【问题标题】:Simpler solution against CSRF?针对 CSRF 的更简单解决方案?
【发布时间】:2012-08-31 04:02:43
【问题描述】:

我一直在考虑Same Origin PolicyCSRF,无法回答自己为什么网络浏览器开发人员不使用更简单的解决方案。

除了禁止跨域脚本之外,为什么它们不能允许对任何站点的任何访问,但使用一个空的 cookie jar? (或者更确切地说,一个只包含当前域的 cookie 的 cookie jar)

任何标签(img、脚本等)都一样

如果任何访问都没有 cookie,那么 CSRF 可以做什么?

【问题讨论】:

    标签: browser web security csrf


    【解决方案1】:

    关于仅包含当前域 cookie 的 cookie jar:当前域的 cookie 可能包含例如会话信息。然后可以通过网络发送此信息并导致会话劫持(例如)。

    即使脚本没有 cookie 信息,网站上也可能存在其他敏感信息,可能通过 DOM 可见。然后可以跨域上传此信息。

    另一方面,我认为同源策略实际上并不能阻止恶意黑客。正如您所说,img 和脚本可以发出请求。我可以运行一个返回 404 的服务器,但会保留 GET 请求的日志(例如:maliciouswebsitehere.com/fake404.html?bankaccountnumber=34398439843983&otherinformation=blah)

    【讨论】:

    • “网站上可能还有其他敏感信息”...怎么可能?如果网站上有任何信息,则该信息不会是私人的……如果有人提出请求,您将获得相同的信息。至于您的 Fake404.html 示例,我不明白您的意思。这如何用于 CSRF?或任何恶意活动?
    • 你假设当前页面的所有敏感信息都在cookies中,如果cookies在跨域请求时无法访问,那么没有问题对吧?我不认为这是真的。这是一个示例:想象以管理员身份使用员工电子邮件/SSN/其他任何内容登录到内部网。为了管理员的方便,该页面上还有 engadget.com 新闻。如果有人在 engadget 上植入 XSS 攻击,管理员的页面(带有敏感信息)可以被抓取并跨域发送 - 不涉及 cookie
    猜你喜欢
    • 2010-09-05
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2016-02-13
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多