整理一下前端开发过程中经常遇到的安全问题
1、xss跨站脚本攻击原理？如何进行？防御手段？
如何进行
XSS是指恶意攻击者利用网站没有对用户提交数据进行转义处理或者过滤不足的缺点，进而添加一些代码，嵌入到web页面中去。使别的用户访问都会执行相应的嵌入代码。从而盗取用户资料、利用用户身份进行某种动作或者对访问者进行病毒侵害的一种攻击方式。
跨站脚本攻击可能造成以下影响：
-
利用虚假输入表单骗取用户个人信息。
-
利用脚本窃取用户的 Cookie 值，被害者在不知情的情况下，帮助攻击者发送恶意请求。
-
显示伪造的文章或图片。
主要原理
过于信任客户端提交的数据！
防御手段
按理说，只要有输入数据的地方，就可能存在 XSS 危险。
-
httpOnly， 在 cookie 中设置 HttpOnly 属性后，js脚本将无法读取到 cookie 信息。
-
过滤转译，不信任任何客户端提交的数据，只要是客户端提交的数据就应该先进行相应的过滤处理然后方可进行下一步的操作。
2、CSRF跨站请求伪造原理？如何进行？防御手段？
如何进行
当你在某网页登录之后，在没有关闭网页的情况下，收到别人的链接。例如:http://127.0.0.1/dvwa/vulnerabilities/csrf/?password_new=1&password_conf=1&Change=Change#
点击链接，会利用浏览器的cookie把密码改掉。
可能会造成以下影响：
-
利用已通过认证的用户权限更新设定信息等；
-
利用已通过认证的用户权限购买商品；
-
利用已通过的用户权限在留言板上发表言论。
主要原理
在没有关闭相关网页的情况下，点击其他人发来的CSRF链接，利用客户端的cookie直接向服务器发送请求。
防御手段
业务上要求用户输入原始密码（简单粗暴），攻击者在不知道原始密码的情况下，无论如何都无法进行CSRF攻击。
-
验证码；强制用户必须与应用进行交互，才能完成最终请求。此种方式能很好的遏制 csrf，但是用户体验比较差。
-
尽量使用 post ，限制 get 使用；上一个例子可见，get 太容易被拿来做 csrf 攻击，但是 post 也并不是万无一失，攻击者只需要构造一个form就可以。
-
Referer check；请求来源限制，此种方法成本最低，但是并不能保证 100% 有效，因为服务器并不是什么时候都能取到 Referer，而且低版本的浏览器存在伪造 Referer 的风险。
-
token；token 验证的 CSRF 防御机制是公认最合适的方案。整体思路如下：
-
第一步：后端随机产生一个 token，把这个token 保存到 session 状态中；同时后端把这个token 交给前端页面；
-
第二步：前端页面提交请求时，把 token 加入到请求数据或者头信息中，一起传给后端；
-
后端验证前端传来的 token 与 session 是否一致，一致则合法，否则是非法请求。若网站同时存在 XSS 漏洞的时候，这个方法也是空谈。
-
图片来自网络