跨站脚本攻击和同源策略

发布于 2024-11-28 15:24:02 字数 547 浏览 0 评论 0原文

我熟悉持久性和非持久性XSS。 我还知道同源策略,它可以防止/限制来自一个网站页面的请求前往另一个网站服务器。这让我认为同源策略至少可以阻止非持久性类型的XSS攻击(因为在持久性类型的攻击中,恶意代码的来源将与被盗的私人信息相同)。 我的理解正确吗? SOP 可以用来阻止/减少这些攻击吗?

编辑:好的,我对浏览器端两个脚本之间的调用方法和另一个网站上的 HTTP POST 等方法的调用感到困惑。谢谢杰克伯的回答。

现在我还有一个问题,SOP 不能防止跨站请求伪造吗? 维基百科中给出的示例讲述了 Bob 访问 Mallory 在聊天论坛上创建的恶意图像标签。然而,根据 SOP 规则,恶意脚本不应该能够访问银行的 cookie。我在这里错过了什么吗?

I am familiar with the persistent and non-persistent XSS.
I also know about Same origin policy that prevents/restricts requests originating from one websites page to go to another websites servers. This made me think that the same origin policy can stop at least the non-persistent type of XSS attacks (Because in the persistent type of attack the malicious code origin would be same as the private information that is stolen).
Is my understanding correct? Can SOP be used to stop/reduce these attacks?

EDIT: Okay I was confusing between invoking methods between 2 scripts at the browser side and invoking methods such as HTTP POST on another website. Thank you for the answer jakber.

Now I have another question, wouldn't SOP be able to prevent Cross-site request forgery?
The example given in the wikipedia talks about Bob accessing a malicious image tag created by Mallory on the chat forum. However, as per the SOP rule, the malicious script should not be able to access bank's cookie. Am I missing something here?

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

扫码二维码加入Web技术交流群

发布评论

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

评论(2

森林迷了鹿 2024-12-05 15:24:02

通常不会。

非持久性或反射型 XSS 攻击利用未经适当清理而作为页面内容回显的输入,也不会持久化它。在这两种情况下,注入的脚本似乎都来自被利用的域。

例如,如果您在 PHP 中执行此操作: echo $_GET['param'] 并将指向该页面的链接发送给包含以下内容的人
?param=
这是一种非持久性XSS攻击,与同源策略无关。

同源意味着你不能直接注入脚本或修改其他域上的 DOM:这就是为什么你需要首先找到 XSS 漏洞。

Typically no.

A non-persistant or reflected XSS attack exploits input that is echoed back as page content without proper sanitization, without persisting it. The injected script will seem to come from the exploited domain in both cases.

For example if you do this in PHP: echo $_GET['param'] and send a link to the page to somebody containing
?param=<script>alert('got you!');</script>
it is a non-persistant XSS attack, and same-origin policy has nothing to do with it.

Same-origin means that you cannot directly inject scripts or modify the DOM on other domains: that's why you need to find an XSS vulnerability to begin with.

甩你一脸翔 2024-12-05 15:24:02

SOP 通常无法防止 XSS 或 CSRF。

对于XSS,jakber的回答已经提供了很好的解释。我只想补充一点,之所以将此漏洞称为“跨站”,是因为攻击者可以将代码(例如

对于CSRF,大多数情况下SOP无法阻止,因为SOP并不能阻止网站A向网站B发送GET和POST请求。

SOP typically cannot prevent either XSS or CSRF.

For XSS, jakber's answer already provides a good explanation. I just want to add that the reason to call this vulnerability "cross-site" is because the attacker can inject code (e.g. <script src="...">) into the target page that loads malicious javascript from another website, which is typically controlled by the attacker. Loading Javascript from another website is not denied by SOP, because doing that will break the Web.

For CSRF, SOP cannot prevent it for most cases because SOP does not prevent website A to send GET and POST requests to website B.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文