我们先列出常见的几种前端的安全问题,在逐一的解释每一个并谈谈简单的解决思路
- XSS(Cross Site Script,跨站脚本攻击)
- SQL(Structured Query Language,结构化查询语言)注入
- CSRF(Cross-site Request Forgery,跨站请求伪造)
XSS(Cross Site Script,跨站脚本攻击)
XSS通常是由带有页面解析内容的数据未经处理直接插入页面上解析
导致的。而XSS根据攻击脚本的引入位置又可以分为以下三种:
- 存储型XSS
- 反射性XSS
- MXSS(DOM XSS)
存储型XSS
常常是由前端提交的数据未经处理直接存储到数据库然后从数据库中读取出来后直接插入到页面中导致
例如1
2
3
4
5
6
7<!-- 前端模版,content为后台得到的数据 -->
<!-- 实际上content的内容为<script>alert("")</script> -->
<div>{{content}}</div>
<!-- 经过解析后,页面上展现的是 -->
<div><script>alert("")</script></div>
上面的代码如果没有对<
,>
,/
进行处理,那么就会直接的运行这一点script代码,这就是一个简单的存储型XSS。
反射性XSS
一般产生的原因是在网页URL参数中注入了可解析内容的数据而导致的,如果直接获取URL中不合法的并插入页面中则可能出现页面上的XSS攻击。
MXSS
一般是在渲染DOM属性是将攻击脚本插入DOM属性中被解析而导致的。
其实这三种的实质是一样的,都是页面中出现了我们本不想让其执行但是可执行的脚本,主要的防范与解决方法就是验证也,输入到页面上所有内容来源数据是否安全,如果有可能含有脚本标签等内容则需要进行转义。
HTML常见字符的转义
1 | // HTML字符转义编码 |
SQL(Structured Query Language,结构化查询语言)注入
SQL注入攻击主要是因为页面提交数据到服务器后端,在服务器端未进行数据验证就将数据直接拼接到SQL语句中执行,因此产生执行与预期不同的现象。
主要的防范措施就是对前端网页提交的数据内容进行严格的检查校验。
例如1
let sql = `select * from user_table where id=${id}`
上面的一段查询语句接收一个参数id,如果前端页面所传递的id的值是100 or name=%user%,那么查询的结果就不只是id=100
的用户了,所有需要对前端传递的数据进行校验,这一步一般由后台人员处理,不过前端人员也可以做一个简单的验证提示,更重要的还是在后台方面。
CSRF(Cross-site Request Forgery,跨站请求伪造)
CSRF指非源站点按照源站点的数据请求格式提交非法数据给源站点服务器的一种攻击方法
。通俗的讲就是用户进入一个页面,这个页面不是真正的官方页面,而是模仿度非常高的一个页面,用户认为他就是官网了,此时就是访问了伪站点页面(非源站点),用户提交的数据进过这个页面提交而不是官方提交就是非法提交,而非源站点页面还可以获取用户姓名等重要信息(常见的银行卡密码盗取,支付密码盗取等)。
这种问题常见的解决方法就是通过页面Token提交验证的方式来验证请求是否为源站点页面提交的,来阻止跨站伪请求的发生。
Token也是需要进行加密解密的。
最后
最后说一点,任何所谓的安全都是相对的,只是理论的破解时间变长了,而不容易被攻击。很多时候需要使用多种方法相结合的方式来一起增加网站的安全性,可以结合验证码等手段大大减少盗刷网站用户信息的频率等。进一步增强网站内容的安全性。