关于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攻击大致需要经历以下几个步骤
- 攻击者构造出特殊的URL，其中包含恶意代码
- 用户打开带有恶意代码的URL
- 用户浏览器接受到响应后执行解析，前端JavaScript取出URL中的恶意代码并执行
- 恶意代码窃取用户数据并发送到攻击者的网站，冒充用户行为，调用目标网站接口执行攻击者指定的操作
防御办法
1.对输入进行检查和转码
输入检查一般是检查用户输入的数据是都包含一些特殊字符，如 <、>, '及"等。如果发现特殊字符，则将这些字符过滤或编码。这种可以称为 “XSS Filter”。
安全的编码函数
针对HTML代码的编码方式是 HtmlEncode（是一种函数实现，将字符串转成 HTMLEntrities）
& --> &
< --> <
> --> >
" --> "相应的， 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数据
