Content Blocking: Unintended Consequences

Our company uses a web firewall device called IronPort to attempt to block unwanted network traffic; it blocks access to known phish and malware domains, and, more annoyingly, domains thought to be related to gaming or “questionable” topics (e.g. politics). Whatever.

Today the IT department pushed a new rule set which blocks some requests to domains like s.tagsrvcs.com. Instead of the normal response, you instead get back a HTTP/403 blocking page of type text/html:

That’s fine, I guess (bye-bye trackers).

Except.

Many of the websites I visit (Wired, WashingtonPost, VanityFair, etc) now hang Internet Explorer:

Huh!?! How could blocking a tracker cause the page to hang?

Windbg gives us a great big clue:

Ah ha! The XSS Filter’s regular expression engine is hanging. But why does it hang if the target content is blocked?!?

Because when the target content isn’t blocked, the server returns a HTTP/200 with a zero byte body, and thus nothing that needs to be scanned for an XSS attack.

When the IronPort device blocks a response, it returns a HTTP/403 with the body HTML shown in the first screenshot. Now IE’s XSS filter must run to check to see whether any of the content from the request was reflected into the blocking page. Still, the blocking page response is pretty simple… Hmm… let’s look at the request.

Oh. Yeah, I can see why turning that into a regular expression might take a bit longer than the developers of the XSS Filter might’ve planned for.

So, a few lessons:

1. Don’t underestimate the collateral damage of blocking content.
2. If there’s absolutely no chance of a reflection, send an X-XSS-Protection: 0 response header.
3. As a web developer, choose your third-party dependencies with care. Any of them could break you.
4. When talking to pointy-haired bosses, webdevs, and designers, refer to HTTPS as “HiFi” to help make it clear that TLS isn’t just some techno mumbo-jumbo– it’s necessary to help ensure the fidelity of the user’s experience.

-Eric