<?xml version="1.0" encoding="UTF-8"?><!-- generator="wordpress/2.2.3" -->
<rss version="2.0" 
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	>
<channel>
	<title>Comments on: Debugging an XSS attack</title>
	<link>http://alexking.org/blog/2008/08/12/debugging-an-xss-attack</link>
	<description>Alex King's blog - software, photography, sports, etc.</description>
	<pubDate>Wed, 07 Jan 2009 20:44:56 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.2.3</generator>

	<item>
		<title>By: David O'Shea</title>
		<link>http://alexking.org/blog/2008/08/12/debugging-an-xss-attack#comment-64546</link>
		<dc:creator>David O'Shea</dc:creator>
		<pubDate>Fri, 05 Sep 2008 01:16:59 +0000</pubDate>
		<guid>http://alexking.org/blog/2008/08/12/debugging-an-xss-attack#comment-64546</guid>
		<description>"Strip out tags/content you don’t want to support": I have seen the advice, which I agree with, that you should instead strip out ALL tags/content except that which you DO want to support.  If you just strip out things that are "bad", you might forget something or possibly not know about some special tag which can be used for an exploit on some particular browser.  Only letting through the things which you know for sure are okay is safer and more "future proof".</description>
		<content:encoded><![CDATA[<p>&#8220;Strip out tags/content you don’t want to support&#8221;: I have seen the advice, which I agree with, that you should instead strip out ALL tags/content except that which you DO want to support.  If you just strip out things that are &#8220;bad&#8221;, you might forget something or possibly not know about some special tag which can be used for an exploit on some particular browser.  Only letting through the things which you know for sure are okay is safer and more &#8220;future proof&#8221;.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Stefan</title>
		<link>http://alexking.org/blog/2008/08/12/debugging-an-xss-attack#comment-64277</link>
		<dc:creator>Stefan</dc:creator>
		<pubDate>Fri, 15 Aug 2008 09:36:41 +0000</pubDate>
		<guid>http://alexking.org/blog/2008/08/12/debugging-an-xss-attack#comment-64277</guid>
		<description>And again I've learned a lot about XSS!
Thanks Alex!</description>
		<content:encoded><![CDATA[<p>And again I&#8217;ve learned a lot about XSS!<br />
Thanks Alex!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: ddos help</title>
		<link>http://alexking.org/blog/2008/08/12/debugging-an-xss-attack#comment-64256</link>
		<dc:creator>ddos help</dc:creator>
		<pubDate>Wed, 13 Aug 2008 17:29:10 +0000</pubDate>
		<guid>http://alexking.org/blog/2008/08/12/debugging-an-xss-attack#comment-64256</guid>
		<description>The thing that makes XSS attacks nastier than, for example, injections is that creating an XSS vulnerability in your web application is much easier than MySql injection for example. I have personally had to combat XSS vulnerabilities and sometimes they can also be pretty hard to find.</description>
		<content:encoded><![CDATA[<p>The thing that makes XSS attacks nastier than, for example, injections is that creating an XSS vulnerability in your web application is much easier than MySql injection for example. I have personally had to combat XSS vulnerabilities and sometimes they can also be pretty hard to find.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Joe Casabona</title>
		<link>http://alexking.org/blog/2008/08/12/debugging-an-xss-attack#comment-64251</link>
		<dc:creator>Joe Casabona</dc:creator>
		<pubDate>Wed, 13 Aug 2008 03:26:59 +0000</pubDate>
		<guid>http://alexking.org/blog/2008/08/12/debugging-an-xss-attack#comment-64251</guid>
		<description>Thanks Alex- Great post! I've been careful about things like SQL injections. Now I know to look for these kinds of attacks too.</description>
		<content:encoded><![CDATA[<p>Thanks Alex- Great post! I&#8217;ve been careful about things like SQL injections. Now I know to look for these kinds of attacks too.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
