<?xml version="1.0" encoding="UTF-8"?><!-- generator="wordpress/2.0.5" -->
<rss version="2.0" 
	xmlns:content="http://purl.org/rss/1.0/modules/content/">
<channel>
	<title>Comments on: PHP form input and Cross-Site attacks</title>
	<link>http://www.melbournechapter.net/wordpress/programming-languages/php/cman/2006/06/16/php-form-input-and-cross-site-attacks/</link>
	<description>web application development with popular technologies</description>
	<pubDate>Tue, 02 Dec 2008 07:13:38 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.0.5</generator>

	<item>
		<title>by: chris</title>
		<link>http://www.melbournechapter.net/wordpress/programming-languages/php/cman/2006/06/16/php-form-input-and-cross-site-attacks/#comment-71707</link>
		<pubDate>Wed, 17 Oct 2007 11:39:43 +0000</pubDate>
		<guid>http://www.melbournechapter.net/wordpress/programming-languages/php/cman/2006/06/16/php-form-input-and-cross-site-attacks/#comment-71707</guid>
					<description>as a relative newbie to all of this, I have found this very interesting. So, excusing my ignorance, once the variables have been instantiated on the mail form, how would one verify this on submission?</description>
		<content:encoded><![CDATA[<p>as a relative newbie to all of this, I have found this very interesting. So, excusing my ignorance, once the variables have been instantiated on the mail form, how would one verify this on submission?
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: ha.ckers.org security lab - Archive &#187; Content restrictions and script keys</title>
		<link>http://www.melbournechapter.net/wordpress/programming-languages/php/cman/2006/06/16/php-form-input-and-cross-site-attacks/#comment-2373</link>
		<pubDate>Mon, 26 Jun 2006 15:46:50 +0000</pubDate>
		<guid>http://www.melbournechapter.net/wordpress/programming-languages/php/cman/2006/06/16/php-form-input-and-cross-site-attacks/#comment-2373</guid>
					<description>[...] Content restrictions was never designed to stop basic CSRF, unless you are talking about functions that could only be affected by JavaScript, which would inherantly be stopped.  Brian&#8217;s comment that this would not help with reflected JS should be innaccurate, as any JavaScript would be affected (part of the problem was that it could end up killing valid JS on the page, which was something we were attempting to overcome in our first iteration of the idea by wrapping the possible offending output in tags to be parsed out by the browser as safe content). [...]</description>
		<content:encoded><![CDATA[<p>[&#8230;] Content restrictions was never designed to stop basic CSRF, unless you are talking about functions that could only be affected by JavaScript, which would inherantly be stopped.  Brian&#8217;s comment that this would not help with reflected JS should be innaccurate, as any JavaScript would be affected (part of the problem was that it could end up killing valid JS on the page, which was something we were attempting to overcome in our first iteration of the idea by wrapping the possible offending output in tags to be parsed out by the browser as safe content). [&#8230;]
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: Richard Lee</title>
		<link>http://www.melbournechapter.net/wordpress/programming-languages/php/cman/2006/06/16/php-form-input-and-cross-site-attacks/#comment-1978</link>
		<pubDate>Sat, 17 Jun 2006 04:34:34 +0000</pubDate>
		<guid>http://www.melbournechapter.net/wordpress/programming-languages/php/cman/2006/06/16/php-form-input-and-cross-site-attacks/#comment-1978</guid>
					<description>For those reading this article you might also want to read up on my post on mail-header injection, and another method spammers use to "hijack" your mail forms.</description>
		<content:encoded><![CDATA[<p>For those reading this article you might also want to read up on my post on mail-header injection, and another method spammers use to &#8220;hijack&#8221; your mail forms.
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: Cameron Manderson</title>
		<link>http://www.melbournechapter.net/wordpress/programming-languages/php/cman/2006/06/16/php-form-input-and-cross-site-attacks/#comment-1940</link>
		<pubDate>Fri, 16 Jun 2006 02:39:50 +0000</pubDate>
		<guid>http://www.melbournechapter.net/wordpress/programming-languages/php/cman/2006/06/16/php-form-input-and-cross-site-attacks/#comment-1940</guid>
					<description>Also you might want to unset the formId from your session when it is sumitted to the server. Also you will want to consider a strategy for your token_timestamp, which you can now use to make forms expire.</description>
		<content:encoded><![CDATA[<p>Also you might want to unset the formId from your session when it is sumitted to the server. Also you will want to consider a strategy for your token_timestamp, which you can now use to make forms expire.
</p>
]]></content:encoded>
				</item>
</channel>
</rss>
