文章总结: 这篇文章介绍了CORS跨域资源共享漏洞的原理和相关HTTP头部配置,详细解释了Access-Control-Allow-Origin等关键头部的作用,并提供了判断CORS漏洞的标准,包括高危漏洞场景如可控Origin配合Credentials为true,以及低危配置错误情况。文章还指出了常见的CORS安全配置误区,为安全测试人员提供了实用的漏洞检测指南。 综合评分: 87 文章分类: WEB安全,漏洞分析,渗透测试
web漏洞之CORS跨域资源共享漏洞
原创
信安路漫漫
信安路漫漫
2025年12月16日 07:00 上海
Cross-origin Resource Sharing 中文名称 “跨域资源共享” 简称 “CORS”,它突破了一个请求在浏览器发出只能在同源的情况下向服务器获取数据的限制。
CORS 相关 HTTP 头部
CORS 主要依赖服务器端的 HTTP 头部来进行配置。以下是常见的 CORS 相关头部字段及其作用:
Access-Control-Allow-Origin:指定哪些源(域)可以访问资源。可以是单个源,或者是 *(允许所有源)。
Access-Control-Allow-Methods:指定允许的 HTTP 方法(如 GET, POST, PUT, DELETE 等)。
Access-Control-Allow-Headers:指定允许的请求头字段。
Access-Control-Allow-Credentials:指示是否允许发送凭据(如 cookies)到跨域资源。
Access-Control-Expose-Headers:允许客户端访问特定的响应头。
Access-Control-Max-Age:指示预检请求的有效期,即多少秒内无需再次发送预检请求。
1 Access-Control-Allow-Origin
作用:指定哪些源(域)可以访问该资源。可以是单个域名,也可以是 *,表示允许所有来源。
值:
单个域名:Access-Control-Allow-Origin:
允许所有来源:Access-Control-Allow-Origin: *
如果允许的来源是动态的,服务器可以根据请求的 Origin 动态返回允许的域名。
2 Access-Control-Allow-Methods
作用:指定允许的 HTTP 请求方法。
常见值:GET, POST, PUT, DELETE, PATCH
3 Access-Control-Allow-Headers
作用:指定哪些请求头字段可以包含在实际请求中。例如,某些自定义请求头,如 X-Custom-Header,需要通过这个字段允许。
示例:Access-Control-Allow-Headers: Content-Type, X-Custom-Header
4 Access-Control-Allow-Credentials
作用:指示是否允许发送凭据(如 cookies)。如果设置为 true,表示跨域请求中可以发送 cookies。
值:true 或 false。
注意:当设置为 true 时,Access-Control-Allow-Origin 不能为 *,必须指定具体的域名。
5 Access-Control-Expose-Headers
作用:允许浏览器访问指定的响应头。默认情况下,浏览器只会暴露某些标准的响应头,使用该字段可以暴露其他自定义的头部。
示例:Access-Control-Expose-Headers: X-Response-Time
6 Access-Control-Max-Age
作用:指定预检请求的有效期(单位为秒)。在此期间,浏览器不会再次发送预检请求。
示例:Access-Control-Max-Age: 3600 表示预检请求的结果有效期为 1 小时。
1 简单请求(Simple Requests)
简单请求是指那些符合以下条件的跨域请求:
请求方法是 GET、POST 或 HEAD;
请求头部只包含以下字段之一:Accept、Content-Type(只限 application/x-www-form-urlencoded、multipart/form-data 和 text/plain),Authorization 等常见字段。
对于这种请求,浏览器会直接发送请求到服务器,并且不发送预检请求。
2 预检请求(Preflight Request)
如果跨域请求方法是 PUT、DELETE、PATCH,或者请求中包含自定义的 HTTP 头部(如 X-Custom-Header),浏览器首先会发送一个 OPTIONS 请求来询问服务器是否允许跨域请求。该请求被称为“预检请求”。服务器需要在响应中包含允许跨域访问的标识,浏览器才会继续发送实际的请求。
注意事项
1)服务器可以通过返回该头部来明确哪些域名被允许跨域访问。可以指定单一域名(如),或者使用通配符 * 允许所有域名访问,但通配符不能与带凭证的请求(如 cookies 或 Authorization 头部)一起使用,也不能与 credentials: ‘include’ 一起使用。
2)当浏览器携带凭证(如 cookies 或 Authorization)发起跨域请求时,服务器需要在响应中设置 Access-Control-Allow-Credentials: true,并且 Access-Control-Allow-Origin 不能使用通配符(*),必须指定明确的域名。
3)浏览器限制了从脚本内发起的跨源 HTTP 请求,例如 XMLHttpRequest 和我们本示例中使用的Fetch API都是遵循的同源策略。当一个请求在浏览器端发送出去后,服务端是会收到的并且也会处理和响应,只不过浏览器在解析这个请求的响应之后,发现不属于浏览器的同源策略(地址里面的协议、域名和端口号均相同)也没有包含正确的 CORS 响应头,返回结果被浏览器给拦截了。
CORS跨域共享漏洞的测试方式
常规的CORS漏洞测试过程:抓取一个能够返回个人敏感数据的HTTP请求包,添加Origin:,查看返回头中是否包含“Access-Control-Allow-Origin: *”、“Access-Control-Allow-Credentials: true”。
常规我们认为返回结果只要包含了Access-Control-Allow-Origin: *就是存在漏洞,但是看了下面文章的测试(),可能不是这样,本人没有测试,感兴趣的可以实际测试一下,下面把文章的结果摘录一下。
1 如果返回头是以下情况,那么就是高危漏洞,这种情况下漏洞最好利用:
Access-Control-Allow-Origin: https://www.attacker.com
Access-Control-Allow-Credentials: true
如下,配置了Access-Control-Allow-Origin,但是Access-Control-Allow-Origin可控
2 如果返回头是以下情况,那么也可以认为是高危漏洞,只是利用起来麻烦一些:
Access-Control-Allow-Origin: null
Access-Control-Allow-Credentials: true
3 如果返回以下,则不存在漏洞,因为Null必须是小写才存在漏洞:
Access-Control-Allow-Origin: Null
Access-Control-Allow-Credentials: true
4 如果返回以下,可认为不存在漏洞,因为CORS安全机制阻止了这种情况下的漏洞利用,也可以写上低危的CORS配置错误问题。
Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true
5 如果返回以下,可认为不存在漏洞,也可以写上低危的CORS配置错误问题。
Access-Control-Allow-Origin: *
参考链接
https://blog.csdn.net/Stromboli/article/details/143749708
https://zhuanlan.zhihu.com/p/210244307
https://blog.csdn.net/qq_50854662/article/details/128544614
查看原文:《web漏洞之CORS跨域资源共享漏洞》
版权声明
本站仅做备份收录,仅供研究与教学参考之用。
读者将信息用于其他用途的,全部法律及连带责任由读者自行承担,本站不承担任何责任。










评论