IE8 XSS过滤器：它到底做了什么？ [英] IE8 XSS filter: what does it really do?

问题描述

Internet Explorer 8具有新的安全功能，试图拦截跨站点脚本尝试的XSS过滤器。它以这种方式描述：

Internet Explorer 8 has a new security feature, an XSS filter that tries to intercept cross-site scripting attempts. It's described this way:

XSS过滤器是Internet Explorer 8的新功能，可检测URL和HTTP POST请求中的JavaScript。如果检测到JavaScript，则XSS过滤器会搜索反射的证据，如果攻击请求未经更改提交，则会返回到攻击网站的信息。如果检测到反射，XSS过滤器会清理原始请求，以便无法执行其他JavaScript。

The XSS Filter, a feature new to Internet Explorer 8, detects JavaScript in URL and HTTP POST requests. If JavaScript is detected, the XSS Filter searches evidence of reflection, information that would be returned to the attacking Web site if the attacking request were submitted unchanged. If reflection is detected, the XSS Filter sanitizes the original request so that the additional JavaScript cannot be executed.

我发现即使没有反射的证据，XSS过滤器也会启动，我开始认为过滤器只是在向另一个站点发出请求并且响应包含JavaScript时才会注意到。

I'm finding that the XSS filter kicks in even when there's no "evidence of reflection", and am starting to think that the filter simply notices when a request is made to another site and the response contains JavaScript.

但即使这很难验证，因为效果似乎来了又去。 IE有不同的区域，就在我认为我已经重现了这个问题时，过滤器不再启动了，我不知道为什么。

But even that is hard to verify because the effect seems to come and go. IE has different zones, and just when I think I've reproduced the problem, the filter doesn't kick in anymore, and I don't know why.

任何人有关于如何打击这个的任何提示？过滤器真的在寻找什么？有没有办法让好人将数据发布到第三方网站，该网站可以返回HTML以显示在iframe中而不会触发过滤器？

Anyone have any tips on how to combat this? What is the filter really looking for? Is there any way for a good-guy to POST data to a 3rd-party site which can return HTML to be displayed in an iframe and not trigger the filter?

背景：我正在从第三方网站加载JavaScript库。 JavaScript从当前HTML页面收集一些数据，并将其发布到第三方网站，第三方网站会响应一些HTML以显示在iframe中。要查看它的实际效果，请访问 AOL Food 页面，然后点击在故事上方打印图标。

Background: I'm loading a JavaScript library from a 3rd-party site. That JavaScript harvests some data from the current HTML page, and posts it to the 3rd-party site, which responds with some HTML to be displayed in an iframe. To see it in action, visit an AOL Food page and click the "Print" icon just above the story.

推荐答案

它真正做到了什么？它允许第三方链接到您网站的混乱版本。

What does it really do? It allows third parties to link to a messed-up version of your site.

当[满足一些条件并且]在查询中看到一个字符串时它会启动提交也在页面中逐字存在，并且它认为可能是危险的。

It kicks in when [a few conditions are met and] it sees a string in the query submission that also exists verbatim in the page, and which it thinks might be dangerous.

它假定如果< script> something（）< ; / script> 存在于查询字符串和页面代码中，然后必须是因为您的服务器端脚本不安全并且直接将该字符串反射为标记而不进行转义。

It assumes that if <script>something()</script> exists in both the query string and the page code, then it must be because your server-side script is insecure and reflected that string straight back out as markup without escaping.

但当然，除了这是一个非常有效的查询，有人可能会巧合地输入匹配，这也是因为有人看了一下页面并故意复制了部分出来了。例如：

But of course apart from the fact that's it's a perfectly valid query someone might have typed that matches by coincidence, it's also just as possible that they match because someone looked at the page and deliberately copied part of it out. For example:

http://www.bing.com/search?q=%3Cscript+type%3D%22text%2Fjavascript%22%3E

在IE8中跟随它，我成功地破坏了你的Bing页面，因此它会给出脚本错误，弹出结果位赢了工作。从本质上讲，它会为攻击者提供链接跟踪许可，以挑选和禁用他不喜欢的部分页面 - 甚至可能包括其他与安全相关的措施，如framebuster脚本。

Follow that in IE8 and I've successfully sabotaged your Bing page so it'll give script errors, and the pop-out result bits won't work. Essentially it gives an attacker whose link is being followed license to pick out and disable parts of the page he doesn't like — and that might even include other security-related measures like framebuster scripts.

IE8认为潜在危险是什么？除了这个脚本标记之外，还有更多和更多的陌生事物。 例如。更重要的是，它似乎与使用文本模式系统（可能是正则表达式）的一组危险模板相匹配，而不是像最终将解析页面本身的任何类型的HTML解析器。是的，使用IE8并且您的浏览器正在使用HT̈͜MLw̧̼̜it̏̔h͙r̿e​​̴̬g̉̆e͎x͍͔̑̽̚。

What does IE8 consider ‘potentially dangerous’? A lot more and a lot stranger things than just this script tag. eg. What's more, it appears to match against a set of ‘dangerous’ templates using a text pattern system (presumably regex), instead of any kind of HTML parser like the one that will eventually parse the page itself. Yes, use IE8 and your browser is pařṣinͅg HT̈́͜ML w̧̼̜it̏̔h ͙r̿e̴̬g̉̆e͎x͍͔̑̃̽̚.

通过查看查询中的字符串'XSS protection'是完全虚假 。它不能固定;这个概念本质上是有缺陷的。除了在不需要时踩到它的问题之外，除了最基本的攻击之外，它无法真正保护你免受任何攻击 - 并且攻击者肯定会解决这样的问题，因为IE8变得更加广泛使用。如果您忘记了正确地逃避HTML输出，那么您仍然会受到攻击;所有XSS保护都为您提供了一种虚假的安全感。不幸的是，微软似乎喜欢这种虚假的安全感;在服务器端，ASP.NET中也有类似的XSS保护。

‘XSS protection’ by looking at the strings in the query is utterly bogus. It can't be ‘fixed’; the very concept is intrinsically flawed. Apart from the problem of stepping in when it's not wanted, it can't ever really protect you from anything but the most basic attacks — and the attackers will surely workaround such blocks as IE8 becomes more widely used. If you've been forgetting to escape your HTML output correctly you'll still be vulnerable; all XSS "protection" has to offer you is a false sense of security. Unfortunately Microsoft seem to like this false sense of security; there is similar XSS "protection" in ASP.NET too, on the server side.

所以，如果你对webapp创作有了一些线索并且你已经正确像一个好男孩一样将输出转换为HTML，通过输出标题来禁用这种不必要的，不可行的，错误的入侵绝对是一个好主意：

So if you've got a clue about webapp authoring and you've been properly escaping output to HTML like a good boy, it's definitely a good idea to disable this unwanted, unworkable, wrong-headed intrusion by outputting the header:

X-XSS-Protection: 0

在您的HTTP响应中。 （如果您使用的是ASP.NET，请在页面中使用 ValidateRequest =false。）

in your HTTP responses. (And using ValidateRequest="false" in your pages if you're using ASP.NET.)

For还有其他人，他们仍然在PHP中将字符串拼凑在一起而不需要正确编码......好吧你也可以把它留在上面。不要指望它实际上保护你的用户，但你的网站已经坏了，所以谁关心它是否会多一点，对吧？

For everyone else, who still slings strings together in PHP without taking care to encode properly... well you might as well leave it on. Don't expect it to actually protect your users, but your site is already broken, so who cares if it breaks a little more, right?

要查看它的实际效果，请访问AOL Food页面，然后单击故事上方的打印图标。

To see it in action, visit an AOL Food page and click the "Print" icon just above the story.

啊是的，我可以在IE8中看到这个突破。并没有立即显而易见IE已经阻止了内容阻止它执行虽然...唯一的跨域请求我可以看到这是XSS过滤器的候选者是这个到 http：// h30405.www3.hp.com/print/start ：

Ah yes, I can see this breaking in IE8. Not immediately obvious where IE has made the hack to the content that's stopped it executing though... the only cross-domain request I can see that's a candidate for the XSS filter is this one to http://h30405.www3.hp.com/print/start:

POST /print/start HTTP/1.1
Host: h30405.www3.hp.com
Referer: http://recipe.aol.com/recipe/oatmeal-butter-cookies/142275?

csrfmiddlewaretoken=undefined&characterset=utf-8&location=http%253A%2F%2Frecipe.aol.com%2Frecipe%2Foatmeal-butter-cookies%2F142275&template=recipe&blocks=Dd%3Do%7Efsp%7E%7B%3D%25%3F%3D%3C%28%2B.%2F%2C%28%3D3%3F%3D%7Dsp%7Ct@kfoz%3D%25%3F%3D%7E%7C%7Czqk%7Cpspm%3Db3%3Fd%3Do%7Efsp%7E%7B%3D%25%3F%3D%3C%7D%2F%27%2B%2C.%3D3%3F%3D%7Dsp%7Ct@kfoz%3D%25%3F%3D%7E%7C%7Czqk...

blocks 参数继续页面更乱。据推测，那里有某些东西（巧合？）反映在返回的HTML中，并触发了IE8中关于XSS漏洞利用的概念之一。

that blocks parameter continues with pages more gibberish. Presumably there is something there that (by coincidence?) is reflected in the returned HTML and triggers one of IE8's messed up ideas of what an XSS exploit looks like.

要解决此问题，惠普需要在h30405.www3.hp.com上安装服务器，包括 X-XSS-Protection：0 标题。

To fix this, HP need to make the server at h30405.www3.hp.com include the X-XSS-Protection: 0 header.

这篇关于IE8 XSS过滤器：它到底做了什么？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！