CSRF和XSS
2023-02-26·6min
type
Post
summary
status
Published
category
tags
slug
date
Feb 26, 2023
password
icon
CSRF
CSRF（Cross-site request forgery）跨站请求伪造，是指攻击者诱导受害者进入第三方网站，利用受害者已获取的Cookie来向被攻击网站发起请求，达到冒充受害者执行某项操作的目的。
攻击流程如下：
- 受害者登陆A网站，获取并保留了登陆凭证Cookie。
- 攻击者诱导受害者进入第三方网站。
- 第三方网站自动或引诱受害者点击链接，向A网站发起请求。浏览器识别到是向A网站发起请求，默认会携带上A网站的Cookie。
- A网站接收到请求，对请求进行验证，并确认了Cookie，误以为是受害者本人发起的请求。
- A网站以受害者的名义执行请求中的操作。
- 攻击完成，攻击者在受害者不知情的情况下冒充受害者，让A网站执行了自己定义的操作。
常见的CSRF攻击方式
常见的主要有三种，分别是：
- 自动发起GET请求的CSRF
- 自动发起POST请求的CSRF
- 诱导用户点击链接的CSRF
自动发起GET请求的CSRF
这种类型是最简单的，一般是这样：
攻击者将恶意的支付请求隐藏在
img标签内，在加载这个标签时，浏览器会自动发起img的资源请求，a网站就会收到包含受害者Cookie的一次跨域请求。如果服务器认为该请求有效的话，就会将10000块转移到攻击者的账户上去了。
自动发起POST请求的CSRF
这种类型就是自动的表单提交，一般是这样：
访问该页面后，表单会自动提交，相当于模拟用户完成了一次POST操作。
引诱用户点击链接的CSRF
这种类型不常见，相比前两种进入第三方网站就中招的方式，这种需要用户主动点击后才能发起请求。
这种类型通常是在论坛中发布的图片中嵌入恶意链接，或者以广告的形式诱导用户中招，例如：
如果之前用户登录了网站A，并且保存Cookie，只要用户点击了这个超链接，就会发起攻击。
CSRF攻击的必要条件
- 目标站点一定要有CSRF漏洞
- 用户要登录过目标站点，并且在浏览器上保存有该站点的登录Cookie
- 需要用户打开一个第三方站点，可以是攻击者的站点，也可以是一些论坛
防护CSRF的策略
利用Cookie的SameSite属性
通常CSRF攻击都是第三方站点利用用户保存的Cookie来向目标站点发起攻击，所以可以从Cookie的安全性出发做以下防护：
- 禁止第三方站点发起的请求携带本站点的Cookie。
- 允许本站内的请求正常携带Cookie。
Cookie中的SameSite就是为了实现这两点而实现的，通过SameSite可以有效降低CSRF攻击的风险。
SameSite有以下三个值：
- Strict：完全禁止第三方站点拿到不属于它的Cookie
- Lax: 相对宽松，允许第三方站点安全的GET方法和HEAD方法携带不属于它的Cookie，其他方法禁止携带。
- None：最宽松，相当于不设置
所以，可以将Cookie的SameSite属性设置为Strict或Lax来解决Cookie问题。
利用同源策略
既然CSRF大多来自第三方网站，那么就直接禁止外域（或者不受信任的域名）对我们发起请求。
在HTTP协议中，每一个请求首部都有两个字段，用于标记来源域名：
- Referer: 记录该请求的来源地址（含URL路径)
- Origin: 记录该请求的域名信息（不含URL路径）
服务器先判断Origin，如果请求头中没有包含Origin属性，再根据实际情况判断是否使用Referer值，看是否是同源请求，如果不是，直接禁止该请求。
Token认证
由于攻击者无法直接窃取到用户的信息（Cookie，Header等），仅仅只能冒用Cookie，所以可以通过启用Token认证来防止CSRF。
- 在用户登录时，服务器生成一个Token返回给用户，用户将其保存。
- 下次向服务端发起请求时，带上Token，服务器端验证Token真伪和有效期，通过则放行。
XSS
XSS（Cross Site Scripting）跨站脚本攻击，为了与CSS区分开来，故简称XSS。
XSS是指攻击者在网页中注入恶意脚本代码，当用户访问时该恶意代码自动执行，达到攻击用户的目的。
XSS主要有以下几个恶意目的：
- 获取用户隐私数据，例如Cookie，发送给攻击者。
- 更改DOM结构，例如在页面内生成浮窗广告。
- 劫持流量实现恶意跳转
XSS是如何注入的
XSS攻击根据来源可分为三种，分别是：
- 存储型XSS
- 反射型XSS
- DOM型XSS
存储型XSS
存储型XSS指攻击者会把恶意代码上传并“存储”在目标网站数据库中，当浏览器请求该网站数据时，网站会把带有恶意代码的数据返回，浏览器接收到响应后解析执行，混在其中的恶意代码也会被执行，从而达到攻击的目的。
存储型XSS漏洞常见于提供用户保存数据功能的网站，如论坛发帖、商品评论、私信等。
比较常见的一个场景是攻击者在社区或者论坛上写下一篇包含恶意js代码的文章或者评论，文章或评论发表后，所有访问该文章或评论的用户，都会在他们的浏览器中执行这段恶意的js代码。
反射型XSS
反射型XSS指攻击者伪造出特殊的URL，其中包含恶意代码。当用户点击这带有恶意代码的URL时，网站服务端就会将恶意代码从URL中取出，拼接在数据中返回给浏览器。浏览器接收到响应后解析执行，混在其中的恶意代码也会被执行，从而达到攻击的目的。
反射型XSS和存储型XSS的区别是：存储型XSS的恶意代码存在数据库里，反射型XSS的恶意代码存在URL里。
反射型XSS漏洞常见于通过URL传递参数的功能，如网站搜索、跳转等。
由于需要用户主动打开恶意的URL才能生效，攻击者往往会结合多种手段诱导用户点击。
DOM型XSS
DOM型XSS指攻击者伪造出特殊的URL，其中包含恶意代码。当用户点击这带有恶意代码的URL时，发起请求，接着浏览器拿到响应数据，如果正好网站中的JS需要URL中的某部分，就会解析URL，并不知情的从中取出恶意代码并执行，从而达到攻击的目的。
DOM型XSS跟前两种XSS的区别：DOM型XSS攻击中，取出和执行恶意代码由浏览器端完成，属于前端JS自身的安全漏洞，而其他两种XSS都属于服务端的安全漏洞。
如何预防XSS攻击
XSS攻击有两大要素：
- 攻击者提交恶意代码。
- 浏览器执行恶意代码。
针对这两点，有以下几点防护措施。
1.过滤特殊字符，或对特定字符进行编译转码
服务端对响应数据中的特殊字符进行过滤处理，例如对
<script>alert(document.cookie)</script> 进行过滤为 ，或直接转码成<script>alert('document.cookie')</script>，这样就不会在页面执行了。2.对重要的cookie设httpOnly
通过对重要的Cookie设置httpOnly，防止客户端通过document.cookie读取cookie，也就是说，前端JS读取不到此条Cookie，即使被XSS攻击，这个Cookie也无法被攻击者获取。
3. URLEncode
将不可信的值输出URL参数之前，进行URLEncode操作。对于从URL参数中获取值一定要进行格式检测（比如你需要的是URL，就判断是否满足URL格式）