#渗透测试#网络安全# 一文了解什么是跨域CROS！！！

免责声明本教程仅为合法的教学目的而准备，严禁用于任何形式的违法犯罪活动及其他商业行为，在使用本教程前，您应确保该行为符合当地的法律法规，继续阅读即表示您需自行承担所有操作的后果，如有异议，请立即停止本文章读。

一、什么是CORS

跨域请求的背景

CORS的工作原理

CORS的实现

总结

二、CORS预检请求的详细流程解析

预检请求的触发条件

预检请求的详细流程

示例代码

总结

三、CORS预检请求的安全性分析

四、服务器响应CORS预检的配置方法

五、CORS预检请求常见错误排查

六、CORS配置不当导致的安全漏洞案例

案例一：Access-Control-Allow-Origin设置为*

案例二：Access-Control-Allow-Credentials设置为true

案例三：Access-Control-Allow-Origin设置为请求头中的Origin字段

七、如何避免CORS配置不当导致的安全漏洞

八、如何检测CORS配置的安全性？

方法一：手动测试

方法二：使用自动化工具

方法三：参考安全最佳实践

一、什么是CORS

CORS（Cross-Origin Resource Sharing，跨域资源共享）是一种用于在浏览器中处理跨域资源访问的机制。当一个网页尝试从一个源请求获取资源，而该资源的服务器与网页所在的源不同时，就会涉及到跨域请求。CORS通过在HTTP请求头中添加一些特定的字段信息来进行通信，以告知服务器是否支持跨域请求，从而使得网页能够在受限的情况下安全地进行跨域资源访问。

跨域请求的背景

在默认情况下，浏览器的同源策略会限制跨域请求，即只允许网页从同一域名下获取数据。这是为了保护用户的安全和隐私。然而，在某些情况下，我们希望网页能够跨域请求并获取其他域名下的资源，这时就需要使用CORS来解决跨域问题。

CORS的工作原理

CORS通过在HTTP请求头中添加一些特定的字段信息来进行通信。具体来说，当网页发送跨域请求时，浏览器会自动发送一个预检请求（OPTIONS请求）给服务器，该请求包含了一些额外的头信息，如Origin（标识发起请求的源）、Access-Control-Request-Method（请求方法）、Access-Control-Request-Headers（请求头）等。服务器收到预检请求后，根据请求头中的信息，决定是否允许该跨域请求。

如果服务器确认允许，就会在响应头中添加一些字段信息，如Access-Control-Allow-Origin（指定允许的源）、Access-Control-Allow-Methods（指定允许的请求方法）、Access-Control-Allow-Headers（指定允许的请求头）等。

CORS的实现

CORS的实现主要包括一些客户端的工作以及两类服务端的处理。服务端需要对满足以下所有条件的HTTP请求做出相应的CORS回应：

如果Origin被服务端允许，服务端返回请求是带有Access-Control-Allow-Origin头，并且这个头部信息的值和客户端Origin的值保持一致；否则就表示不被允许。
如果Access-Control-Allow-Origin被设置成*，则意味着任何Origin都被允许。注意：如果所访问的资源需要凭证，那么Access-Control-Allow-Origin则不应该被设置为*，而且Access-Control-Allow-Credentials头需要被设置成true。

总结

CORS是一种用于在浏览器中处理跨域资源访问的机制，它通过在HTTP请求头中添加一些特定的字段信息来进行通信，以告知服务器是否支持跨域请求。CORS的实现主要包括客户端和服务器端的工作，通过设置特定的HTTP头来控制浏览器是否允许跨域请求。

二、CORS预检请求的详细流程解析

CORS（Cross-Origin Resource Sharing，跨域资源共享）是一种用于在浏览器中处理跨域资源访问的机制。当一个网页尝试从一个源请求获取资源，而该资源的服务器与网页所在的源不同时，就会涉及到跨域请求。为了确保跨域请求的安全性，浏览器会在发送实际请求之前，先发送一个预检请求（OPTIONS请求），以确认服务器是否允许该跨域请求。

预检请求的触发条件

预检请求并不是每次跨域请求都会触发，而是满足以下条件之一时才会触发：

请求方法：如果请求方法不是GET、POST、HEAD这三种之一，就会触发预检请求。例如PUT、DELETE等方法的请求会触发预检请求。
自定义头字段：当请求包含自定义头字段时，会触发预检请求。例如在请求中设置了自定义的头信息如test:test，就会触发预检请求。
特定MIME类型的POST请求：对于搭配某些MIME类型的POST请求（非Content-Type为特定三种类型的POST请求）也会触发预检请求。

预检请求的详细流程

发送预检请求：当满足触发条件时，浏览器会自动发送一个OPTIONS请求给服务器。该请求包含了一些额外的头信息，如Origin（标识发起请求的源）、Access-Control-Request-Method（请求方法）、Access-Control-Request-Headers（请求头）等。

服务器处理预检请求：服务器接收到预检请求后，会根据请求头中的信息，决定是否允许该跨域请求。如果允许，服务器会在响应头中添加一些字段信息，如Access-Control-Allow-Origin（指定允许的源）、Access-Control-Allow-Methods（指定允许的请求方法）、Access-Control-Allow-Headers（指定允许的请求头）等。

浏览器处理预检请求的响应：浏览器接收到服务器的响应后，会检查响应头中的CORS头信息，以确定是否允许实际请求。如果允许，浏览器才会真正发送实际请求。

发送实际请求：如果预检请求成功，浏览器会发送实际请求。此时，服务器会根据实际请求的内容，返回相应的资源。

示例代码

以下是一个使用fetch API发送跨域请求的示例代码，其中包含了预检请求的触发过程：
// 假设我们请求https://api.github.com/ ，这个接口支持跨域访问 
// 通过添加自定义请求头，来触发预检请求 
var requestOptions = {
  method: 'GET',
  headers: {
    test: 'test' // 自定义的头信息 
  },
  redirect: 'follow'
};
 
fetch('https://api.github.com/',  requestOptions)
  .then(response => response.json()) 
  .then(result => console.log(result)) 
  .catch(error => console.log('error',  error));
在上述代码中，由于添加了自定义头信息，浏览器会先发送一个OPTIONS预检请求，探测服务器是否允许实际的GET请求跨域访问。服务器根据自身的规则返回响应头信息，如果允许跨域，浏览器才会真正发送GET请求。

总结

CORS预检请求是为了确保跨域请求的安全性而设计的一种机制。通过在发送实际请求之前，先发送一个预检请求，浏览器可以确认服务器是否允许该跨域请求，从而避免潜在的安全风险。预检请求的触发条件包括请求方法、自定义头字段和特定MIME类型的POST请求。了解CORS预检请求的详细流程，有助于开发者更好地理解和使用CORS机制，从而实现安全的跨域资源访问。

三、CORS预检请求的安全性分析

CORS（Cross-Origin Resource Sharing，跨域资源共享）是一种用于在浏览器中处理跨域资源访问的机制。为了确保跨域请求的安全性，浏览器会在发送实际请求之前，先发送一个预检请求（OPTIONS请求），以确认服务器是否允许该跨域请求。这种机制虽然提高了跨域请求的安全性，但也带来了一些新的安全风险。

CORS误配置风险：如果服务器对CORS的配置不当，可能会导致未经授权的跨域请求被接受，从而引发安全问题。例如，服务器错误地配置了Access-Control-Allow-Origin为*，允许所有源的跨域请求，这可能会导致敏感信息泄露。

CSRF（跨站请求伪造）风险：攻击者可以利用CORS实现CSRF攻击。例如，恶意网站可以利用CORS请求接口获取用户数据或执行增删改操作。为了防止CSRF攻击，服务器应该在CORS请求中验证Origin头字段，并且在响应中设置合适的Access-Control-Allow-Credentials值。

信息泄露风险：攻击者可以利用CORS的一些特性获取敏感信息。例如，根据CORS头部判断网站架构，根据错误信息判断后台技术栈等。

报文劫持风险：攻击者可以在客户端通过JavaScript劫持CORS报文，改变请求参数、添加非法头部甚至修改响应内容。为了防止报文劫持，服务器应该在响应中设置合适的Content-Security-Policy（CSP）头部。

四、服务器响应CORS预检的配置方法

为了确保CORS预检请求的安全性，服务器需要正确配置响应头信息。以下是一些常见的配置方法：

设置Access-Control-Allow-Origin：该头部指定了允许进行跨域请求的源。例如，设置为https://example.com 表示只允许来自https://example.com 的跨域请求。如果设置为*，表示允许所有源的跨域请求，但需要注意，这样做可能会导致安全风险。

设置Access-Control-Allow-Methods：该头部指定了允许的请求方法。例如，设置为GET, POST, PUT, DELETE表示允许GET、POST、PUT、DELETE四种请求方法。

设置Access-Control-Allow-Headers：该头部指定了允许的请求头。例如，设置为Content-Type, Authorization表示允许Content-Type和Authorization两个请求头。

设置Access-Control-Allow-Credentials：该头部指定了是否允许发送凭据（如Cookies）。如果设置为true，表示允许发送凭据；如果设置为false，表示不允许发送凭据。

设置Access-Control-Max-Age：该头部指定了预检请求的结果可以被缓存的时间。例如，设置为86400表示预检请求的结果可以被缓存一天。

五、CORS预检请求常见错误排查

预检请求未通过：如果服务器拒绝了预检请求，浏览器将不会发送实际请求。此时，可以在浏览器的开发者工具中查看预检请求的响应头信息，检查是否有错误信息。例如，如果服务器没有设置Access-Control-Allow-Origin头部，预检请求将会失败。

实际请求未通过：如果预检请求通过了，但实际请求未通过，可以在浏览器的开发者工具中查看实际请求的响应头信息，检查是否有错误信息。例如，如果服务器没有设置Access-Control-Allow-Credentials头部，实际请求将会失败。

请求头信息错误：如果请求头信息错误，可能会导致预检请求或实际请求失败。例如，如果请求头中包含了不允许的自定义头部，预检请求将会失败。此时，可以检查请求头信息，确保其符合服务器的要求。

服务器配置错误：如果服务器配置错误，可能会导致预检请求或实际请求失败。例如，如果服务器没有正确设置CORS相关的响应头信息，预检请求将会失败。此时，可以检查服务器的配置文件，确保其正确配置了CORS相关的响应头信息。

六、CORS配置不当导致的安全漏洞案例

CORS（Cross-Origin Resource Sharing，跨域资源共享）是一种用于在浏览器中处理跨域资源访问的机制。为了确保跨域请求的安全性，服务器需要正确配置CORS响应头信息。然而，许多开发者由于缺乏对CORS的理解，或者为了方便，往往会错误地配置CORS，从而导致安全漏洞。以下是一些CORS配置不当导致的安全漏洞案例。

案例一：Access-Control-Allow-Origin设置为*

在某些情况下，开发者为了方便，会将Access-Control-Allow-Origin设置为*，表示允许所有源的跨域请求。然而，这种做法可能会导致安全风险。例如，假设有一个网站https://example.com ，它的API接口允许跨域请求，并且Access-Control-Allow-Origin设置为*。此时，如果有一个恶意网站https://malicious.com ，它可以利用JavaScript代码向https://example.com 发送跨域请求，并且可以读取响应内容。这样，恶意网站就可以窃取用户的敏感信息。

案例二：Access-Control-Allow-Credentials设置为true

在某些情况下，开发者为了方便，会将Access-Control-Allow-Credentials设置为true，表示允许发送凭据（如Cookies）。然而，这种做法可能会导致安全风险。例如，假设有一个网站https://example.com ，它的API接口允许跨域请求，并且Access-Control-Allow-Credentials设置为true。此时，如果有一个恶意网站https://malicious.com ，它可以利用JavaScript代码向https://example.com 发送跨域请求，并且可以读取响应内容。这样，恶意网站就可以窃取用户的敏感信息。

案例三：Access-Control-Allow-Origin设置为请求头中的Origin字段

在某些情况下，开发者为了方便，会将Access-Control-Allow-Origin设置为请求头中的Origin字段。然而，这种做法可能会导致安全风险。例如，假设有一个网站https://example.com ，它的API接口允许跨域请求，并且Access-Control-Allow-Origin设置为请求头中的Origin字段。此时，如果有一个恶意网站https://malicious.com ，它可以利用JavaScript代码向https://example.com 发送跨域请求，并且可以读取响应内容。这样，恶意网站就可以窃取用户的敏感信息。

七、如何避免CORS配置不当导致的安全漏洞

不要将Access-Control-Allow-Origin设置为*：除非你确实希望允许所有源的跨域请求，否则不要将Access-Control-Allow-Origin设置为*。相反，你应该明确指定允许哪些源的跨域请求。

不要将Access-Control-Allow-Credentials设置为true：除非你确实希望允许发送凭据（如Cookies），否则不要将Access-Control-Allow-Credentials设置为true。相反，你应该明确指定是否允许发送凭据。

不要将Access-Control-Allow-Origin设置为请求头中的Origin字段：除非你确实希望允许所有源的跨域请求，否则不要将Access-Control-Allow-Origin设置为请求头中的Origin字段。相反，你应该明确指定允许哪些源的跨域请求。

使用Content-Security-Policy头部：为了防止CSRF攻击，服务器应该在响应中设置合适的Content-Security-Policy（CSP）头部。例如，设置为default-src 'self'表示只允许从同一个源加载资源。

使用X-Content-Type-Options头部：为了防止MIME类型嗅探攻击，服务器应该在响应中设置合适的X-Content-Type-Options头部。例如，设置为nosniff表示禁止浏览器对响应内容进行MIME类型嗅探。

使用X-Frame-Options头部：为了防止点击劫持攻击，服务器应该在响应中设置合适的X-Frame-Options头部。例如，设置为DENY表示禁止在iframe中加载页面。

使用Referrer-Policy头部：为了防止Referer信息泄露，服务器应该在响应中设置合适的Referrer-Policy头部。例如，设置为no-referrer表示禁止在请求中发送Referer信息。

使用Feature-Policy头部：为了防止滥用API，服务器应该在响应中设置合适的Feature-Policy头部。例如，设置为geolocation 'none'表示禁止使用地理位置API。

使用Expect-CT头部：为了防止中间人攻击，服务器应该在响应中设置合适的Expect-CT头部。例如，设置为max-age=30表示要求客户端在接下来的30秒内验证证书透明度。

使用Strict-Transport-Security头部：为了防止SSL/TLS降级攻击，服务器应该在响应中设置合适的Strict-Transport-Security头部。例如，设置为max-age=31536000; includeSubDomains; preload表示要求客户端在接下来的一年内只使用HTTPS连接，并且包括所有子域名。

通过以上措施，可以有效地避免CORS配置不当导致的安全漏洞。

八、如何检测CORS配置的安全性？

CORS（跨域资源共享）配置不当可能会导致严重的安全漏洞，因此检测CORS配置的安全性非常重要。以下是一些检测CORS配置安全性的方法和工具。

方法一：手动测试

手动测试是最基本的方法，可以通过以下步骤进行：

查看响应头：向目标网站发送跨域请求，并查看响应头中是否有CORS相关的头信息，如Access-Control-Allow-Origin、Access-Control-Allow-Methods、Access-Control-Allow-Headers等。

测试不同的源：尝试从不同的源向目标网站发送跨域请求，看看目标网站是否允许这些请求。

测试凭据：尝试发送带有凭据（如Cookies）的跨域请求，看看目标网站是否允许这些请求。

测试不同的方法：尝试使用不同的HTTP方法（如GET、POST、PUT、DELETE等）向目标网站发送跨域请求，看看目标网站是否允许这些请求。

测试不同的头部：尝试在请求头中添加不同的头部信息，看看目标网站是否允许这些请求。

方法二：使用自动化工具

自动化工具可以大大提高检测效率，以下是一些常用的CORS配置漏洞检测工具：

CORScanner：CORScanner是一款专为发现网站CORS配置错误漏洞而设计的Python工具。它支持多线程和文件输入，适合进行大规模的网络扫描任务1。

OWASP ZAP：OWASP ZAP是一款开源的Web应用安全扫描工具，它内置了CORS配置漏洞检测功能。使用OWASP ZAP，可以轻松地检测出CORS配置不当导致的安全漏洞。

Burp Suite：Burp Suite是一款功能强大的Web应用安全测试工具，它也可以用于检测CORS配置的安全性。通过使用Burp Suite的拦截功能，可以手动或自动地发送跨域请求，并查看响应头中的CORS相关头信息。

方法三：参考安全最佳实践

参考安全最佳实践可以帮助你更好地理解和配置CORS。以下是一些CORS配置的安全最佳实践：

明确指定允许的源：不要将Access-Control-Allow-Origin设置为*，而是明确指定允许哪些源的跨域请求。

谨慎使用Access-Control-Allow-Credentials：只有在确实需要发送凭据（如Cookies）的情况下，才将Access-Control-Allow-Credentials设置为true。

限制允许的方法和头部：只允许必要的HTTP方法和头部信息，不要允许所有方法和头部信息。

使用预检请求：对于非简单请求，服务器应该先处理预检请求（OPTIONS请求），然后再处理实际请求。

定期审查和更新配置：定期审查和更新CORS配置，确保其符合最新的安全要求。

通过以上方法和工具，可以有效地检测CORS配置的安全性，从而防止CORS配置不当导致的安全漏洞。