AI 助理
备案控制台
开发者社区 开发与运维 文章 正文

【全栈修炼】CORS和CSRF修炼宝典

2022-05-06 178
版权
版权声明：
本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《 阿里云开发者社区用户服务协议》和 《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写 侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。
本文涉及的产品
.cn 域名，1个 12个月
简介： 【全栈修炼】CORS和CSRF修炼宝典


《全栈修炼》系列

  1. 《【全栈修炼】OAuth2修炼宝典》

CORS 和 CSRF 太容易混淆了，看完本文，你就清楚了。

一、CORS 和 CSRF 区别

先看下图：

两者概念完全不同，另外常常我们也会看到 XSS ，这里一起介绍：

  1. CORS ： Cross Origin Resourse-Sharing 跨站资源共享
  2. CSRF ： Cross-Site Request Forgery 跨站请求伪造
  3. XSS ： Cross Site Scrit 跨站脚本攻击（为与 CSS 区别，所以在安全领域叫 XSS）

二、CORS

1. 概念

跨来源资源共享（CORS），亦译为跨域资源共享，是一份浏览器技术的规范，提供了 Web 服务从不同网域传来沙盒脚本的方法，以避开浏览器的同源策略，是 JSONP 模式的现代版。与 JSONP 不同，CORS 除了 GET 请求方法以外也支持其他的 HTTP 请求。用 CORS 可以让网页设计师用一般的 XMLHttpRequest，这种方式的错误处理比 JSONP 要来的好。另一方面，JSONP 可以在不支持 CORS 的老旧浏览器上运作。现代的浏览器都支持 CORS。

—— 维基百科

核心知识： CORS是一个W3C标准，它允许浏览器向跨源服务器，发出XMLHttpRequest 请求，从而克服 AJAX 只能同源使用的限制。

因此，实现 CORS 通信的关键是服务器。只要服务器实现了 CORS 接口，就可以跨源通信，即为了解决跨域问题。

2. CORS 请求类型

浏览器将 CORS 请求分成两类：简单请求（simple request）和非简单请求（not-so-simple request）。

简单请求一般包括下面两种情况：

情况 描述
请求方法 请求方法为：HEAD 或 GET 或 POST；
HTTP 头信息 HTTP 头信息不超出以下几种字段：Accept
Accept-Language
Content-Language
Last-Event-ID
Content-Type：只限于三个值 application/x-www-form-urlencoded、multipart/form-data、text/plain

凡是不同时满足上面两个条件，就属于非简单请求。

3. 简单请求的 CORS 流程

当浏览器发现我们的 AJAX 请求是个简单请求，便会自动在头信息中，增加一个 Origin 字段。

Origin 字段用来说明本次请求的来源（包括协议 + 域名 + 端口号），服务端根据这个值来决定是否同意此次请求。

当 Origin 指定的源不在许可范围，服务器会返回一个正常的 HTTP 回应，但浏览器会在响应头中发现 Access-Control-Allow-Origin 字段，便抛出异常。

当 Origin 指定的源在许可范围，服务器返回的响应头中会多出几个头信息字段：

除了上面图中的头信息，一般会有以下三个相关头信息：

  1. Access-Control-Allow-Origin

该字段是必须的。表示许可范围的域名，通常有两种值：请求时 Origin 字段的值或者 *（星号）表示任意域名。

  1. Access-Control-Allow-Credentials

该字段可选。布尔值，表示是否允许在 CORS 请求之中发送 Cookie 。若不携带 Cookie 则不需要设置该字段。

当设置为 true 则 Cookie 包含在请求中，一起发送给服务器。还需要在 AJAX 请求中开启 withCredentials 属性，否则浏览器也不会发送 Cookie 。

let xhr = new XMLHttpRequest();
xhr.withCredentials = true;

注意： 如果前端设置 Access-Control-Allow-Credentials 为 true 来携带 Cookie 发起请求，则服务端 Access-Control-Allow-Origin 不能设置为 *。

  1. Access-Control-Expose-Headers

该字段可选。可以设置需要获取的字段。因为默认 CORS 请求时，XMLHttpRequest 对象的getResponseHeader()方法只能拿到以下 6 个基本字段：

Cache-Control、Content-Language、Content-Type、Expires、Last-Modified、Pragma。

4. 非简单请求的 CORS 流程

非简单请求情况如：请求方法是 PUT / DELETE 或者 Content-Type:application/json 类型的请求。

在非简单请求发出 CORS 请求时，会在正式通信之前增加一次 “预检”请求（OPTIONS方法），来询问服务器，本次请求的域名是否在许可名单中，以及使用哪些头信息。

当 “预检”请求 通过以后，才会正式发起 AJAX 请求，否则报错。

4.1 预检请求

OPTIONS /cors HTTP/1.1
Origin: http://api.bob.com
Access-Control-Request-Method: PUT
Access-Control-Request-Headers: X-Custom-Header
User-Agent: Mozilla/5.0...
...

“预检”请求 信息中包含两个特殊字段：

  1. Access-Control-Request-Method

该字段是必须的，用来列出浏览器的 CORS 请求会用到哪些 HTTP 方法，上例是 PUT。

  1. Access-Control-Request-Headers

指定浏览器 CORS 请求额外发送的头信息字段，上例是 X-Custom-Header。

4.2 预检响应

HTTP/1.1 200 OK
Access-Control-Allow-Origin: http://api.bob.com
Access-Control-Allow-Methods: GET, POST, PUT
Access-Control-Allow-Headers: X-Custom-Header
Content-Type: text/html; charset=utf-8
Connection: Keep-Alive
...

当预检请求通过以后，在预检响应头中，会返回 Access-Control-Allow- 开头的信息，其中 Access-Control-Allow-Origin 表示许可范围，值也可以是 *。

当预检请求拒绝以后，在预检响应头中，不会返回 Access-Control-Allow- 开头的信息，并在控制台输出错误信息。

三、CSRF

1. 概念

跨站请求伪造（英语：Cross-site request forgery），也被称为 one-click attack 或者 session riding，通常缩写为 CSRF 或者 XSRF， 是一种挟制用户在当前已登录的Web应用程序上执行非本意的操作的攻击方法。跟跨网站脚本（XSS）相比，XSS 利用的是用户对指定网站的信任，CSRF 利用的是网站对用户网页浏览器的信任。

—— 维基百科

核心知识： 跨站点请求伪造请求。

简单理解： 攻击者盗用你的身份，以你的名义发送恶意请求。

常见场景：以你名义发送邮件，发消息，盗取你的账号，甚至于购买商品，虚拟货币转账等等。

造成影响：个人隐私泄露以及财产安全。

2. CSRF 攻击流程

上面描述了 CSRF 攻击的流程，其中受害者完成两个步骤：

  1. 登录受信任网站 A ，并在本地生成保存Cookie；
  2. 在不登出 A 情况下，访问病毒网站 B；

可以理解为：若以上两个步骤没有都完成，则不会受到 CSRF 攻击。

3. 服务端防御 CSRF 攻击

服务端防御的方式有很多，思想类似，都是在客户端页面增加伪随机数。

3.1 Cookie Hashing（所有表单都包含同一个伪随机数）

最简单有效方式，因为攻击者理论上无法获取第三方的Cookie，所以表单数据伪造失败。以 php 代码为例：

<?php
    //构造加密的Cookie信息
    $value = "LeoDefenseSCRF";
    setcookie("cookie", $value, time()+3600);
?>

在表单里增加Hash值，以认证这确实是用户发送的请求。

<?php
    $hash = md5($_COOKIE['cookie']);
?>
<form method="POST" action="transfer.php">
　　<input type="text" name="toBankId">
　　<input type="text" name="money">
　　<input type="hidden" name="hash" value="<?=$hash;?>">
　　<input type="submit" name="submit" value="Submit">
</form>

然后在服务器端进行Hash值验证。

<?php
    if(isset($_POST['check'])) {
　　     $hash = md5($_COOKIE['cookie']);
    　　 if($_POST['check'] == $hash) {
            doJob();
        } else {
　　　　　//...
    　　}
    } else {
　　    //...
    }
?>

这个方法个人觉得已经可以杜绝99%的CSRF攻击了，那还有1%呢....由于用户的 Cookie 很容易由于网站的 XSS 漏洞而被盗取，这就另外的1%。

一般的攻击者看到有需要算Hash值，基本都会放弃了，某些除外，所以如果需要100%的杜绝，这个不是最好的方法。

3.2 验证码

思路是：每次用户提交都需要用户在表单中填写一个图片上的随机字符串，这个方案可以完全解决CSRF，但易用性差，并且验证码图片的使用涉及 MHTML 的Bug，可能在某些版本的微软IE中受影响。

3.3 One-Time Tokens(不同的表单包含一个不同的伪随机值)

需要注意“并行会话的兼容”。如果用户在一个站点上同时打开了两个不同的表单，CSRF保护措施不应该影响到他对任何表单的提交。考虑一下如果每次表单被装入时站点生成一个伪随机值来覆盖以前的伪随机值将会发生什么情况：用户只能成功地提交他最后打开的表单，因为所有其他的表单都含有非法的伪随机值。必须小心操作以确保CSRF保护措施不会影响选项卡式的浏览或者利用多个浏览器窗口浏览一个站点。

php 实现如下：

  1. 先是 Token 令牌生成函数(gen_token())和 Session 令牌生成函数(gen_stoken())：
<?php
    function gen_token() {
        $token = md5(uniqid(rand(), true));
        return $token;
    }
　　function gen_stoken() {
　　　　$pToken = "";
　　　　if($_SESSION[STOKEN_NAME]  == $pToken){
　　　　　　$_SESSION[STOKEN_NAME] = gen_token();
　　　　}    
　　　　else{ }
　　}
?>
  1. WEB表单生成隐藏输入域的函数：　
<?php
    function gen_input() {
        gen_stoken();
        echo "<input type=\"hidden\" name=\"" . FTOKEN_NAME . "\"
     　　     value=\"" . $_SESSION[STOKEN_NAME] . "\"> ";
　　}
?>
  1. WEB表单结构：
<?php
    session_start();
    include("functions.php");
?>
<form method="POST" action="transfer.php">
    <input type="text" name="toBankId">
    <input type="text" name="money">
    <? gen_input(); ?>
    <input type="submit" name="submit" value="Submit">
</FORM>
  1. 服务端核对令牌

这一步很简单，不做详细介绍。

四、XSS

注意： 本文简单介绍 XSS 知识，具体详细可以阅读 FEWY 写的 《跨站脚本攻击—XSS》segmentfault.com/a/119000002…

1. 概念

跨站脚本（英语：Cross-site scripting，通常简称为：XSS）是一种网站应用程序的安全漏洞攻击，是代码注入的一种。它允许恶意用户将代码注入到网页上，其他用户在观看网页时就会受到影响。这类攻击通常包含了HTML以及用户端脚本语言。

—— 维基百科

XSS 攻击，一般是指攻击者通过在网页中注入恶意脚本，当用户浏览网页时，恶意脚本执行，控制用户浏览器行为的一种攻击方式。

常见 XSS 危害有：

  • 窃取用户Cookie，获取用户隐私，盗取用户账号。
  • 劫持用户（浏览器）会话，从而执行任意操作，例如进行非法转账、强制发表日志、发送电子邮件等。
  • 强制弹出广告页面，刷流量，传播跨站脚本蠕虫，网页挂马等。
  • 结合其他漏洞，如 CSRF 漏洞，实施进一步的攻击。

2. XSS 分类

3. XSS 防御

3.1 方法1：浏览器自带防御 （X-XSS-Protection ）

现今主流浏览器（Internet Explorer，Chrome 和 Safari）带有 HTTP X-XSS-Protection 响应头，当检测到跨站脚本攻击(XSS)时，浏览器将停止加载页面。

X-XSS-Protection 响应头有以下 4 个值：

  • X-XSS-Protection: 0

禁止XSS过滤。

  • X-XSS-Protection: 1

启用XSS过滤（通常浏览器是默认的）。 如果检测到跨站脚本攻击，浏览器将清除页面（删除不安全的部分）。

  • X-XSS-Protection: 1; mode=block

启用XSS过滤。 如果检测到攻击，浏览器将不会清除页面，而是阻止页面加载。

  • X-XSS-Protection: 1; report=<reporting-uri>

启用XSS过滤。 如果检测到跨站脚本攻击，浏览器将清除页面并使用CSP report-uri指令的功能发送违规报告。

注意：

这并不能完全防止反射型 XSS，而且也并不是所有浏览器都支持 X-XSS-Protection，存在兼容性问题。

它只对反射型 XSS 有一定的防御力，其原理也只是检查 URL 和 DOM 中元素的相关性。

3.2 方法2：转义

即将常用特殊字符进行转义，避免攻击者使用构造特殊字符来注入脚本。需要在客户端和服务端，都对用户输入的数据进行转义。

常见需要转义的特殊字符如 <，>，&，"，'。

转义方法：

function escapeHTML(str) {
    if (!str) return '';
    str = str.replace(/&/g, "&amp;");
    str = str..replace(/</g, "&lt;");
    str = str..replace(/>/g, "&gt;");
    str = str..replace(/"/g, "&quot;");
    str = str..replace(/'/g, "&#39;");
    return str;
};

3.3 方法3：过滤

常见于富文本内容，因为其需要保留 HTML，所以不能直接使用转义方法，而可以通过使用白名单，来允许特定的 HTML 标签及属性，来抵御 XSS 攻击。

3.4 方法4：内容安全策略（CSP）

内容安全策略（Content Security Policy，CSP），实质就是白名单制度，开发者明确告诉客户端，哪些外部资源可以加载和执行，大大增强了网页的安全性。

两种方法可以启用 CSP。

  1. 通过 HTTP 头信息的 Content-Security-Policy 的字段：
Content-Security-Policy: script-src 'self'; 
                         object-src 'none';
                         style-src cdn.example.org third-party.org; 
                         child-src https:
  1. 通过网页的 <meta> 标签
<meta http-equiv="Content-Security-Policy" content="script-src 'self'; object-src 'none'; style-src cdn.example.org third-party.org; child-src https:">

上面代码中，CSP 做了如下配置：

  • 脚本： 只信任当前域名
  • <object>标签： 不信任任何 URL，即不加载任何资源
  • 样式表： 只信任 cdn.example.org 和 third-party.org
  • 页面子内容，如 <frame>、<iframe>： 必须使用HTTPS协议加载
  • 其他资源： 没有限制
  • 启用后，不符合 CSP 的外部资源就会被阻止加载。

参考文章

  1. 《跨域资源共享 CORS 详解》
  2. 《CSRF & CORS》
  3. 《浅谈CSRF攻击方式》
  4. 《跨站脚本攻击—XSS》


文章标签：
域名
JavaScript
PHP
Go
前端开发
iOS开发
安全
Web App开发
数据格式
开发者
JSON
关键词：
全栈CSRF
王平安
目录
相关文章
巴黎香榭
|
Web App开发 Linux Python
Python全栈 Web（Django框架、HttpRequest，csrf跨域攻击）
Flask、Python、Django、框架、服务器、客户端、浏览器、交互、WEB、Python前端、CSS、JAVA、HTML、H5、PHP、JavaScript、JQuery、分布式开发、项目、flask项目、项目实战、django框架、Python项目、Python的Flask框架、Pytho.
巴黎香榭
1986 0
东方睿赢
|
6月前
|
JavaScript 安全 前端开发
js开发：请解释什么是XSS攻击和CSRF攻击，并说明如何防范这些攻击。
XSS和CSRF是两种常见的Web安全威胁。XSS攻击通过注入恶意脚本盗取用户信息或控制账户，防范措施包括输入验证、内容编码、HTTPOnly Cookie和CSP。CSRF攻击则诱使用户执行未经授权操作，防范手段有CSRF Tokens、双重验证、Referer检查和SameSite Cookie属性。开发者应采取这些防御措施并定期进行安全审计以增强应用安全性。
东方睿赢
126 0
阿甘兄
|
安全 NoSQL Java
互联网并发与安全系列教程（06） - 常见的Web安全漏洞（CSRF攻击）
互联网并发与安全系列教程（06） - 常见的Web安全漏洞（CSRF攻击）
阿甘兄
120 0
黑客网络安全
|
SQL 安全 前端开发
渗透攻击实例-邪恶的CSRF（社会工程学）
渗透攻击实例-邪恶的CSRF（社会工程学）
黑客网络安全
106 0
土木林森
|
6月前
|
缓存 安全 JavaScript
前端安全：Vue应用中防范XSS和CSRF攻击
【4月更文挑战第23天】本文探讨了在Vue应用中防范XSS和CSRF攻击的重要性。XSS攻击通过注入恶意脚本威胁用户数据，而CSRF则利用用户身份发起非授权请求。防范措施包括：对输入内容转义、使用CSP、选择安全的库；采用Anti-CSRF令牌、同源策略和POST请求对抗CSRF；并实施代码审查、更新依赖及教育团队成员。通过这些实践，可提升Vue应用的安全性，抵御潜在攻击。
土木林森
936 0
html的七十二变
|
9天前
|
存储 Web App开发 安全
如何防范 CSRF 攻击
CSRF（跨站请求伪造）攻击是一种常见的安全威胁。防范措施包括：使用Anti-CSRF Token、检查HTTP Referer、限制Cookie作用域、采用双重提交Cookie机制等，确保请求的合法性与安全性。
html的七十二变
23 5
html的七十二变
|
9天前
|
网络安全 数据安全/隐私保护
什么是 CSRF 攻击
CSRF（跨站请求伪造）攻击是指攻击者诱导用户点击恶意链接或提交表单，利用用户已登录的身份在目标网站上执行非授权操作，如转账、修改密码等。这种攻击通常通过嵌入恶意代码或链接实现。
html的七十二变
24 2
土木林森
|
17天前
|
安全 前端开发 Java
Web安全进阶：XSS与CSRF攻击防御策略深度解析
【10月更文挑战第26天】Web安全是现代软件开发的重要领域，本文深入探讨了XSS和CSRF两种常见攻击的原理及防御策略。针对XSS，介绍了输入验证与转义、使用CSP、WAF、HTTP-only Cookie和代码审查等方法。对于CSRF，提出了启用CSRF保护、设置CSRF Token、使用HTTPS、二次验证和用户教育等措施。通过这些策略，开发者可以构建更安全的Web应用。
土木林森
53 4
土木林森
|
16天前
|
安全 Go PHP
Web安全进阶：XSS与CSRF攻击防御策略深度解析
【10月更文挑战第27天】本文深入解析了Web安全中的XSS和CSRF攻击防御策略。针对XSS，介绍了输入验证与净化、内容安全策略（CSP）和HTTP头部安全配置；针对CSRF，提出了使用CSRF令牌、验证HTTP请求头、限制同源策略和双重提交Cookie等方法，帮助开发者有效保护网站和用户数据安全。
土木林森
44 2
土木林森
|
18天前
|
存储 安全 Go
Web安全基础：防范XSS与CSRF攻击的方法
【10月更文挑战第25天】Web安全是互联网应用开发中的重要环节。本文通过具体案例分析了跨站脚本攻击（XSS）和跨站请求伪造（CSRF）的原理及防范方法，包括服务器端数据过滤、使用Content Security Policy (CSP)、添加CSRF令牌等措施，帮助开发者构建更安全的Web应用。
土木林森
51 3