Protecting your web applications from the Universal XSS Vulnerability in Internet Explorer 11

Feb 05, 15 Protecting your web applications from the Universal XSS Vulnerability in Internet Explorer 11

A vulnerability in IE 11 has been announced by security researcher David Leo, which has yet to be patched by Microsoft. This zero-day vulnerability, termed as Universal XSS, bypasses the Same Origin Policy (SOP) implemented by IE. SOP ensures one site cannot access cookies or other content set by another site.

Being able to bypass SOP means that an attacker can steal anything from another domain (site), and inject anything into another domain (site).

A proof-of-concept has been put up on this page on the domain This is the attacking domain. The target domain is, whose content is changed to include “Hacked by Deusen” by the former.

To execute this attack, the attackers would have to lure the victim to their malicious page. While the PoC injects harmless content into the Daily Mail site’s page, an attacker could steal cookies to a banking site instead, which would give them unfettered access to the victim’s bank account.  Or they steal other credentials or inject malicious content into the targeted domain.

While this is primarily a client side vulnerability, the Barracuda Web Application Firewall can help mitigate this using its anti-clickjacking module, with just a few clicks.

The anti-clickjacking feature injects the X-Frame-Options HTTP header in HTTP responses with a value of either DENY or SAMEORIGIN. If for example, your bank’s pages contain this header in their responses, then IE (or any modern browser) will prevent the attacker’s domain to render the bank’s page in their iframe, which is required to carry out the attack.

To configure this, navigate to the WEBSITES::Advanced Security page and scroll down to the Clickjacking Protection section. Click Edit against each of the services to bring up the edit window. Set the Status to ON and the Render Page Inside Iframe to Never or Same Origin.

The techlib article for this can be found at:

Note that if your website is rendered within iframes from external domains for a deliberate reason, then you should configure “Clickjacking” to Allowed Origin URI and provide the list of domains that you wish to whitelist for rendering your site.

If your backend web application is already inserting this header, or if you have previously configured the WAF to insert this via the Websites Translations page, then there is no need to redo this.

More information about X-Frame-Options header can be found at:

Mitigating framesniffing with the X-Frame-Options header