关于前端漏洞
xss，csrf（Cross-site request forgery）跨站点请求伪造
####xss : xss就是在页面执行你想要的js
XSS 防御技巧
XSS 防御技巧
HttpOnly
服务器端在设置安全级别高的Cookie时，带上HttpOnly的属性，就能防止JavaScript获取。
PHP设置HttpOnly：
1 <?2 header(“Set-Cookie: a=1;”, false);3 header(“Set-Cookie: b=1;httponly”, false);4 setcookie(“c”, “1”, NULL, NULL, NULL, NULL, ture);
输入检查
任何用户输入的数据，都是“不可信”的。
输入检查，一般是用于输入格式检查，例如：邮箱、电话号码、用户名这些…
都要按照规定的格式输入：电话号码必须纯是数字和规定长度；用户名除 中英文数字 外，仅允许输入几个安全的符号。
输入过滤不能完全交由前端负责，前端的输入过滤只是为了避免普通用户的错误输入，减轻服务器的负担。
因为攻击者完全可以绕过正常输入流程，直接利用相关接口向服务器发送设置。
所以，前端和后端要做相同的过滤检查。
输出检查
相比输入检查，前端更适合做输出检查。
可以看到，HttpOnly和前端没直接关系，输入检查的关键点也不在于前端。
那XSS的防御就和前端没关系了?
当然不是，随着移动端web开发发展起来了，Ajax的使用越来越普遍，越来越多的操作都交给前端来处理。
前端也需要做好XSS防御。
JavaScript直接通过Ajax向服务器请求数据，接口把数据以JSON格式返回。前端整合处理数据后，输出页面。
所以，前端的XSS防御点，在于输出检查。
但也要结合XSS可能发生的场景。
XSS注意场景
在HTML标签中输出
如：{$var}
风险：{$var} 为
防御手段：变量HtmlEncode后输出
在HTML属性中输出
如：
风险：{$var} 为 “ onclick=”/xss/
防御手段：变量HtmlEncode后输出
在
风险：{$var} 为 1; alert(/xss/)
防御手段：确保输出变量在引号里面，再让变量JavaScriptEncode后输出。
在事件中输出
如：hello!click me!
风险：{$var} 为 ); alert(/xss/); //
防御手段：确保输出变量在引号里面，再让变量JavaScriptEncode后输出。
在CSS中输出
一般来说，尽量禁止用户可控制的变量在