AntiSamy rules not getting applied to attributes if an attribute does not have a value about antisamy

[kwwall]

@davewichers - This is related to https://stackoverflow.com/questions/66370847/owasp-esapi-xss-attack-undetected. There's a little more information there. He tried it with the AntiSamy 1.5.7 jar and had the same problem. Even if this is not a bug in AntiSamy, it would still make a good test case. However, you may want to look at the SO link as @AmanTodi gives more details there about the AntiSamy policy file that was used.

[spassarop]

Hi everyone, I'm not sure what that problem really is, because I could not reproduce it in AntiSamy.

I ran two tests with 1.6.0 and 1.5.7, both with default policy and the one that issuer states in SO (https://github.com/OWASP/EJSF/blob/master/esapi_master_FULL/antisamy-esapi.xml). I ran the following code:

String test1 = as.scan("<img src=x onerror=alert(1) alt='text'", policy, AntiSamy.DOM).getCleanHTML();
String test2 = as.scan("<img src=x onerror=alert(1) alt=", policy, AntiSamy.DOM).getCleanHTML();
System.out.println("test1:"+test1);
System.out.println("test2:"+test2);

Both DOM and SAX parsers returned the same, also for both of the AntiSamy versions I mentioned. From varying configurations I had the following results:

Default policy:

test1:<img alt="text" src="x" />
test2:

antisamy-esapi.xml policy:

test1:
test2:

So none of the outputs have the onerror attribute. I even changed the default policy for the img tag to use the regexps on the description and results are the same.

An extra info I can give is that the empty results for the unassigned alt= attribute are because the parser does not even interpret the input as valid HTML. That's an issue with the parser library (CyberNeko HTML Parser), however, it isn't directly related to the actual problem of this issue.

More info should be provided to confirm that's an AntiSamy issue, like a test case that fails on filtering the onerror tag, without using ESAPI. Then we could start to indentify the problem and search for solutions.

[AmanTodi]

@spassarop Can you please check if the following code produces any output in your case ?

List<String> test1 = as.scan("<img src=x onerror=alert(1) alt='text'", policy, AntiSamy.DOM).getErrorMessages();
List<String> test2 = as.scan("<img src=x onerror=alert(1) alt=", policy, AntiSamy.DOM).getErrorMessages();
System.out.println("test1:"+test1);
System.out.println("test2:"+test2);

Are we supposed to get errorMessages everytime an attribute is filtered ?

[davewichers]

Regarding: "Are we supposed to get errorMessages every time an attribute is filtered?", the answer is no. The lack of error messages doesn't mean something is safe. The only way to absolutely know if AntiSamy filtered something is to diff the output vs. the input. @spassarop will have to answer your other question.

[spassarop]

@AmanTodi I just run that exact code on AntiSamy 1.5.7 with the regex policy modifications and this was the result:

test1:[The img tag contained an attribute that we could not process. The onerror attribute had a value of "alert(1)". This value could not be accepted for security reasons. We have chosen to remove this attribute from the tag and leave everything else in place so that we could process the input.]
test2:[]

It makes sense because the onerror attribute was always the reason for filtering in this case. The second input does not return anything because as I said before:

the parser does not even interpret the input as valid HTML

So it's the same as analyzing an empty string, which does not produce any filtering nor error messages.

[davewichers]

@spassarop - Is there still a problem here to fix? Or not actually a problem, or a won't fix??

[spassarop]

The described issue is that some invalid HTML is not returning errors. All presented input examples return HTML with no JS code (one of them empty). It was stated that error absence in the returned list does not mean an issue was not detected.

In this case, one was detected explicitly (validation error returned), the other was "so invalid" that the parser was not even able to get a valid node to analyze (no validation error returned). In any case the initial issue does not apply in my opinion. I would close it, but I leave it you @davewichers.

[davewichers]

OK. Closing this.