Filter Bypass using certain characters

[GoogleCodeExporter]

What steps will reproduce the problem?
1. <img src=x / onerror=alert(1)>
2.
3.

What is the expected output? What do you see instead?
It should have been filtered out due to an event attribute, but ignored just 
like plain text.

What version of the product are you using? On what operating system?
Version 1.4.4

Please provide any additional information below.
Nothing fancy. Its just that browsers are still able to parse this properly. 
Thats the basic problem with XSS - Impedence Mismatch

Cheers,
Nafeez, Citrix Systems

Original issue reported on code.google.com by ahamedna...@gmail.com on 18 Sep 2012 at 7:45

[GoogleCodeExporter]

I'm curious what the issue is here.  I tried with 1.4.4 and the cleaned string 
is "<img src="x" />", which appears to be correct.  What are you seeing that is 
causing an actual problem here?

Can you come up with an attack vector where you are able to get "clean" results 
that can still cause javascript to be executed?

-Troy

Original comment by tad...@gmail.com on 3 Oct 2012 at 3:20

[GoogleCodeExporter]

Hi Troy,
 I was using CleanResults.getErrorMessages() to verify if there were any errors and it returns nothing. And I just checked whether CleanResults.getCleanHTML() and it produced the same results as you said.

So basically the problem is not in the AntiSamy detection system. But its in 
the population of the ErrorList. 

String dirtyInput = "<img src=x / onerror=alert(1)>";
System.out.println(cr.getCleanHTML() + "\n Errors: " +cr.getErrorMessages());
<img src="x">
 Errors: []

So any application which just checks for the Error messages and then uses the 
System is affected. For eg) the application on which I found this was found to 
check getErrorMessages() and if its empty it considers it as safe.

This is a normal implementation scenario IMHO.

Thank you.

Original comment by ahamedna...@gmail.com on 4 Oct 2012 at 3:52

[GoogleCodeExporter]

Troy is correct. I've been proactively warning people against doing this from 
day one, and so I hope this is not a normal implementation scenario. 

Ideally, this should be reported as an error for consistency's sake.

Original comment by arshan.d...@gmail.com on 22 Oct 2012 at 2:24