With the recent Chrome 57 build, the XSS auditor detection (and blocking capabilities) has been improved to the point that many web-based services suddendly stopped working giving this rather obscure HTTP error:
ERR_BLOCKED_BY_XSS_AUDITOR
The issue is almost always caused by some HTML-formatted content being sent via POST within the request, which is a rather common behavior for a number of modern web tools and features - such as WYSIWYG editors, interactive uploaders, AJAX-based CMS real-time updates, and so on.
When the tool is developed by third-parties, the best thing you can do is to open an issue with the developers and make them go through the hassle: however, there are scenarios where you *need* to anticipate the fix by yourself, not to mention the cases when *you* are the tool developer. This is what happened to me yesterday, when I had to apply a quick fix to a tool I coded for a friend of mine a while ago: an interactive electronic invoice display which follows the recent italian electronic invoice PA standards.
What I did there was use an AJAX-based function to pass the whole content of an entire HTML page and then displaying it using the same HTTP request, which was the only working way I found to support the drag-and-drop feature in a cross-browser way: more specifically, I couldn't use the great HTML5 native drag-drop feature because it's not working well in IE < 10, which I really had to support. The script worked really well until a couple days ago, when it suddenly started to raise the above error. After digging here and there, I finally stumbled upon this post which (kinda) explained the fact.
According to the post author, the most straightforward way to overcome the issue was adding the following key/value pair to the response headers:
|
1 |
X-XSS-Protection: 0 |
This can be done in a number of ways, depending on the server-side technology you're using.
ASP.NET
Add the following within the Web.Config file:
|
1 2 3 4 5 6 |
<system.webServer> <httpProtocol> <customHeaders> <add name="X-XSS-Protection" value="0" /> </customHeaders> [...] |
Or just add a HttpContext.Current.Response.AppendHeader("X-XSS-Protection", 0) within your MVC controller/ASPX page code.
PHP
Use the Header function to add something like the following before the first ouput:
|
1 |
header('X-XSS-Protection: 0'); |
... And so on.
Unfortunately, such approach didn't fix my problem at all. Then I thought about getting rid of the raw HTML code by encoding it in some convenient way, such as the always-good Base64 schema... And I had much better luck with that.
What I did was downloading this neat jQuery-base64 plugin (many thanks to the author, Tao Klerks), adding it to my HTML page using a standard <script> element within the <head> block and then encoding the input right before POSTing it in the following way:
|
1 |
$.base64Encode(htmlContent); |
Then I switched to the server-side PHP code and base64-decoded the received input from the result page - using the PHP-native base64_decode function - in the following way:
|
1 |
if ($_POST["html"]) die(base64_decode($_POST["html"])); |
... And that was enough to get rid of the ERR_BLOCKED_BY_XSS_AUDITOR error.
That's it for now: happy coding!
