[转帖]前端安全（同源策略、XSS攻击、CSRF攻击）

转载

jinanxiaolaohu6 2024-01-09 10:21:13 博主文章分类：日常工作

同源策略（Same-origin policy）

如果两个 URL 的协议、域名和端口都相同，我们就称这两个 URL 同源。

下表给出了与 URL http://store.company.com/dir/page.html 的源进行对比的示例:

http://store.company.com/dir2/other.html 同源
https://store.company.com/secure.html 不同源，协议不同
http://store.company.com:81/dir/etc.html 不同源，端口不同
http://news.company.com/dir/other.html 不同源，主机不同
复制代码

不同源会有如下限制：

Web 数据层面，同源策略限制了不同源的站点读取当前站点的 Cookie、IndexDB、LocalStorage 等数据。
DOM 层面，同源策略限制了来自不同源的 JavaScript 脚本对当前 DOM 对象读和写的操作。
网络层面，同源策略限制了通过 XMLHttpRequest 等方式将站点的数据发送给不同源的站点。

虽然这些限制是必要的，但是有时很不方便，合理的用途也受到影响。我们来看看如何突破？

跨域资源共享（CORS）

CORS（Cross-origin resource sharing，跨域资源共享）是一个 W3C 标准，定义了在必须访问跨域资源时，浏览器与服务器应该如何沟通。CORS 背后的基本思想，就是使用自定义的 HTTP 头部让浏览器与服务器进行沟通，从而决定请求或响应是否应该成功。

因此，实现 CORS 通信的关键是服务器。只要服务器实现了 CORS 接口，就可以跨源通信。

服务器设置它接收的跨域URL就可以了，或者设置为接收全部

Access-Control-Allow-Origin：http://www.example.cn
Access-Control-Allow-Origin：*
复制代码

在CORS中发送Cookie需要额外的设置

ajax 请求需要设置 xhr 的属性 withCredentials 为 true
服务器需要设置响应头部 Access-Control-Allow-Credentials: true
复制代码

JSONP 跨域

由于 script 标签不受浏览器同源策略的影响，允许跨域引用资源。

因此可以通过动态创建 script 标签，然后利用 src 属性进行跨域，这也就是 JSONP 跨域的基本原理。

JSONP 实现跨域的流程：

1、定义一个回调函数 handleResponse 用来接收返回的数据

function handleResponse(data) {
    console.log(data);
};
复制代码

2、动态创建一个 script 标签，并且告诉后端回调函数名叫 handleResponse

var body = document.getElementsByTagName('body')[0];
var script = document.gerElement('script');
script.src = 'http://www.example.com/json?callback=handleResponse';
body.appendChild(script);
复制代码

3、通过 script.src 请求 http://www.example.com/json?callback=handleResponse，

4、后端能够识别这样的 URL 格式并处理该请求，然后返回 handleResponse({"name": "data"}) 给浏览器

5、浏览器在接收到 handleResponse({"name": "data"}) 之后立即执行，也就是执行 handleResponse 方法，获得后端返回的数据，这样就完成一次跨域请求了。

缺点：

只支持 GET 请求。
由于是从其它域中加载代码执行，因此如果其他域不安全，很可能会在响应中夹带一些恶意代码。
要确定 JSONP 请求是否失败并不容易。虽然 HTML5 给 script 标签新增了一个 onerror 事件处理程序，但是存在兼容性问题。

图像 Ping 跨域

由于 img 标签不受浏览器同源策略的影响，允许跨域引用资源。因此可以通过 img 标签的 src 属性进行跨域，这也就是图像 Ping 跨域的基本原理。

直接通过下面的例子来说明图像 Ping 实现跨域的流程：

var img = new Image();

// 通过 onload 及 onerror 事件可以知道响应是什么时候接收到的，但是不能获取响应文本
img.onload = img.onerror = function() {
    console.log("Done!");
}

// 请求数据通过查询字符串形式发送
img.src = 'http://www.example.cn/test?name=jack';
复制代码

缺点：

只支持 GET 请求；
只能浏览器与服务器的单向通信，因为浏览器不能访问服务器的响应文本。

服务器代理

浏览器有跨域限制，但是服务器不存在跨域问题，所以可以由服务器请求所有域的资源再返回给客户端。

因此通过代理服务器例如Nginx的正向或者反向代理都可以解决这个问题。

原理：

本地启动项目访问地址是：localhost:8080；
服务器提供的接口地址是：http://example.com/api/v1/xxxx；
现在在本地项目中发起一个ajax请求到服务器，就会报跨域了，因为请求的地址与被请求的服务器接口出现跨域了；
localhost:8080发出的请求/api/v1/xxxx
这样发送请求首先浏览器肯定是认为是同源的。因为协议域名和端口都是相同的。但是实际上并没有任何服务器提供了localhost:8080/api/v1/xxxx请求。
这个时候就是代理服务器的工作了，它通过配置监听到了localhost:8080发出的请求，然后也让它直接转发成http://example.com/api/v1/xxxx。
这样代理服务器就到真实服务器上请求到数据了。
代理服务器将请求到的数据返回给浏览器了。

至此浏览器认为自己请求的是同源服务提供的接口，而服务器也接收到一个正常的请求然后返回数据。

知道其中的原理我们就能明白为什么有那么多的途径可以配置了例如： webpack 的 devServer.proxy、Charles、Nginx。

XSS 攻击

XSS 全称是 Cross Site Scripting，为了与“CSS”区分开来，故简称 XSS，翻译过来就是“跨站脚本”。

XSS 攻击是指黑客往 HTML 文件中或者 DOM 中注入恶意脚本，从而在用户浏览页面时利用注入的恶意脚本对用户实施攻击的一种手段。

最开始的时候，这种攻击是通过跨域来实现的，所以叫“跨域脚本”。但是发展到现在，往 HTML 文件中注入恶意代码的方式越来越多了，所以是否跨域注入脚本已经不是唯一的注入手段了，但是 XSS 这个名字却一直保留至今。

当页面被注入了恶意 JavaScript 脚本时，浏览器无法区分这些脚本是被恶意注入的还是正常的页面内容，所以恶意注入 JavaScript 脚本也拥有所有的脚本权限。

可以窃取 Cookie 信息。恶意 JavaScript 可以通过“document.cookie”获取 Cookie 信息，然后通过 XMLHttpRequest 或者 Fetch 加上 CORS 功能将数据发送给恶意服务器；恶意服务器拿到用户的 Cookie 信息之后，就可以在其他电脑上模拟用户的登录，然后进行转账等操作。
可以监听用户行为。恶意 JavaScript 可以使用“addEventListener”接口来监听键盘事件，比如可以获取用户输入的信用卡等信息，将其发送到恶意服务器。黑客掌握了这些信息之后，又可以做很多违法的事情。
可以通过修改 DOM 伪造假的登录窗口，用来欺骗用户输入用户名和密码等信息。
还可以在页面内生成浮窗广告，这些广告会严重地影响用户体验。

恶意脚本是怎么注入的

1、存储型 XSS 攻击

很多网站都会提供一些表单行为，如果输入用户名时我们输入一段脚本呢?

<script> console.log(document.cookie) </script>
复制代码

如果前端或者后端没有对用户的输入进行处理，那么会导致之后前端展示用户名时会直接执行上面这段脚本，这样一个恶意脚本就被插入到用户网页中。

2、反射型 XSS 攻击

var express = require('express');
var router = express.Router();


/* GET home page. */
router.get('/', function(req, res, next) {
  res.render('index', { title: 'Express',xss:req.query.xss });
});


module.exports = router;
复制代码

<!DOCTYPE html>
<html>
<head>
  <title><%= title %></title>
  <link rel='stylesheet' href='/stylesheets/style.css' />
</head>
<body>
  <h1><%= title %></h1>
  <p>Welcome to <%= title %></p>
  <div>
      <%- xss %>
  </div>
</body>
</html>
复制代码

后台根据URL上的参数，直接返回给前端界面。

如果用户访问http://localhost:3000/?xss=<script>alert('你被xss攻击了')</script>，那是不是就会出问题了呢。

因此可以这样认为，用户输入的都是不可靠的一定要做处理。

3、基于 DOM 的 XSS 攻击基于 DOM 的 XSS 攻击是不牵涉到页面 Web 服务器的。具体来讲，黑客通过各种手段将恶意脚本注入用户的页面中，比如通过网络劫持在页面传输过程中修改 HTML 页面的内容，这种劫持类型很多，有通过 WiFi 路由器劫持的，有通过本地恶意软件来劫持的，它们的共同点是在 Web 资源传输过程或者在用户使用页面的过程中修改 Web 页面的数据。

如何阻止 XSS 攻击

1、前端和服务端都对用户的输入进行过滤或转码

<script>alert('你被xss攻击了')</script>

转码：

<script>alert('你被xss攻击了')</script>
复制代码

经过转码之后的内容，如<script>标签被转换为<script>，因此即使这段脚本返回给页面，页面也不会执行这段脚本。

2、充分利用 CSP 安全策略

CSP 的主要目标是减少和报告 XSS 攻击，XSS 攻击利用了浏览器对于从服务器所获取的内容的信任。恶意脚本在受害者的浏览器中得以运行，因为浏览器信任其内容来源，即使有的时候这些脚本并非来自于它本该来的地方。

CSP通过指定有效域——即浏览器认可的可执行脚本的有效来源——使服务器管理者有能力减少或消除XSS攻击所依赖的载体。一个CSP兼容的浏览器将会仅执行从白名单域获取到的脚本文件，忽略所有的其他脚本 (包括内联脚本和HTML的事件处理属性)。

作为一种终极防护形式，始终不允许执行脚本的站点可以选择全面禁止脚本执行。

实施严格的 CSP 可以有效地防范 XSS 攻击，具体来讲 CSP 有如下几个功能：

限制加载其他域下的资源文件，这样即使黑客插入了一个 JavaScript 文件，这个 JavaScript 文件也是无法被加载的；
禁止向第三方域提交数据，这样用户数据也不会外泄；
禁止执行内联脚本和未授权的脚本；

常见设置：

Content-Security-Policy: default-src 'self'; img-src *; media-src media1.com media2.com; script-src userscripts.example.com
复制代码

图片可以从任何地方加载(注意 "*" 通配符)。
多媒体文件仅允许从 media1.com 和 media2.com 加载(不允许从这些站点的子域名)。
可运行脚本仅允许来自于userscripts.example.com。

3、使用 HttpOnly 属性

由于很多 XSS 攻击都是来盗用 Cookie 的，因此还可以通过使用 HttpOnly 属性来保护我们 Cookie 的安全。

通常服务器可以将某些 Cookie 设置为 HttpOnly 标志，HttpOnly 是服务器通过 HTTP 响应头来设置的，下面是打开 Google 时，HTTP 响应头中的一段：

set-cookie: NID=...; expires=Sat, 18-Apr-2020 06:52:22 GMT; path=/; domain=.google.com; HttpOnly
复制代码

set-cookie 属性值最后使用了 HttpOnly 来标记该 Cookie。顾名思义，使用 HttpOnly 标记的 Cookie 只能使用在 HTTP 请求过程中，所以无法通过 JavaScript 来读取这段 Cookie。

由于 JavaScript 无法读取设置了 HttpOnly 的 Cookie 数据，所以即使页面被注入了恶意 JavaScript 脚本，也是无法获取到设置了 HttpOnly 的数据。因此一些比较重要的数据我们建议设置 HttpOnly 标志。

CSRF 攻击

相信你经常能听到的一句话：“别点那个链接，小心有病毒！”点击一个链接怎么就能染上病毒了呢？

我们结合一个真实的关于 CSRF 攻击的典型案例来分析下，在 2007 年的某一天，David 无意间打开了 Gmail 邮箱中的一份邮件，并点击了该邮件中的一个链接。过了几天，David 就发现他的域名被盗了。不过几经周折，David 还是要回了他的域名，也弄清楚了他的域名之所以被盗，就是因为无意间点击的那个链接。

[转帖]前端安全（同源策略、XSS攻击、CSRF攻击）_服务器

首先 David 发起登录 Gmail 邮箱请求，然后 Gmail 服务器返回一些登录状态给 David 的浏览器，这些信息包括了 Cookie、Session 等，这样在 David 的浏览器中，Gmail 邮箱就处于登录状态了。
接着黑客通过各种手段引诱 David 去打开他的链接，比如 hacker.com，然后在 hacker.com 页面中，黑客编写好了一个邮件过滤器，并通过 Gmail 提供的 HTTP 设置接口设置好了新的邮件过滤功能，该过滤器会将 David 所有的邮件都转发到黑客的邮箱中。
最后的事情就很简单了，因为有了 David 的邮件内容，所以黑客就可以去域名服务商那边重置 David 域名账户的密码，重置好密码之后，就可以将其转出到黑客的账户了。

CSRF 英文全称是 Cross-site request forgery，所以又称为“跨站请求伪造”，是指黑客引诱用户打开黑客的网站，在黑客的网站中，利用用户的登录状态发起的跨站请求。简单来讲，CSRF 攻击就是黑客利用了用户的登录状态，并通过第三方的站点来做一些坏事。

一个典型的CSRF攻击有着如下的流程：

受害者登录a.com，并保留了登录凭证（Cookie）；
攻击者引诱受害者访问了b.com；
b.com 向 a.com 发送了一个请求：a.com/act=xx。浏览器会默认携带a.com的Cookie；
a.com接收到请求后，对请求进行验证，并确认是受害者的凭证，误以为是受害者自己发送的请求；
a.com以受害者的名义执行了act=xx；
攻击完成，攻击者在受害者不知情的情况下，冒充受害者，让a.com执行了自己定义的操作。

CSRF的特点

攻击一般发起在第三方网站，而不是被攻击的网站。被攻击的网站无法防止攻击发生；
攻击利用受害者在被攻击网站的登录凭证，冒充受害者提交操作；而不是直接窃取数据；
整个过程攻击者并不能获取到受害者的登录凭证，仅仅是“冒用”；
跨站请求可以用各种方式：图片URL、超链接、CORS、Form提交等等。

防护策略

1、充分利用好 Cookie 的 SameSite 属性

SameSite 选项通常有 Strict、Lax 和 None 三个值。

set-cookie: 1P_JAR=2019-10-20-06; expires=Tue, 19-Nov-2019 06:36:21 GMT; path=/; domain=.google.com; SameSite=none
复制代码

Strict 最为严格。如果 SameSite 的值是 Strict，那么浏览器会完全禁止第三方 Cookie。简言之，如果你从百度的页面中访问 InfoQ 的资源，而 InfoQ 的某些 Cookie 设置了 SameSite = Strict 的话，那么这些 Cookie 是不会被发送到 InfoQ 的服务器上的。只有你从 InfoQ 的站点去请求 InfoQ 的资源时，才会带上这些 Cookie。
Lax 相对宽松一点。在跨站点的情况下，从第三方站点的链接打开和从第三方站点提交 Get 方式的表单这两种方式都会携带 Cookie。但如果在第三方站点中使用 Post 方法，或者通过 img、iframe 等标签加载的 URL，这些场景都不会携带 Cookie。
而如果使用 None 的话，在任何情况下都会发送 Cookie 数据。

对于防范 CSRF 攻击，我们可以针对实际情况将一些关键的 Cookie 设置为 Strict 或者 Lax 模式，这样在跨站点请求时，这些关键的 Cookie 就不会被发送到服务器，从而使得黑客的 CSRF 攻击失效。

2、验证请求的来源站点

接着我们再来了解另外一种防止 CSRF 攻击的策略，那就是在服务器端验证请求来源的站点。由于 CSRF 攻击大多来自于第三方站点，因此服务器可以禁止来自第三方站点的请求。那么该怎么判断请求是否来自第三方站点呢？

在HTTP协议中，每一个异步请求都会携带两个Header，用于标记来源域名：

Origin Header
Referer Header

这两个Header在浏览器发起请求时，大多数情况会自动带上，并且不能由前端自定义内容。服务器可以通过解析这两个Header中的域名，确定请求的来源域。

3、CSRF Token

除了使用以上两种方式来防止 CSRF 攻击之外，还可以采用 CSRF Token 来验证，这个流程比较好理解，大致分为两步。

第一步，在浏览器向服务器发起请求时，服务器生成一个 CSRF Token。CSRF Token 其实就是服务器生成的字符串，然后将该字符串植入到返回的页面中。你可以参考下面示例代码：

<!DOCTYPE html>
<html>
<body>
    <form action="https://time.geekbang.org/sendcoin" method="POST">
      <input type="hidden" name="csrf-token" value="nc98P987bcpncYhoadjoiydc9ajDlcn">
      <input type="text" name="user">
      <input type="text" name="number">
      <input type="submit">
    </form>
</body>
</html>
复制代码

第二步，在浏览器端如果要发起转账的请求，那么需要带上页面中的 CSRF Token，然后服务器会验证该 Token 是否合法。如果是从第三方站点发出的请求，那么将无法获取到 CSRF Token 的值，所以即使发出了请求，服务器也会因为 CSRF Token 不正确而拒绝请求。

关于CSRF这里只是简单介绍，如果需要全方位了解可以参考：前端安全CSRF