【原创】本文主要简述前端web安全知识
文件上传
后端服务器未对文件进行校验和过滤，上传asp/aspx/jsp/php等脚本文件（webshell）
解决方式：
1.前端过滤文件类型（攻击者可以直接绕过，开发者工具改代码，黑名单绕过）
2.后端过滤文件类型（如果是通过mime（contentType）类型判断，可抓包修改contentType绕过，黑名单绕过）
图片上传
图片文件中可能存在木马代码，然后在后端的使用该文件的时候（文件包含），比如 include (img_url)，会执行包含在文件里面的木马，存在安全风险
XSS漏洞
存储型：表单入口不过滤，恶意用户插入脚本，提交到数据库，每个用户都有可能被劫持
反射型/Dom型：表单入口恶意提交脚本代码，页面重定向的链接带有提交的恶意脚本，能回显执行（没有过滤地址URL），获取用户信息
钓鱼
1.假官网 通过各种方式让用户误以为是可靠链接;
2.攻击真实网站，形成存储型XSS，用户访问即跳转到（或其他方式）钓鱼登陆界面；
CSRF/XSRF攻击
XSRF 的全称是“跨站请求伪造”，它利用的是服务器对客户端浏览器的信任，从而伪造用户向服务器发送请求，从而欺骗服务器达到一些目的。
下图展示攻击方式，
简单攻击场景
1、用户A登陆了某银行网站取钱，此时会保留cookie；
(大家有没有遇见过，如果在短时间内登陆某APP，关闭APP后(不是退出账号密码)，快速再次登陆此App，此时会不用再次登陆app)
2、用户B在知道A在某银行取钱后，利用各种信息诱导进入某另一网站***.****.com
3、此时网站***.****.com存在一张图片，图片指向一个取钱的http请求
<img src=http://www.mybank.com/Transfer.php?toBankId=11&money=1000>
4、此时如果用户A点击了该图片，他就会丢失1000元。因为该请求是从A用户的网站发出去的，而不巧的是用户A刚不久之前访问某银行网站，此时请求会携带有效cookie，并且服务器的session还有效。
5、A的钱被偷了。
需要注意的一点是用户B无法窃取用户A的cookie，他只是利用用户A在不知情的情况下，发出了http请求，借助服务器对于用户浏览器的信任，实现了非法转账(攻击)
预防的措施
1、token验证
由于恶意用户无法窃取cookie，只能利用用户cookie模拟未携带token的http请求，那只要在服务器端进行token验证就可以防御xsrf的攻击。比如我们可以将token存储在localStorage中。
2、验证码
需要用户自己来填写验证码从而识别是否是用户主动发起的该请求。
其优点：简单粗暴、低成本
缺点：用户体验不好，需要多次验证。
3、Referer 字段
利用 HTTP 头中的 Referer 判断请求来源是否合法，Referer记录了该 HTTP 请求的来源地址。
4、随机参数，防机器人抓包请求重放
