XSS和CSRF攻击及防范措施

[zenglinan]

xss 攻击

一、xss 攻击分类

1. 存储型
2. 反射型
3. DOM 型

1. 存储型

1. 攻击者将恶意代码提交到网站数据库中
2. 用户访问网站的时候，恶意代码被服务端从数据库中取出，拼接在 HTML 中返回给前端
3. 浏览器解析执行的时候，恶意代码被执行

常见应用场景：论坛发帖、商品评论、用户私信等

2. 反射型

1. 攻击者构造出包含了恶意代码的 url，url指向了目标网站，但是参数中可以拼接了恶意代码
2. 诱导用户点击，用户点击后会向目标网站发起请求，同时查询参数中携带了恶意代码
3. 服务端将查询参数直接拼接在 HTML 中返回给浏览器
4. 浏览器解析执行时，恶意代码被执行

常见应用场景：通过 URL 传递参数的场景，如网站搜索、跳转

3. DOM 型

DOM 型是浏览器端的漏洞，可能是以下情况：

1. <script>标签
2. javascript:??执行符(a标签的href属性,url上)
3. innerHTML=?? 或 .outerHTML=?? 或 setTimeout(??) 或 setInterval(??)(执行js)
4. document.write(??) 或 eval(??)
5. location、onclick、onerror、onload、onmouseover等事件（执行js）
6. 在 style 属性和标签中，包含类似 background-image:url(“javascript:…”);的代码（新版本浏览器已经可以防范）。
7. 在 style 属性和标签中，包含类似 expression(…) 的 CSS 表达式代码(新版本浏览器已经可以防范)

总而言之，对于 DOM 型 XSS 攻击，当执行用户输入代码时，以及将用户输入拼接到 HTML 时，要时刻注意

二、XSS 攻击防范

1. 防范反射型、存储型 XSS
2. 防范 DOM 型 XSS

1. 防范反射型、存储型 XSS

(1) 采用纯前端渲染

(2) 拼接 HTML 时，要对 HTML 进行充分转义(利用一些转义库)

2. 防范 DOM 型 XSS

(1) 将用户输入插入 HTML 或拼接 js 执行时，要进行编码，将一些特殊字符转义：

& -> &
<-> &lt;
> -> &gt;
"-> &quot;
' -> &#x27;
/ -> &#x2F;

(2) 对于 a 标签的 href 等外链请求，添加白名单进行过滤

其他防范措施

1. HTTP-Only：保护 cookie 不被获取
2. 限制输入的长度
3. 采取 CSP 防范（限制网站可以从哪些地方加载资源）

可以设置在响应头，也可以设置在 meta 标签中，示例如下：

允许网页应用的用户在他们自己的内容中包含来自任何源的图片, 但是限制音频或视频需从信任的资源提供者(获得)，所有脚本必须从特定主机服务器获取可信的代码.

// 响应头
Content-Security-Policy: 
default-src 'self'; img-src *; media-src media1.com media2.com; script-src userscripts.example.com

<meta http-equiv="Content-Security-Policy"
content="default-src 'self'; img-src https://*; child-src 'none';">

CSRF

1. CSRF 攻击前提
2. 防范措施

一、CSRF 攻击前提

CSRF（Cross-site request forgery）跨站请求伪造：受害者进入第三方网站，第三方网站中，偷偷向被攻击网站发送请求。利用受害者在被攻击网站已经获取的注册凭证，绕过后台的用户验证，达到冒充用户对被攻击的网站执行某项操作的目的。

攻击前提：

1. 受害人登录过了被攻击网站，并保存了登录凭证 cookie，并且尚未过期，下次访问会自动携带 cookie 登录
2. 在有凭证的前提下登录第三方网站

二、防范措施：

1. 同源验证

验证请求头 Origin、Referrer

这两个域名在请求的时候浏览器会自动带上，不能由前端随意修改

需要注意的是：

Origin 在 IE11 中不存在，在 302 重定向中也不存在，Referrer 可以被前端隐藏不携带，如果不存在这两个请求头时，需要利用其它方式验证

当访问源是外域时，直接拒绝访问，但要注意的是，需要过滤掉 html 页面请求，因为当请求来自搜索引擎结果页面时，也是外域访问，会被当做 CSRF 请求。

2. CSRF token 验证

后端根据秘钥生成 token，当用户登录的时候，将这个 token 发给前端，要求容易遭受 CSRF 攻击的请求都必须携带这个 token。注意，这个 token 不能用 cookie 发给后端，这样就形同虚设了。

后端收到后解开 token，如果合法并且没过期说明该请求是用户的正常请求

缺点：增加了服务端的计算压力，同时前端大量请求都需要携带 token

3. 验证码 / 密码

对于一些安全性需求高的操作，比如转账等，要求用户输入验证码或密码后才允许操作

4. Samesite Cookie

后端返回 cookie 的时候设置 Samesite Cookie 属性，如下：

Set-Cookie: foo=1; Samesite=Strict
Set-Cookie: bar=2; Samesite=Lax

Samesite=Strict：对于所有跨域请求，一律不携带这个 cookie

Samesite=Lax：如果打开了新页面或者改变了当前页面，并且该请求是个 GET 请求，则允许携带该 cookie

缺点：

1. Samesite 不支持子域，也就是说子域无法使用设置了 Samesite 的 cookie，这可能导致用户在主域登录后，前往子域页面仍需要重新登录
2. 兼容性不好