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

[AmanTodi]

In a web project we use ESAPI validator to sanitize inputs. While most of the improper inputs are detected as expected, it fails to detect the below given input as improper. I am using esapi-2.1.0.1 and antisamy-1.5.3 jars.

<img src=x onerror=alert(1) alt=

Potentially, the browser closes the tag itself, hence triggering the alert function. Surprisingly, ESAPI detects the below given input as improper:

<img src=x onerror=alert(1) alt="text"

Below are some test cases and analysis done :
Regex used for alt attribute : [a-zA-Z0-9:-_.]+ (It needs minimum one character)
Regex used for onerror attribute : [0-9\s*,]* (It allows numbers and whitespace characters)

1. Input: <img src=x alt="" || Observation: Tag is filtered || Status: Passed
2. Input: <img src=x alt= || Observation: Tag not filtered || Status: Failed
3. Input: <img src=x onerror=alert(1) alt="" || Observation: Tag is filtered (due to regex condition for onerror) || Status: Passed
4. Input: <img src=x onerror=alert(1) alt= || Observation: Tag not filtered || Status: Failed

Observation:
Value of alt attribute is modifying the behavior of attribute validation (for itself in cases 1 & 2 and other tags in cases 3 & 4).

Questions:

1. For case 4. isn't the regex for onerror still supposed to validate the onerror attribute? Has it got something to do with alt attribute value?
2. What are the probable reasons where the value of alt attribute could alter the behavior of other attributes?

Can anyone please guide me with any suggestions or comments to mitigate the issue if I am going wrong somewhere ?

Thanks.

[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.