点击 Get跨域数据安全风险检查清单|json|xss|跨域

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

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

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

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

什么是跨域？

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

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

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

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

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

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

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

Jsonp

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

1.显性Jsonp劫持

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

只要受害者访问攻击者构造的页面，攻击者就能利用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）。跨源的图像或媒体，使用、和标签跨域请求。属于以下几种文档类型的：使用 createDocument() 创建的文档、通过data协议生成的文档重定向跨域请求时。使用iframe标签，并且 sandbox 属性没有设置 allow-same-origin 。响应（response）是网络错误时。

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

iframe> </code> 3.Origin限制绕过当一个API跨域访问时，如果Origin限制不严格，将很容易被攻击者绕过，泄露敏感信息。如下案例所示，当某获取订单信息的接口使用了CORS跨域技术： <img src="http://dingyue.ws.126.net/2022/1220/ce7e61c7j00rn68070035d200u00065g00u00065.jpg"> 修改Origin后，响应头中的Origin没有变化，说明服务端对Origin是有校验的。 <img src="http://dingyue.ws.126.net/2022/1220/5b93f2b9j00rn68080032d200u0005ig00u0005i.jpg"> 攻击者经过测试，发现可以通过添加子域名的方式：http://www.test.com.evil.com，以绕过服务端对Origin的校验。 <img src="http://dingyue.ws.126.net/2022/1220/947538b0j00rn68090030d200u0005ng00u0005n.jpg"> 那么攻击者就可以通过使用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：编程语言）来进行跨域请求。 <img src="http://dingyue.ws.126.net/2022/1220/e5ec2d7aj00rn680a006fd200u00088g00u00088.jpg"> <img src="http://dingyue.ws.126.net/2022/1220/38fa9849j00rn680c000td200u00086g00g2004d.jpg"> 如图，search.xxx.com的输入框存在Xss漏洞，此时攻击者就可以通过输入框引入js，去跨域请求www.xxx.com/userInfo.php。poc如下： <code>// evil.js fetch("http://www.xxx.com:8099/userInfo.php").then((res) => {return res.json(); }).then((data) => { console.log(data); alert(JSON.stringify(data)); }) </code> <img src="http://dingyue.ws.126.net/2022/1220/9c500210j00rn680c002id200u0006rg00u0006r.jpg"> Crossdomain.xml 在flash 10版本后，如果flash有跨域访问的需求，就必须在目标域的根目录下放置Crossdomain.xml文件。该文件限制了flash是否可以跨域读写数据以及允许从什么地方跨域读写数据。但如果Crossdomain.xml配置不当，网站就很容易存在安全漏洞。如Crossdomain允许任意域、Crossdomain域名未注册等。1.Crossdomain允许任意域当Crossdomain.xml为如下配置时，网站会允许任意域访问： <code><?xml version="1.0"?> <cross-domain-policy> <allow-access-from domain="*" /> </cross-domain-policy> </code> 如果某个站点（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如下配置： <img src="http://dingyue.ws.126.net/2022/1220/d6ff7c02p00rn680c000vd200nu003ig00nu003i.png"> xxxtest.com的域名没有还被注册。此时攻击者就可以通过注册xxxtest.com的域名，跨域获取xxx.com下的数据。 Iframe 在开发中，为了实现功能的简单复用，开发者会把需要复用的组件写成单独的页面挂到一个域名下，其他项目采用iframe的方式去加载该页面。iframe标签可以不受同源策略限制，进行跨域。但是当网站存在Xss漏洞或者配置不当时，就很容易被窃取敏感数据。1.document.domain跨子域如下案例，http://www.test.com/userinfo会返回当前用户的姓名及手机号，通常来说，攻击者可以使用http://www.test.com下的Xss漏洞来访问该API，以窃取用户的敏感信息。 <img src="http://dingyue.ws.126.net/2022/1220/69f45e7bj00rn680d002gd200u0006zg00u0006z.jpg"> <img src="http://dingyue.ws.126.net/2022/1220/1894dc91j00rn680d003td200sg00agg00sg00ag.jpg"> 但这里开发者使用了document.domain，将域设置为了test.com，导致攻击面扩大到了test.com下的任意一个子域名。 <img src="http://dingyue.ws.126.net/2022/1220/a2c39271j00rn680e000kd2009n004rg009n004r.jpg"> 因此，攻击者可以使用任意一个子域名http://*.test.com的Xss漏洞，就能访问到该API，从而窃取到用户的敏感信息。 <img src="http://dingyue.ws.126.net/2022/1220/c201e835j00rn680f003rd200sg009fg00sg009f.jpg"> 2.window.name固定由于window.name一旦设置完成，就是固定信息，无论iframe的src怎么变化，window.name都不会改变。如果一个页面在window.name存放了敏感数据，攻击者就可以通过iframe加载该页面获取到敏感数据。如图案例所示，某页面在window.name中存放了敏感数据。 <img src="http://dingyue.ws.126.net/2022/1220/da127afbj00rn680f0018d200g8009gg00g8009g.jpg"> 攻击者可通过iframe加载该页面，等待其往window.name中存放敏感数据，然后获取iframe的window.name。 <img src="http://dingyue.ws.126.net/2022/1220/ab3d027fj00rn680g001fd200cs00cgg00cs00cg.jpg"> 因为有同源策略的限制，攻击者暂时是无法获取到的。 <img src="http://dingyue.ws.126.net/2022/1220/c6e7beabj00rn680h000wd200my0084g00my0084.jpg"> 但攻击者可以通过iframe.contentWindow.location让iframe跳转到与iframe外同域的页面，使网页同源。 <img src="http://dingyue.ws.126.net/2022/1220/c47e3ac6j00rn680h0026d200hg00exg00hg00ex.jpg"> 即可获取到window.name中存放的敏感数据。 <img src="http://dingyue.ws.126.net/2022/1220/41a7fc67j00rn680i001dd200b40087g00b40087.jpg"> 3.window.postMessage伪造数据发送端window.PostMeaage是HTML5提供的一个跨域解决方案。可以绕过同源策略，实现不同域之间的window对象通信。但当数据接收端为如下配置时，如果开发者没有对数据来源进行校验，且也没有对接收的数据做出处理，将很容易存在安全隐患。 <code># 子页面 res.html <div> </div> <script> window.onload = function () { var messageEle = document.getElementById('message'); window.addEventListener('message', function (e) { messageEle.innerHTML = e.data; }); } </script> </code> <code># 父页面 evil.html DOCTYPE HTML> <html><body> <iframe src="http://127.0.0.1:8081/res.html" width="500" height="60" id="receiver">