CodeWithJ | CodeWithJ

CORS（Cross-Origin Resource Sharing，跨域资源共享） 是一种浏览器安全机制，允许或限制从不同来源（域名、协议或端口）加载资源的网页进行交互。它解决了浏览器的同源策略（Same-Origin Policy, SOP）限制，允许受控的跨域请求，以保护用户数据的安全。

背景

浏览器的同源策略 规定，网页只能访问与其自身同源（即相同域名、协议和端口）的资源，防止恶意网站获取其他域的数据。这虽然有效提升了安全性，但限制了现代 Web 应用中常见的跨域交互需求，如 API 请求、跨域文件加载等。 CORS 允许在安全的情况下进行跨域请求，提供了一种松散的跨源资源访问机制，使得服务器可以指定哪些外部源可以访问其资源。

CORS 的基本原理

简单请求（Simple Request） ：当浏览器向不同来源的服务器发出跨域请求时，如果满足一定条件，这个请求被称为简单请求 。例如，GET 或 POST 请求，且请求头为Content-Type: text/plain，这些请求可以直接发送。响应头 ：服务器通过在响应头中设置CORS 相关的头 ，告知浏览器是否允许这个跨域请求。重要的 CORS 响应头 ：

Access-Control-Allow-Origin: 指定允许哪些来源访问资源。可以是具体的域名，也可以是*（表示允许任何来源）。

Access-Control-Allow-Origin: https://example.com

请求示例 ：

GET /api/data HTTP/1.1
Origin: https://client.com

响应示例 ：

HTTP/1.1 200 OK
Access-Control-Allow-Origin: https://client.com
Content-Type: application/json

预检请求（Preflight Request） ：对于某些类型的请求，如使用了自定义的请求头，或者使用了非 GET/POST/HEAD 等方法，浏览器会在实际请求之前发送一个预检请求 （OPTIONS请求），以确保目标服务器允许该请求。预检请求示例 ：

OPTIONS /api/data HTTP/1.1
Origin: https://client.com
Access-Control-Request-Method: POST
Access-Control-Request-Headers: Content-Type

预检响应示例 ：

HTTP/1.1 200 OK
Access-Control-Allow-Origin: https://client.com
Access-Control-Allow-Methods: POST, GET, OPTIONS
Access-Control-Allow-Headers: Content-Type
Access-Control-Max-Age: 86400

Access-Control-Allow-Methods: 指定允许的 HTTP 方法，如GET、POST等。
Access-Control-Allow-Headers: 允许使用的自定义请求头。
Access-Control-Max-Age: 指定预检请求的结果可以缓存多长时间，减少后续预检请求的次数。

响应头解释 ：

Access-Control-Allow-Origin: 允许的跨域源。
Access-Control-Allow-Methods: 允许的 HTTP 请求方法。
Access-Control-Allow-Headers: 允许的请求头字段。
Access-Control-Allow-Credentials: 是否允许发送凭证（如 Cookies、HTTP 认证等）。值为true时，浏览器允许客户端发送和接收凭证。

Access-Control-Allow-Credentials: true

CORS 的工作流程

浏览器发起请求 ：当浏览器发起跨域请求时，会在请求头中添加Origin字段，指示请求的来源。
服务器检查请求 ：服务器接收到请求后，根据自身配置检查Origin，并决定是否允许该请求。如果允许，服务器会在响应头中返回相应的 CORS 头信息。
浏览器处理响应 ：浏览器根据服务器返回的Access-Control-Allow-Origin等 CORS 头信息，决定是否允许页面访问返回的数据。如果服务器没有正确设置这些头，浏览器将阻止请求并抛出 CORS 错误。

CORS 示例

简单请求 ：前端 JavaScript 代码：

fetch("https://api.example.com/data", {
  method: "GET",
  credentials: "include", // 发送凭证，如Cookie
})
  .then((response) => response.json())
  .then((data) => console.log(data))
  .catch((error) => console.error("Error:", error));

假设 api.example.com 设置了 CORS 响应头：

Access-Control-Allow-Origin: https://client.com
Access-Control-Allow-Credentials: true

预检请求 ：当请求使用了非简单的 HTTP 方法（如PUT或DELETE），或自定义请求头（如Authorization），浏览器会首先发送预检请求：

OPTIONS /api/data HTTP/1.1
Origin: https://client.com
Access-Control-Request-Method: PUT

服务器响应：

HTTP/1.1 200 OK
Access-Control-Allow-Origin: https://client.com
Access-Control-Allow-Methods: PUT, GET, OPTIONS
Access-Control-Allow-Headers: Authorization

如何配置 CORS

Node.js/Express ：使用cors中间件：

const express = require("express");
const cors = require("cors");
const app = express();

app.use(
  cors({
    origin: "https://client.com", // 允许的来源
    credentials: true, // 允许发送Cookies
  })
);

app.get("/api/data", (req, res) => {
  res.json({ message: "Hello World!" });
});

app.listen(3000);

Nginx ：可以通过 Nginx 配置 CORS 响应头：

server {
    location /api/ {
        add_header 'Access-Control-Allow-Origin' 'https://client.com';
        add_header 'Access-Control-Allow-Credentials' 'true';
        add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS';
        add_header 'Access-Control-Allow-Headers' 'Authorization, Content-Type';
    }
}

常见问题

CORS 错误 ：当浏览器禁止跨域请求时，会抛出 CORS 错误。这通常是因为服务器没有正确配置 CORS 响应头，或者浏览器不允许请求中的某些操作（如发送凭证）。
如何调试 ：可以通过浏览器的开发者工具查看请求和响应头，检查Access-Control-Allow-*相关头信息是否正确配置。

总结

CORS 是为了解决同源策略下的跨域资源请求问题的浏览器机制。它通过一系列的 HTTP 请求头，让服务器控制哪些来源可以访问其资源，并规定了如何安全地进行跨域请求。在实现跨域请求时，确保服务器配置正确的 CORS 响应头是关键。

WEB服务安全问题概述

2024年9月16日 · 阅读需 5 分钟

常见漏洞类型

分布式拒绝服务攻击（DDoS - Distributed Denial of Service） DDoS 攻击通过让大量的设备同时向目标服务器发送请求，耗尽其资源，导致服务器无法处理正常的请求，最终使服务无法使用。

目标：服务器、网站或网络资源。
方法：利用僵尸网络（Botnet）来发起大规模流量攻击。

SQL 注入（SQL Injection） SQL 注入是一种攻击方式，攻击者通过输入恶意 SQL 代码，绕过身份验证或操纵数据库查询，访问或修改敏感数据。

目标：使用 SQL 数据库的网站或应用程序。
后果：窃取或删除数据库中的敏感信息，或篡改应用行为。

跨站脚本攻击（XSS - Cross-Site Scripting） XSS 是一种代码注入攻击，攻击者通过向网页注入恶意脚本，当用户浏览受感染的网页时，恶意代码在用户的浏览器中执行。

目标：Web 应用程序用户。
后果：窃取用户的会话令牌、用户凭证，或者在用户浏览器上执行恶意操作。

暴力破解（Brute Force Attack） 暴力破解是一种尝试所有可能的密码组合，直到找到正确密码的攻击方法。

目标：用户登录系统、SSH、RDP 等需要密码的系统。
防御：使用强密码、账户锁定策略和双因素认证。

文件包含攻击（File Inclusion Attack） 这种攻击发生在 Web 应用程序允许用户动态加载文件的情况下。攻击者利用漏洞加载恶意文件，执行不安全操作。

目标：PHP、ASP 等动态加载文件的 Web 应用程序。
后果：攻击者可能获得服务器的控制权或敏感数据。

跨站请求伪造（CSRF - Cross-Site Request Forgery） CSRF 攻击诱骗已登录的用户在未察觉的情况下执行恶意操作。例如，在用户登录某网站时，诱导其点击特制的链接，导致未经授权的操作。

目标：Web 应用中的合法用户。
后果：攻击者可以利用用户的身份执行未经授权的操作。

authentication 和 authorization 区别

总结：

特性	Authentication（身份验证）	Authorization（授权）
目的	确认用户身份（你是谁）	决定用户能做什么（有什么权限）
过程	验证用户凭证（用户名、密码、指纹等）	检查用户是否有权限访问特定资源或执行特定操作
顺序	首先进行身份验证	身份验证之后进行授权
实例	用户输入用户名和密码，系统验证其合法性	用户登录后，系统决定用户能否查看特定页面或文件
应用范围	登录、身份识别、用户认证系统	权限管理、资源访问控制、功能限制

实际场景：

身份验证 ：你输入用户名和密码登录银行网站。
授权：你登录成功后，银行网站决定你可以查看账户余额，但不能访问管理员功能。

在实际应用中，身份验证和授权经常结合使用。例如，在 OAuth 2.0 中，用户首先通过身份验证登录（Authentication），然后授权应用程序访问其资源（Authorization）。

背景​

CORS 的基本原理​

CORS 的工作流程​

CORS 示例​

如何配置 CORS​

常见问题​

总结​

常见漏洞类型​

authentication 和 authorization 区别​

总结：​

实际场景：​

背景