详解XSS和CSRF

关于XSS

xss是跨站脚本攻击，攻击者通过“注入”，在网页中插入恶意代码，从而被浏览器执行所造成的一种攻击方式。

举一些实例，它可以进行如下操作：

1.窃取用户的cookie信息。恶意代码可以通过执行 ”doccument.cookie“获取用户的cookie信息，然后发送给恶意服务器

2.监听用户的输入行为。使用 "addEventListener"接口来监听键盘事件，比如可以获取用户输入的银行卡及密码等个人信息。

3.在页面生成浮窗广告或执行alert弹窗，造成不好的用户体验。

XSS类型

XSS攻击可以分为三类：反射型，存储型，DOM型

1.反射型XSS攻击

反射型攻击是指用户提交恶意代码给服务器，服务器又将恶意代码反射给浏览器端，例如在url请求中加上script代码，那么浏览器在访问相应url时就会执行恶意代码

2.存储型XSS攻击

如上图所示，攻击者利用站点漏洞将恶意代码提交到网站的数据库中，当用户进行访问时，就会执行相应的恶意代码，脚本代码会将用户信息上传到黑客服务器。

在实际应用中，如果在登录页面，用户名输入框中输入<script>alert('存储型 XSS 攻击')</script>代码，服务端在存储相应信息之后，返回成功的登录名，就会执行这段代码，在页面形成弹窗。

存储型攻击与反射型攻击的区别在于，服务器端是否存储了相应的恶意代码。

3.DOM型XSS攻击

 这是发生在前端的攻击，通过恶意脚本修改页面的DOM节点，从js中输出数据到HTML页面中

与普通XSS不同的是，DOM XSS是在浏览器的解析中改变页面DOM树，且恶意代码并不在返回页面源码中回显，这使我们无法通过特征匹配来检测DOM XSS

基于DOM攻击大致需要经历以下几个步骤

1. 攻击者构造出特殊的URL，其中包含恶意代码
2. 用户打开带有恶意代码的URL
3. 用户浏览器接受到响应后执行解析，前端JavaScript取出URL中的恶意代码并执行
4. 恶意代码窃取用户数据并发送到攻击者的网站，冒充用户行为，调用目标网站接口执行攻击者指定的操作

防御办法

1.对输入进行检查和转码

输入检查一般是检查用户输入的数据是都包含一些特殊字符，如 <、>, '及"等。如果发现特殊字符，则将这些字符过滤或编码。这种可以称为 “XSS Filter”。

安全的编码函数

针对HTML代码的编码方式是 HtmlEncode（是一种函数实现，将字符串转成 HTMLEntrities）

& --> &
< --> &lt;
> --> &gt;
" --> &quot;

相应的， JavaScript的编码方式可以使用 JavascriptEncode。

假如说用户输入了 <script>alert("你被攻击了")</script>，我们要对用户输入的内容进行过滤（如果包含了 <script> 等敏感字符，就过滤掉）或者对其编码，如果是恶意的脚本，则会变成下面这样

<script>alert("你被攻击了");</script>

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

2.利用CSP

CSP (Content Security Policy) 即内容安全策略，是一种可信白名单机制，可以在服务端配置浏览器哪些外部资源可以加载和执行。可以通过这种方式来尽量减少 XSS 攻击。

通常可以通过两种方式来开启 CSP：

• 设置 HTTP Header 的 Content-Security-Policy

Content-Security-Policy: default-src 'self'; // 只允许加载本站资源
Content-Security-Policy: img-src https://*  // 只允许加载 HTTPS 协议图片
Content-Security-Policy: child-src 'none'    // 允许加载任何来源框架

• 设置 meta 标签的方式

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

关于CSRF

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

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

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

三种常见的攻击方式：

1.GET类型的CSRF

通常请求被放置在img标签的src中，当用户访问了包含这个标签的网页时，浏览器会自动向src中的地址提交一次http请求

2.自动发起POST类型请求

通过构建一个隐藏的表单，表单的内容就是自动发起支付的接口请求。当用户打开该页面时，这个表单会被自动执行提交。当表单被提交之后，服务器就会执行转账操作。因此使用构建自动提交表单这种方式，就可以自动实现跨站点 POST 数据提交。

3.链接类型

通过夸张的广告诱导用户点击链接，跳转到危险的网站，该网站自动自动发送请求，冒充用户执行相应的操作。

因此，CSRF有以下两个特点：一是通常发生在第三方域名，二是攻击者不能访问cookie信息，只是使用。针对这两个方面，对CSRF攻击进行相应的防护。

防护措施：

1.确定来源域名。

由于CSRF攻击大多来自第三方站点，可以在服务器端验证请求来源的站点，禁止第三方站点的请求。 可以通过HTTP请求头中的 Referer和Origin属性确定来源域名。

2.设置CSRF Token

在用户首次发出请求时，服务器为该用户生成一个token（一般是随机字符串和时间戳生成的随机数组合），之后所有的请求都携带这个token，在有效期内服务器进行验证。由于攻击者无法获取这个随机的token，可以防护csrf攻击。

3.为Set-Cookie响应头新增Samesite属性

SameSite有3个可选值： Strict, Lax和None

Samesite=Strict，严格模式，浏览器完全禁止第三方cookie，只有本站点访问本站点的资源，才会携带cookie

Samesite=Lax，宽松模式，在跨站点的情况下，从第三方站点链接打开和从第三方站点提交 Get方式的表单这两种方式都会携带Cookie。但如果在第三方站点中使用POST方法或者通过 img、Iframe等标签加载的URL，这些场景都不会携带Cookie。

Samesite=none，任何情况下都可以发送cookie数据