IE 中的 XSS - 绕过方法？

发布于 2024-11-05 21:46:17 字数 117 浏览 1 评论 0原文

既然 IE 8 有 XSS 过滤器，那么真的没有办法使用该浏览器来利用 XSS 漏洞吗？例如，cookie 窃取者不再对我的网站构成威胁？

（如果您认为这是不正确的并且您的过滤器可能存在缺陷，我想知道）

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

习惯那些不曾习惯的习惯 2024-11-12 21:46:17

IE8 中的 XSS-Filter 肯定可以被击败。是否可能取决于页面中的XSS-Vuln。
例如，您可以使用奇怪的编码或双重 XSS 攻击。
编辑：
这是一个可以通过 IE8 过滤器的 XSS 攻击的野外示例：
esrb.org 上的 XSS

回复收藏 0 原文

红颜悴 2024-11-12 21:46:17

即，基本 XSS 过滤器通过首先检查请求的生成位置来处理传出请求。我的意思是，对于反射型 XSS，请求可能是从攻击者系统生成的，以便放置恶意脚本。所以通过扩展
查看来自同一域的请求是没有意义的，因为这会浪费资源。

然而 IE 做出了一个错误的假设，XSS 可以来自任何地方、任何地方。
由于这种错误的假设，反射型 XSS 漏洞可能会被利用。 IE 已考虑“location:”HTTP 标头重定向以及
元刷新 HTML 标签。然而，还有其他可用于攻击的重定向方法。

现在让我们假设在我们的目标应用程序中发现了一个直接的 XSS 漏洞
xss.php 文件：

<?php
//xss.php
print $_GET['var'];
?>

假设在 redir.php 文件中发现 OWASP a10 违规。

<?php
//redir.php
print “<script>”;
print “document.location='”.htmlspecialchars($_GET['redir'],ENT_QUOTES).”'”;
print “</script>”;
?>

此类应用程序的概念验证漏洞如下：

http://abc.com/redir.php?redir=http%3A%2F%2Fabc.com%2Fxss.php%3Fvar%3D%253Cscript
%253Ealert%2528%2Fxss%2F%2529%253C%2Fscript%253E

上述链接可能来自任何地方，包括 url 收缩服务。 XSS 有效负载是“var”GET 变量。 PoC 的这一部分已经过双重 url 编码。这里有一个尖括号“>”变为“%253E”。这种编码欺骗了服务器上的 htmlspecialchars() 以及 IE 的过滤器。此编码的有效负载不受对 htmlspecialchars() 调用的影响，并且在不存在该负载的情况下也会以相同的方式运行。

Ie basic XSS filter processes the outgoing request by first checking where the request is been generated.I mean for a reflective XSS the request may be generating from attackers system in order do put malicious script. So by extension
there should be no point in looking at requests that originate from the same domain as this would be a waste of resources.

However IE is making an incorrect assumption, XSS can come from anywhere and there for any
reflective XSS vulnerability can become exploitable due to this incorrect assumption. IE has taken “location:” HTTP header redirects into consideration as well as
meta refresh HTML tags. There are however other redirection methods which can be used in an attack.

Now let us assume there is a straight forward XSS vulnerability in our target application found in the
xss.php file:

<?php
//xss.php
print $_GET['var'];
?>

Assume OWASP a10 violation found in the redir.php file.

<?php
//redir.php
print “<script>”;
print “document.location='”.htmlspecialchars($_GET['redir'],ENT_QUOTES).”'”;
print “</script>”;
?>

The Proof of Concept exploit for an application like this is as follows:

http://abc.com/redir.php?redir=http%3A%2F%2Fabc.com%2Fxss.php%3Fvar%3D%253Cscript
%253Ealert%2528%2Fxss%2F%2529%253C%2Fscript%253E

Above link could originate from anywhere, including a url shrinking services . The XSS payload is the “var” GET variable. This part of the PoC has been double url encoded. There for an angled bracket “>” becomes “%253E”. This is encoding fools both the htmlspecialchars() on the server as well as IE's filter. This encoded payload is unaffected by the call to htmlspecialchars() and would behave in the same way with its absence.

回复收藏 0 原文