Internet Explorer 8 has a new security feature, an XSS filter that tries to intercept cross-site scripting attempts. It's described this way:
Internet Explorer 8有一个新的安全特性，一个XSS过滤器，试图拦截跨站脚本尝试。这样的描述:
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过滤器是Internet Explorer 8的新特性，它可以在URL和HTTP POST请求中检测JavaScript。如果检测到JavaScript, XSS过滤器会搜索反射的证据，如果攻击请求没有更改，则返回到攻击Web站点的信息。如果检测到反射，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.
我发现，即使没有“反射的证据”，XSS过滤器也会启动，并且开始认为过滤器只是在请求到另一个站点时才会注意到，并且响应包含了JavaScript。
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.
但即便如此，也很难验证，因为这种影响似乎是来来去去的。IE有不同的区域，当我认为我已经复制了这个问题时，过滤器就不再踢了，我也不知道为什么。
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?
有人知道如何应对吗?过滤器究竟在寻找什么?有什么方法可以让一个好男人把数据发布到一个第三方网站上，这个网站可以返回HTML以显示在iframe中而不是触发过滤器?
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.
背景:我正在从一个第三方站点加载一个JavaScript库。JavaScript从当前的HTML页面获取一些数据，并将其发布到第三方站点，该站点以iframe中显示的一些HTML进行响应。要想看到它的作用，请访问AOL的食品页面，点击上面的“打印”图标。
3 个解决方案
#1
55
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.
当(一些条件满足时)它会启动，它在查询提交中看到一个字符串，它也在页面中逐字地存在，并且它认为它可能是危险的。
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
http://www.bing.com/search?q=%3Cscript + % 3 d % 22型文本3 e % 2 fjavascript % 22%
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中，我已经成功地破坏了你的Bing页面，所以它会给脚本错误，而弹出的结果位不会起作用。本质上，它提供了一个攻击者，其链接正在被跟踪，以挑选和禁用他不喜欢的部分，甚至可能包括其他与安全相关的措施，比如framebuster脚本。
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͍͔̑̃̽̚.
IE8认为“潜在的危险”是什么?除了这个script标签，还有很多其他的东西。如。更重要的是，它似乎与一组使用文本模式系统(可能是regex)的“危险”模板匹配，而不是像最终解析页面本身那样的HTML解析器。是的,使用IE8浏览器是pař年代̣inͅg HT̈́͜毫升w̧̼̜它̏̔h͙r̿e̴̬g̉̆e͎x͍͔̑̃̽̚。
‘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.
通过查看查询中的字符串，“XSS保护”完全是伪造的。它不能被“固定”;这个概念本身就是有缺陷的。除了在不需要时介入的问题之外，它还不能真正保护你免受最基本的攻击——而且攻击者肯定会在IE8变得更广泛使用的时候解决这些问题。如果你没有正确地逃离HTML输出，你仍然会很脆弱;所有的XSS“保护”必须提供给你的是一种虚假的安全感。不幸的是，微软似乎喜欢这种虚假的安全感;在ASP中也有类似的XSS“保护”。在服务器端也有。
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:
因此，如果你对webapp的创作有了一个线索，并且你已经像一个好男孩一样正确地逃避了HTML的输出，那么你可以通过输出标题来禁用这种不受欢迎的、不可行的、错误的入侵。
X-XSS-Protection: 0
in your HTTP responses. (And using ValidateRequest="false" in your pages if you're using ASP.NET.)
在你的HTTP响应。(如果使用ASP.NET，则在页面中使用ValidateRequest=“false”)。
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?
对于其他所有人来说，他们仍然在PHP中使用字符串，而不需要仔细地编码……好吧，你还是别谈了。不要期望它能真正保护你的用户，但是你的网站已经被破坏了，所以谁会在乎它是否会更坏呢?
To see it in action, visit an AOL Food page and click the "Print" icon just above the story.
要想看到它的作用，请访问AOL的食品页面，点击上面的“打印”图标。
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:
啊，是的，我能看到IE8的突破。不太明显的是，IE在哪里对停止执行的内容进行了攻击……我能看到的唯一一个跨域请求是XSS过滤器的候选项，它是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...
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.
该块参数将继续使用更多的胡言乱语。假设在返回的HTML中有一些东西(巧合?)，并触发了IE8的一个混乱的想法，即XSS的开发是什么样子的。
To fix this, HP need to make the server at h30405.www3.hp.com include the X-XSS-Protection: 0 header.
要解决这个问题，HP需要在h30405.www3.hp.com上创建服务器，包括X-XSS-Protection: 0 header。
#2
25
You should send me (ericlaw@microsoft) a network capture (www.fiddlercap.com) of the scenario you think is incorrect.
你应该给我(ericlaw@microsoft)一个你认为不正确的场景的网络捕捉(www.fiddlercap.com)。
The XSS filter works as follows:
XSS滤波器的工作原理如下:
- Is XSSFILTER enabled for this process?
If yes– proceed to next check If no – bypass XSS Filter and continue loading - 这个过程是否启用了XSSFILTER ?如果是，请继续进行下一个检查，如果没有旁路XSS过滤器并继续加载。
- Is a "document" load (like a frame, not a subdownload)? If yes– proceed to next check If no – bypass XSS Filter and continue loading
- 是一个“文档”加载(像一个框架，而不是一个子下载)?如果是，请继续进行下一个检查，如果没有旁路XSS过滤器并继续加载。
- Is it a HTTP/HTTPS request? If yes– proceed to next check If no – bypass XSS Filter and continue loading
- 它是HTTP/HTTPS请求吗?如果是，请继续进行下一个检查，如果没有旁路XSS过滤器并继续加载。
- Does RESPONSE contain x-xss-protection header? Yes: Value = 1: XSS Filter Enabled (no urlaction check) Value = 0: XSS Filter Disabled (no urlaction check) No: proceed to next check
- 响应是否包含x-xss保护头?Yes:值= 1:XSS过滤器启用(无urlaction检查)值= 0:XSS过滤器禁用(无urlaction检查)不:继续下一个检查。
- Is the site loading in a Zone where URLAction enables XSS filtering? (By default: Internet, Trusted, Restricted) If yes– proceed to next check If no – bypass XSS Filter and continue loading
- 站点是否在URLAction支持XSS过滤的区域中加载?(默认情况下:互联网，受信任的，受限制的)如果是，继续进行下一个检查，如果没有旁路XSS过滤器并继续加载。
- Is a cross site Request? (Referrer header: Does the final (post-redirect) fully-qualified domain name in the HTTP request referrer header match the fully-qualified domain name of the URL being retrieved?) If yes – bypass XSS Filter and continue loading If no – then the URL in the request should be neutered.
- 跨站请求?(Referrer header:在HTTP请求Referrer头中，最终的(后重定向)完全限定域名是否匹配被检索的URL的完全限定域名?)如果是-绕过XSS过滤器并继续加载，如果没有-那么请求中的URL应该是中性的。
- Does the heuristic indicate of the RESPONSE data came from unsafe REQUEST DATA? If yes – modify the response.
- 响应数据的启发式指示是否来自不安全的请求数据?如果是，请修改响应。
Now, the exact details of #7 are quite complicated, but basically, you can imagine that IE does a match of request data (URL/Post Body) to response data (script bodies) and if they match, then the response data will be modified.
现在，#7的确切细节相当复杂，但是基本上，您可以想象IE会对响应数据(脚本主体)进行匹配请求数据(URL/Post体)，如果它们匹配，那么响应数据将被修改。
In your site's case, you'll want to look at the body of the POST to http://h30405.www3.hp.com/print/start and the corresponding response.
在您的站点的案例中，您将希望查看POST的主体，以http://h30405.www3.hp.com/print/start和相应的响应。
#3
7
Actually, it's worse than might seem. The XSS filter can make safe sites unsafe. Read here: http://www.h-online.com/security/news/item/Security-feature-of-Internet-Explorer-8-unsafe-868837.html
事实上，这比看起来更糟糕。XSS过滤器可以使安全的站点不安全。阅读:http://www.h online.com/security/news/item/security -功能-互联网浏览器- 8 -安全- 868837. - html
From that article:
从这篇文章:
However, Google disables IE's XSS filter by sending the X-XSS-Protection: 0 header, which makes it immune.
然而，谷歌通过发送X-XSS-Protection: 0头，使它不受攻击，从而使其不受影响。
I don't know enough about your site to judge if this may be a solution, but you can probably try. More in depth, technical discussion of the filter, and how to disable it is here: http://michael-coates.blogspot.com/2009/11/ie8-xss-filter-bug.html
我对你的网站了解的不够多，无法判断这是不是一个解决方案，但你可以试试。更多关于过滤器的技术讨论，以及如何禁用它:http://michael- es.blogspot.com/2009/11/ie8-xss-filter-bug.html。
#1
55
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.
当(一些条件满足时)它会启动，它在查询提交中看到一个字符串，它也在页面中逐字地存在，并且它认为它可能是危险的。
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
http://www.bing.com/search?q=%3Cscript + % 3 d % 22型文本3 e % 2 fjavascript % 22%
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中，我已经成功地破坏了你的Bing页面，所以它会给脚本错误，而弹出的结果位不会起作用。本质上，它提供了一个攻击者，其链接正在被跟踪，以挑选和禁用他不喜欢的部分，甚至可能包括其他与安全相关的措施，比如framebuster脚本。
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͍͔̑̃̽̚.
IE8认为“潜在的危险”是什么?除了这个script标签，还有很多其他的东西。如。更重要的是，它似乎与一组使用文本模式系统(可能是regex)的“危险”模板匹配，而不是像最终解析页面本身那样的HTML解析器。是的,使用IE8浏览器是pař年代̣inͅg HT̈́͜毫升w̧̼̜它̏̔h͙r̿e̴̬g̉̆e͎x͍͔̑̃̽̚。
‘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.
通过查看查询中的字符串，“XSS保护”完全是伪造的。它不能被“固定”;这个概念本身就是有缺陷的。除了在不需要时介入的问题之外，它还不能真正保护你免受最基本的攻击——而且攻击者肯定会在IE8变得更广泛使用的时候解决这些问题。如果你没有正确地逃离HTML输出，你仍然会很脆弱;所有的XSS“保护”必须提供给你的是一种虚假的安全感。不幸的是，微软似乎喜欢这种虚假的安全感;在ASP中也有类似的XSS“保护”。在服务器端也有。
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:
因此，如果你对webapp的创作有了一个线索，并且你已经像一个好男孩一样正确地逃避了HTML的输出，那么你可以通过输出标题来禁用这种不受欢迎的、不可行的、错误的入侵。
X-XSS-Protection: 0
in your HTTP responses. (And using ValidateRequest="false" in your pages if you're using ASP.NET.)
在你的HTTP响应。(如果使用ASP.NET，则在页面中使用ValidateRequest=“false”)。
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?
对于其他所有人来说，他们仍然在PHP中使用字符串，而不需要仔细地编码……好吧，你还是别谈了。不要期望它能真正保护你的用户，但是你的网站已经被破坏了，所以谁会在乎它是否会更坏呢?
To see it in action, visit an AOL Food page and click the "Print" icon just above the story.
要想看到它的作用，请访问AOL的食品页面，点击上面的“打印”图标。
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:
啊，是的，我能看到IE8的突破。不太明显的是，IE在哪里对停止执行的内容进行了攻击……我能看到的唯一一个跨域请求是XSS过滤器的候选项，它是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...
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.
该块参数将继续使用更多的胡言乱语。假设在返回的HTML中有一些东西(巧合?)，并触发了IE8的一个混乱的想法，即XSS的开发是什么样子的。
To fix this, HP need to make the server at h30405.www3.hp.com include the X-XSS-Protection: 0 header.
要解决这个问题，HP需要在h30405.www3.hp.com上创建服务器，包括X-XSS-Protection: 0 header。
#2
25
You should send me (ericlaw@microsoft) a network capture (www.fiddlercap.com) of the scenario you think is incorrect.
你应该给我(ericlaw@microsoft)一个你认为不正确的场景的网络捕捉(www.fiddlercap.com)。
The XSS filter works as follows:
XSS滤波器的工作原理如下:
- Is XSSFILTER enabled for this process?
If yes– proceed to next check If no – bypass XSS Filter and continue loading - 这个过程是否启用了XSSFILTER ?如果是，请继续进行下一个检查，如果没有旁路XSS过滤器并继续加载。
- Is a "document" load (like a frame, not a subdownload)? If yes– proceed to next check If no – bypass XSS Filter and continue loading
- 是一个“文档”加载(像一个框架，而不是一个子下载)?如果是，请继续进行下一个检查，如果没有旁路XSS过滤器并继续加载。
- Is it a HTTP/HTTPS request? If yes– proceed to next check If no – bypass XSS Filter and continue loading
- 它是HTTP/HTTPS请求吗?如果是，请继续进行下一个检查，如果没有旁路XSS过滤器并继续加载。
- Does RESPONSE contain x-xss-protection header? Yes: Value = 1: XSS Filter Enabled (no urlaction check) Value = 0: XSS Filter Disabled (no urlaction check) No: proceed to next check
- 响应是否包含x-xss保护头?Yes:值= 1:XSS过滤器启用(无urlaction检查)值= 0:XSS过滤器禁用(无urlaction检查)不:继续下一个检查。
- Is the site loading in a Zone where URLAction enables XSS filtering? (By default: Internet, Trusted, Restricted) If yes– proceed to next check If no – bypass XSS Filter and continue loading
- 站点是否在URLAction支持XSS过滤的区域中加载?(默认情况下:互联网，受信任的，受限制的)如果是，继续进行下一个检查，如果没有旁路XSS过滤器并继续加载。
- Is a cross site Request? (Referrer header: Does the final (post-redirect) fully-qualified domain name in the HTTP request referrer header match the fully-qualified domain name of the URL being retrieved?) If yes – bypass XSS Filter and continue loading If no – then the URL in the request should be neutered.
- 跨站请求?(Referrer header:在HTTP请求Referrer头中，最终的(后重定向)完全限定域名是否匹配被检索的URL的完全限定域名?)如果是-绕过XSS过滤器并继续加载，如果没有-那么请求中的URL应该是中性的。
- Does the heuristic indicate of the RESPONSE data came from unsafe REQUEST DATA? If yes – modify the response.
- 响应数据的启发式指示是否来自不安全的请求数据?如果是，请修改响应。
Now, the exact details of #7 are quite complicated, but basically, you can imagine that IE does a match of request data (URL/Post Body) to response data (script bodies) and if they match, then the response data will be modified.
现在，#7的确切细节相当复杂，但是基本上，您可以想象IE会对响应数据(脚本主体)进行匹配请求数据(URL/Post体)，如果它们匹配，那么响应数据将被修改。
In your site's case, you'll want to look at the body of the POST to http://h30405.www3.hp.com/print/start and the corresponding response.
在您的站点的案例中，您将希望查看POST的主体，以http://h30405.www3.hp.com/print/start和相应的响应。
#3
7
Actually, it's worse than might seem. The XSS filter can make safe sites unsafe. Read here: http://www.h-online.com/security/news/item/Security-feature-of-Internet-Explorer-8-unsafe-868837.html
事实上，这比看起来更糟糕。XSS过滤器可以使安全的站点不安全。阅读:http://www.h online.com/security/news/item/security -功能-互联网浏览器- 8 -安全- 868837. - html
From that article:
从这篇文章:
However, Google disables IE's XSS filter by sending the X-XSS-Protection: 0 header, which makes it immune.
然而，谷歌通过发送X-XSS-Protection: 0头，使它不受攻击，从而使其不受影响。
I don't know enough about your site to judge if this may be a solution, but you can probably try. More in depth, technical discussion of the filter, and how to disable it is here: http://michael-coates.blogspot.com/2009/11/ie8-xss-filter-bug.html
我对你的网站了解的不够多，无法判断这是不是一个解决方案，但你可以试试。更多关于过滤器的技术讨论，以及如何禁用它:http://michael- es.blogspot.com/2009/11/ie8-xss-filter-bug.html。