<?xml version="1.0" encoding="UTF-8"?><!-- generator="wordpress/2.1" -->
<rss version="2.0" 
	xmlns:content="http://purl.org/rss/1.0/modules/content/">
<channel>
	<title>Comments on: An example of a flawed XSS BlackList filter</title>
	<link>http://blogs.owasp.org/diniscruz/2007/01/23/an-example-of-a-flawed-xss-blacklist-filter/</link>
	<description>A place to post my research (and my comments) on Security and on the .NET Framework</description>
	<pubDate>Thu, 21 Aug 2008 17:28:02 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.1</generator>

	<item>
		<title>By: pdp</title>
		<link>http://blogs.owasp.org/diniscruz/2007/01/23/an-example-of-a-flawed-xss-blacklist-filter/#comment-4</link>
		<author>pdp</author>
		<pubDate>Tue, 23 Jan 2007 15:15:57 +0000</pubDate>
		<guid>http://blogs.owasp.org/diniscruz/2007/01/23/an-example-of-a-flawed-xss-blacklist-filter/#comment-4</guid>
					<description>The main point is that XSS is an attack vector that is very hard to mitigate. Why? Well, different applications have different requirements that involve different problems. Some problems can be grouped and solved with a single solution. Others can’t! You need to write custom solutions.

Also, be aware that currently developed XSS filters protect the client by sanitizing the input sent to the server. That’s very good, however, I’ve seen many applications that do pretty good job on the server side but they fail to perform that well on the client side. I am talking about DOM based XSS. If your JavaScript code makes use of cookies, queries, fragment identifiers or other type of input without sanitizing it, attackers can abuse it in order to execute malicious code on the browser.</description>
		<content:encoded><![CDATA[<p>The main point is that XSS is an attack vector that is very hard to mitigate. Why? Well, different applications have different requirements that involve different problems. Some problems can be grouped and solved with a single solution. Others can’t! You need to write custom solutions.</p>
<p>Also, be aware that currently developed XSS filters protect the client by sanitizing the input sent to the server. That’s very good, however, I’ve seen many applications that do pretty good job on the server side but they fail to perform that well on the client side. I am talking about DOM based XSS. If your JavaScript code makes use of cookies, queries, fragment identifiers or other type of input without sanitizing it, attackers can abuse it in order to execute malicious code on the browser.</p>
]]></content:encoded>
				</item>
	<item>
		<title>By: Anurag</title>
		<link>http://blogs.owasp.org/diniscruz/2007/01/23/an-example-of-a-flawed-xss-blacklist-filter/#comment-5</link>
		<author>Anurag</author>
		<pubDate>Tue, 23 Jan 2007 18:58:37 +0000</pubDate>
		<guid>http://blogs.owasp.org/diniscruz/2007/01/23/an-example-of-a-flawed-xss-blacklist-filter/#comment-5</guid>
					<description>dinis

What you mentioned is correct but if i am correct then the situation you mentioned is for the sites which wants you to input html tags like blogs, or certain discussion forums, etc.
This approach is definitely not right for those websites. 

I agree that this approach does not covers all the websites, but then in my opinion 5-10% of the websites would require such data and even those sites would not require these characters in all of the input. Most of the websites in their regular functionality would not even need the filtered characters mentioned here as input. 


- Anurag</description>
		<content:encoded><![CDATA[<p>dinis</p>
<p>What you mentioned is correct but if i am correct then the situation you mentioned is for the sites which wants you to input html tags like blogs, or certain discussion forums, etc.<br />
This approach is definitely not right for those websites. </p>
<p>I agree that this approach does not covers all the websites, but then in my opinion 5-10% of the websites would require such data and even those sites would not require these characters in all of the input. Most of the websites in their regular functionality would not even need the filtered characters mentioned here as input. </p>
<p>- Anurag</p>
]]></content:encoded>
				</item>
</channel>
</rss>
