XSS vulnerabilities still exist even after using HTML Purifier

Question

I'm testing one of my web application using Acunetix. To protect this project against XSS attacks, I used HTML Purifier. This library is recommended by most of PHP developers for this purpose, but my scan results shows HTML Purifier can not protect us from XSS attacks completely. The scanner found two ways of attack by sending different harmful inputs:

1<img sRc='http://attacker-9437/log.php? (See HTML Purifier result here)
1"onmouseover=vVF3(9185)" (See HTML Purifier result here)

As you can see results, HTML Purifier could not detect such attacks. I don't know if is there any specific option on HTML Purifier to solve such problems, or is it really unable to detect these methods of XSS attacks.
Do you have any idea? Or any other solution?

1 isn't XSS. 2 is safe unless you misuse the purifier (you should never put user content inside attributes). — SLaks
1 that is right, it is HTML injection actually. 2 is used to print user searched term in the value of text box. Do you have any idea for these 2 problem? — Mohammad Saberi
2 should be entirely mitigated with htmlspecialchars() (this will escape the quotation marks). It's generally not something you should feed HTML Purifier - HTML Purifier is for the full HTML, not for text in HTML attributes. (You could, though, build your HTML without htmlspecialchars() and then run the entire document through HTML Purifier before outputting it. HTML Purifier will then strip the "onmouseover" from any tag it happens to be on.) — pinkgothic
See htmlpurifier.org/… for an example of your 2 when purified within its HTML context. — pinkgothic

pinkgothic pinkgothic · Accepted Answer · 2018-09-27T07:57:22

(This is a late answer since this question is becoming the place duplicate questions are linked to, and previously some vital information was only available in comments.)

HTML Purifier is a contextual HTML sanitiser, which is why it seems to be failing on those tasks.

Let's look at why in some detail:

`1<img sRc='http://attacker-9437/log.php?`

You'll notice that HTML Purifier closed this tag for you, leaving only an image injection. An image is a perfectly valid and safe tag (barring, of course, current image library exploits). If you want it to throw away images entirely, consider adjusting the HTML Purifier whitelist by setting HTML.Allowed.

That the image from the example is now loading a URL that belongs to an attacker, thus giving the attacker the IP of the user loading the page (and nothing else), is a tricky problem that HTML Purifier wasn't designed to solve. That said, you could write a HTML Purifier attribute checker that runs after purification, but before the HTML is put back together, like this:

// a bit of context
$htmlDef = $this->configuration->getHTMLDefinition(true);
$image   = $htmlDef->addBlankElement('img');

// HTMLPurifier_AttrTransform_CheckURL is a custom class you've supplied, 
// and checks the URL against a white- or blacklist:
$image->attr_transform_post[] = new HTMLPurifier_AttrTransform_CheckURL();

The HTMLPurifier_AttrTransform_CheckURL class would need to have a structure like this:

class HTMLPurifier_AttrTransform_CheckURL extends HTMLPurifier_AttrTransform
{
    public function transform($attr, $config, $context) {
        $destination = $attr['src'];
        if (is_malicious($destination)) {
            // ^ is_malicious() is something you'd have to write
            $this->confiscateAttr($attr, 'src');
        }
        return $attr;
    }
}

Of course, it's difficult to do this 'right':

if this is a live check with some web-service, this will slow purification down to a crawl
if you're keeping a local cache you run risk of having outdated information
if you're using heuristics ("that URL looks like it might be malicious based on indicators x, y and z"), you run risk of missing whole classes of malicious URLs

`1"onmouseover=vVF3(9185)"`

HTML Purifier assumes the context your HTML is set in is a <div> (unless you tell it otherwise by setting HTML.Parent).

If you just feed it an attribute value, it's going to assume you're going to output this somewhere so the end-result looks like this:

...
<div>1"onmouseover=vVF3(9185)"</div>
...

That's why it appears to not be doing anything about this input - it's harmless in this context. You might even not want to strip this information in that context. I mean, we're talking about this snippet here on stackoverflow, and that's valuable (and not causing a security problem).

Context matters. Now, if you instead feed HTML Purifier this snippet:

<div class="1"onmouseover=vVF3(9185)"">foo</div>

...suddenly you can see what it's made to do:

<div class="1">foo</div>

Now it's removed the injection, because in this context, it would have been malicious.

What to use HTML Purifier for and what not

So now you're left to wonder what you should be using HTML Purifier for, and when it's the wrong tool for the job. Here's a quick run-down:

you should use htmlspecialchars($input, ENT_QUOTES, 'utf-8') (or whatever your encoding is) if you're outputting into a HTML document and aren't interested in preserving HTML at all - it's unnecessary overhead and it'll let some things through
you should use HTML Purifier if you want to output into a HTML document and allow formatting, e.g. if you're a message board and you want people to be able to format their messages using HTML
you should use htmlspecialchars($input, ENT_QUOTES, 'utf-8') if you're outputting into a HTML attribute (HTML Purifier is not meant for this use-case)

You can find some more information about sanitising / escaping by context in this question / answer.

XSS vulnerabilities still exist even after using HTML Purifier

2 Answers

`1<img sRc='http://attacker-9437/log.php?`

`1"onmouseover=vVF3(9185)"`

What to use HTML Purifier for and what not

Points below:

Remediation