互联网的发展，使各种WEB应用也变得越来越复杂，满足了用户的各种需求，但随之而来的就是各种网络安全的问题。
对于前端安全漏洞这块之前自己也是一点都没接触，但真正在业务上遇到了，才不得不重视起来，前段时间也给公司前端小伙伴们分享了一些简单的关于xss csrf攻击的例子与解决办法，整理总结了一篇学习笔记~前端安全不容忽视，不说深入研究其门道，至少要了解它的攻击方式，能让我们最大限度的防范。
一、XSS （跨站脚本攻击）
实际案例：
为了用户能在登录之后访问到之前浏览的页面，所以在url加入了一个service参数，但是未对它做任何校验，可能会被钓鱼网站利用。
⭐️上述操作，当我们在搜索栏中输入对应的恶意脚本代码，服务器端进行处理，当未找到匹配内容时简单返回我们输入的查询字符串，如果网站前端或者服务器端没有对查询字符串做恰当的处理，只是简单返回并插入到页面中，那这段恶意脚本代码很可能被当做正常的script标签解释执行。后果就是泄露了自己账户的cookie。
⭐️ 扩展：1.将重要的cookie标记为httpOnly,HttpOnly是在设置cookie时接受的一个参数，一旦被设置，在浏览器的document对象中就看不到cookie了，这样的话Javascript 中的document.cookie语句就不能获取到cookie了
二、CSRF （跨站请求伪造）
CSRF可以做什么？
攻击者盗用了你的身份，以你的名义发送恶意请求。CSRF能够做的事情包括：以你名义发送邮件，发消息，盗取你的账号，甚至于购买商品，虚拟货币转账......造成的问题包括：个人隐私泄露以及财产安全
原理：
1.用户登录受信任网站A，并在本地生成Cookie。
2.在不登出A的情况下，访问危险网站B。
小白示例1：
银行网站A，它以GET请求来完成银行转账的操作，如：http://www.mybank.com/Transfer.php?toBankId=11&money=1000
危险网站B，它里面有一段HTML的代码如下：
<img src=http://www.mybank.com/Transfer.php?toBankId=11&money=1000>
用户操作：登录了银行网站A，然后访问危险网站B，发现你的银行账户少了1000块
小白示例2：
银行A改用POST请求进行转账操作，如下表单：
危险网站B，还是这句代码：
<img src=http://www.mybank.com/Transfer.php?toBankId=11&money=1000>
PS: 后台如果使用$_REQUEST去获取请求的数据，而$_REQUEST既可以获取GET请求的数据，也可以获取POST请求的数据，结果同上。
:) 继续改良版：如果后台使用$_POST只获取POST请求，危险网站B又将代码修改成下面这样，暗地里发送了POST请求到银行：
结果同上，钱还是被转走了！
⭐️这些攻击模式，可以看出CSRF攻击是源于WEB的隐式身份验证机制，WEB的身份验证机制虽然可以保证一个请求是来自于某个用户的浏览器，但无法保证该请求是用户批准发送的。
CSRF的防御
1、客户端页面增加伪随机数：在表单里增加Hash值，以认证这确实是用户发送的请求，服务器端进行Hash值验证
2、验证码（易用性不太好）：每次的用户提交都需要用户在表单中填写一次随机字符串
3、验证 HTTP Referer 字段： 在 HTTP 头中有一个字段叫 Referer，它记录了该 HTTP 请求的来源地址，银行对于每一个转账请求验证其 Referer 值，如果是以www.mybank.com开头的域名，说明该请求是来自银行网站自己的请求
4、在请求地址中添加 token 并验证：在 HTTP 请求中以参数的形式加入一个随机产生的 token，并在服务器端建立一个拦截器来验证这个 token，如果请求中没有 token 或者 token 内容不正确，则认为可能是 CSRF 攻击而拒绝该请求
5、Chrome下，可以让第三方访问时不带Cookies ——SameSite属性
（敏感信息设置SameSite：strict，不敏感的信息不设置）
strict任何来自第三方的请求都不能使用 Cookies ，包括通过链接点进来的
lex只有比较敏感的操作不带 Cookies ，比如表单提交
