> 题目：前端常见的安全问题有哪些？ Web 前端的安全问题，能回答出下文的两个问题，这个题目就能基本过关了。开始之前，先说一个最简单的攻击方式 —— SQL 注入。 上学的时候就知道有一个「SQL注入」的攻击方式。例如做一个系统的登录界面，输入用户名和密码，提交之后，后端直接拿到数据就拼接 SQL 语句去查询数据库。如果在输入时进行了恶意的 SQL 拼装，那么最后生成的 SQL 就会有问题。但是现在稍微大型一点的系统，都不会这么做，从提交登录信息到最后拿到授权，要经过层层的验证。因此，SQL 注入都只出现在比较低端小型的系统上。 ### XSS（Cross Site Scripting，跨站脚本攻击） 这是前端最常见的攻击方式，很多大型网站（如 Facebook）都被 XSS 攻击过。 举一个例子，我在一个博客网站正常发表一篇文章，输入汉字、英文和图片，完全没有问题。但是如果我写的是恶意的 JS 脚本，例如获取到`document.cookie`然后传输到自己的服务器上，那我这篇博客的每一次浏览都会执行这个脚本，都会把访客 cookie 中的信息偷偷传递到我的服务器上来。 其实原理上就是黑客通过某种方式（发布文章、发布评论等）将一段特定的 JS 代码隐蔽地输入进去。然后别人再看这篇文章或者评论时，之前注入的这段 JS 代码就执行了。**JS 代码一旦执行，那可就不受控制了，因为它跟网页原有的 JS 有同样的权限**，例如可以获取 server 端数据、可以获取 cookie 等。于是，攻击就这样发生了。 #### XSS的危害 XSS 的危害相当大，如果页面可以随意执行别人不安全的 JS 代码，轻则会让页面错乱、功能缺失，重则会造成用户的信息泄露。 比如早些年社交网站经常爆出 XSS 蠕虫，通过发布的文章内插入 JS，用户访问了感染不安全 JS 注入的文章，会自动重新发布新的文章，这样的文章会通过推荐系统进入到每个用户的文章列表面前，很快就会造成大规模的感染。 还有利用获取 cookie 的方式，将 cookie 传入入侵者的服务器上，入侵者就可以模拟 cookie 登录网站，对用户的信息进行篡改。 #### XSS的预防 那么如何预防 XSS 攻击呢？—— 最根本的方式，就是对用户输入的内容进行验证和替换，需要替换的字符有： ~~~ & 替换为：&amp; < 替换为：&lt; > 替换为：&gt; ” 替换为：&quot; ‘ 替换为：&#x27; / 替换为：&#x2f; ~~~ 替换了这些字符之后，黑客输入的攻击代码就会失效，XSS 攻击将不会轻易发生。 除此之外，还可以通过对 cookie 进行较强的控制，比如对敏感的 cookie 增加`http-only`限制，让 JS 获取不到 cookie 的内容。 ### CSRF（Cross-site request forgery，跨站请求伪造） CSRF 是借用了当前操作者的权限来偷偷地完成某个操作，而不是拿到用户的信息。 例如，一个支付类网站，给他人转账的接口是`http://buy.com/pay?touid=999&money=100`，而这个接口在使用时没有任何密码或者 token 的验证，只要打开访问就直接给他人转账。一个用户已经登录了`http://buy.com`，在选择商品时，突然收到一封邮件，而这封邮件正文有这么一行代码`<img src="http://buy.com/pay?touid=999&money=100"/>`，他访问了邮件之后，其实就已经完成了购买。 CSRF 的发生其实是借助了一个 cookie 的特性。我们知道，登录了`http://buy.com`之后，cookie 就会有登录过的标记了，此时请求`http://buy.com/pay?touid=999&money=100`是会带着 cookie 的，因此 server 端就知道已经登录了。而如果在`http://buy.com`去请求其他域名的 API 例如`http://abc.com/api`时，是不会带 cookie 的，这是浏览器的同源策略的限制。但是 ——**此时在其他域名的页面中，请求`http://buy.com/pay?touid=999&money=100`，会带着`buy.com`的 cookie ，这是发生 CSRF 攻击的理论基础。** 预防 CSRF 就是加入各个层级的权限验证，例如现在的购物网站，只要涉及现金交易，肯定要输入密码或者指纹才行。除此之外，敏感的接口使用`POST`请求而不是`GET`也是很重要的。 ## **文档** [web安全](https://www.kancloud.cn/freya001/security/1214610)