bhaveshk90/Content-Security-Policy-CSP-Bypass-Techniques

# 内容安全策略 (CSP) 绕过技术 内容安全策略 (CSP) 绕过技术  # 什么是 CSP ? CSP 代表内容安全策略，这是一种定义网页可以获取或执行哪些资源的机制。换句话说，可以将其理解为一种策略，用于决定可以从不同位置在特定页面上调用或执行哪些脚本、图像、iframe。内容安全策略通过响应头或 HTML 页面的 meta 元素实现。此后，浏览器将遵循该策略，并在检测到违规时主动阻止。 # 为什么使用它? 内容安全策略广泛用于保护 Web 应用程序免受内容注入（如跨站脚本攻击）。此外，通过使用 CSP，服务器可以指定允许使用的协议。我们可以将 CSP 视为 XSS 的缓解措施吗？答案是否定的！CSP 是针对内容注入攻击的额外安全层。第一道防线始终是输出编码和输入验证。成功的 CSP 实施不仅可以保护网页免受这些漏洞的侵害，还可以提供被 CSP 本身阻止（即未成功）的各种攻击细节。Web 管理员可以受益于此功能，从而发现潜在的错误。 # 它是如何工作的? CSP 通过限制活动内容和被动内容的加载来源来工作。它还可以额外限制活动内容的某些方面，例如内联 JavaScript 的执行以及 eval() 的使用。 如果您是开发人员，您将需要为网站使用的每种类型的资源定义所有允许的来源。假设您是 abc.com 网站的所有者，并且该网站从 localhost 以及其他不同来源（例如 allowed.com）加载多种资源，如脚本、图像、CSS。一个非常基本的策略是： # 通过响应头实现： ```Content-Security-policy: default-src 'self'; script-src 'self' allowed.com; img-src 'self' allowed.com; style-src 'self';``` # 通过 meta 标签实现： `````` 现在您可能有一个问题，什么是 **default-src**，**img-src**，**style-src** 和 **script-src**。这些是 CSP 的指令。只有使用指令才能正确实施内容策略。以下是一些常见 CSP 指令的列表： ``` script-src : This directive specifies allowed sources for JavaScript. This includes not only URLs loaded directly into : This will not-allowed on the page. But why? Because inline-src is set to self. But Wait! where the hell it is mentioned? I can't see inline-src defined in above CSP at all. The answer is have you noticed default-src 'self'? So even other directives are not defined but they will be following default-src directive value only. ``` 以下是指令列表，即使未在策略中定义，它们也将遵循 default-src 的值： ``` child-src connect-src font-src frame-src img-src manifest-src media-src object-src prefetch-src script-src script-src-elem script-src-attr style-src style-src-elem style-src-attr worker-src ``` 我们对内容安全策略指令及其资源有了相当的了解。还有一件重要的事情我们需要知道。每当 CSP 限制任何无效源加载数据时，如果策略中定义了以下指令，它可以向网站管理员报告该事件： ``` Content-Security-Policy: default-src 'self'; img-src https://*; child-src 'none'; report-uri /Report-parsing-url; ``` 管理员可以跟踪攻击者使用哪种攻击脚本或技术从不受信任的资源加载恶意内容。现在，让我们进入有趣的部分 **绕过技术**： 正确分析 CSP 策略。有一些在线工具非常有帮助。 ``` 1. https://csp-evaluator.withgoogle.com/ 2. https://cspvalidator.org/ ``` 以下是它们如何评估并提供结果的屏幕截图。  **场景 : 1** ``` Content-Security-Policy: script-src https://facebook.com https://google.com 'unsafe-inline' https://*; child-src 'none'; report-uri /Report-parsing-url; ``` 通过观察此策略，我们可以说它非常脆弱，并且也将允许内联脚本。其背后的原因是使用了 unsafe-inline 源作为 script-src 指令的值。 **有效载荷**: "/> **场景 : 2** ``` Content-Security-Policy: script-src https://facebook.com https://google.com 'unsafe-eval' data: http://*; child-src 'none'; report-uri /Report-parsing-url; ``` 这也是一个配置错误的 CSP 策略，因为使用了 unsafe-eval。 **有效载荷** : **场景 : 3** ``` Content-Security-Policy: script-src 'self' https://facebook.com https://google.com https: data *; child-src 'none'; report-uri /Report-parsing-url; ``` 这也是一个配置错误的 CSP 策略，因为在 script-src 中使用了通配符。 ***有效载荷*** : `` "/>'> "/>'> `` **场景: 4** ``` Content-Security-Policy: script-src 'self' report-uri /Report-parsing-url; ``` 又是配置错误的 CSP 策略！我们可以看到这里缺少 object-src 和 default-src。 **有效载荷** : ``` ">'> ``` **场景:** 5 ``` Content-Security-Policy: script-src 'self'; object-src 'none' ; report-uri /Report-parsing-url; ``` 我们看到 object-src 设置为 none，但是是的，这个 CSP 也可以被绕过以执行 XSS。如何做？如果应用程序允许用户将任何类型的文件上传到主机。攻击者可以上传任何恶意脚本并在任何标签内调用。 **有效载荷** : ``` "/>'> ``` **场景** : 6 ``` Content-Security-Policy: script-src 'self' https://www.google.com; object-src 'none' ; report-uri /Report-parsing-url; ``` 在这种情况下，script-src 设置为 self 和列入白名单的特定域，可以使用 [jsonp](https://github.com/zigoo0/JSONBee) 绕过。jsonp 端点允许不安全的回调方法，允许攻击者执行 xss。 **有效载荷** : ``` "> ``` **场景** : 7 ``` Content-Security-Policy: script-src 'self' https://cdnjs.cloudflare.com/; object-src 'none' ; report-uri /Report-parsing-url; ``` 在这种情况下，script-src 设置为 self 和列入白名单的 javascript 库域。可以使用该库中任何易受攻击的 javascript 文件版本来绕过它，这允许攻击者执行 xss。 **有效载荷** : ``` "> ">