<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: An Introduction to Web Application Security</title>
	<atom:link href="http://insecureweb.com/web-security/an-introduction-to-web-application-security/feed/" rel="self" type="application/rss+xml" />
	<link>http://insecureweb.com/web-security/an-introduction-to-web-application-security/</link>
	<description>Insight into web application security</description>
	<lastBuildDate>Wed, 16 Dec 2009 01:02:49 -0800</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8.5</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Justin Klein Keane</title>
		<link>http://insecureweb.com/web-security/an-introduction-to-web-application-security/comment-page-1/#comment-25</link>
		<dc:creator>Justin Klein Keane</dc:creator>
		<pubDate>Wed, 04 Mar 2009 22:38:37 +0000</pubDate>
		<guid isPermaLink="false">http://www.insecureweb.com/?p=8#comment-25</guid>
		<description>Request parameters actually extend far beyond GET and POST and these other request parameters are often overlooked by developers.  For instance, http-referer and browser are user supplied parameters that are often used by logging mechanisms in web applications without developers ever realizing that malicious users can alter these parameters to include SQL injections, Cross Site Scripting (XSS) designed to attack admins viewing log reports, and other nastiness.  Cookies are another source of malicious content that developers rarely consider.  Every piece of user supplied data can be manipulated quite easily by attackers with tools like WebScarab, Paros, and the Firefox Tamper Data plugin.  It&#039;s important to sanitize all of this data before processing it.

What you describe is also an element of Cross Site Request Forgery (CSRF or Sea-Surf) that can be prevented by injecting pseudo random hidden tokens into forms.  This strategy can be used to insure that form POSTs are actually being generated by authenticated users.  Web systems record tokens when they generate the forms, and then only process form POSTs if they&#039;re accompanied by the relevant token.  Making tokens time sensitive is also a good idea (i.e. they time out after an hour).  Needless to say a good random generation algorithm is essential so these token&#039;s can&#039;t be predicted.</description>
		<content:encoded><![CDATA[<p>Request parameters actually extend far beyond GET and POST and these other request parameters are often overlooked by developers.  For instance, http-referer and browser are user supplied parameters that are often used by logging mechanisms in web applications without developers ever realizing that malicious users can alter these parameters to include SQL injections, Cross Site Scripting (XSS) designed to attack admins viewing log reports, and other nastiness.  Cookies are another source of malicious content that developers rarely consider.  Every piece of user supplied data can be manipulated quite easily by attackers with tools like WebScarab, Paros, and the Firefox Tamper Data plugin.  It&#8217;s important to sanitize all of this data before processing it.</p>
<p>What you describe is also an element of Cross Site Request Forgery (CSRF or Sea-Surf) that can be prevented by injecting pseudo random hidden tokens into forms.  This strategy can be used to insure that form POSTs are actually being generated by authenticated users.  Web systems record tokens when they generate the forms, and then only process form POSTs if they&#8217;re accompanied by the relevant token.  Making tokens time sensitive is also a good idea (i.e. they time out after an hour).  Needless to say a good random generation algorithm is essential so these token&#8217;s can&#8217;t be predicted.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
