Web 的安全模型植根于同源策略。 https://mybank.com 中的代码应该只能访问 https://mybank.com 的数据,并且绝对不应该允许 https://evil.example.com 访问。每个来源都与网络的其余部分隔离,为开发人员提供了一个安全的沙箱,可以在其中构建和执行业务逻辑。这个从理论上讲是一个安全的系统,但是在实践中,攻击者已经找到了颠覆系统的巧妙方法。
例如,跨站点脚本 (XSS) 攻击,通过诱使站点与预期内容一起提供恶意代码来绕过同源策略。这是一个巨大的问题,因为浏览器相信页面上显示的所有代码都是该页面安全来源的合法部分。 XSS 备忘单 包含了一些常见的 XSS 攻击方式,推荐大家阅读。
如果攻击者成功注入代码,那么可能导致灾难性的后果:用户会话数据被泄露,本应保密的信息被泄露给恶意攻击者。
内容安全策略 (CSP)是一种可以显着降低现代浏览器中 XSS 攻击的风险和影响的防御措施。
Source allowlists
XSS 攻击利用的问题是浏览器无法区分应用程序中的脚本和第三方恶意注入的脚本。例如,Chrome 官网的开发人员在首页设计了一个按钮,点击之后,会执行来自 https://apis.google.com/js/plusone.js 的代码。Chrome 官网的开发人员当然信任这个 plusone.js
文件里的代码,但我们不能指望浏览器自身智能地
信任来自 apis.google.com 的代码,而来自诸如 apis.evil.example.com
的代码。
对于这两个 side 的代码,浏览器会一视同仁,下载并执行。
CSP 不是盲目地信任服务器提供的所有内容,而是定义了 Content-Security-Policy HTTP
标头,它允许创建受信任内容源的允许列表,并指示浏览器仅执行或呈现来自这些源的资源。即使攻击者可以找到注入脚本的漏洞,该脚本也不会匹配白名单,因此不会被执行。
由于我们相信 apis.google.com 能够提供有效的代码,并且我们相信自己也会这样做,因此让我们定义一个策略,只允许脚本在来自这两个来源之一时执行:
Content-Security-Policy: script-src 'self' https://apis.google.com
网友评论