前端面试之对安全防御的理解分析
作者：前端兰博
1.引言
每逢前端面试，80%的候选人都会被问到这个问题。这问题确确实实是一道八股文。为了应付面试，我自己也是反反复复背了好几次，但是记了又忘，忘了又记，如此优雅的恶性循环让我痛下决心去搞定其中的枝枝叶叶。废话不多说，上车吧。
2.常见前端攻击策略
- SQL注入
- XSS攻击
- CSRF攻击
3.攻击策略解释
3.1 SQL注入
sql注入通常是在url头或者表单内部通过拼接sql语句实现攻击。
它的原理比较简单，当浏览器url头或者表单提交数据到后端时，后端会进行数据库操作，如果未经过处理请求参数，那么攻击者会通过任意sql语句获取关键敏感数据从而实现攻击。
3.2 XSS攻击
xss攻击也是十分经典的，在前端发展历程中也是打不死的小强，现在已经衍生出了许多xss攻击策略。
- 存储型：经过后端+经过数据库
存储型攻击通常指攻击者在前端的表单上输入恶意脚本代码，后端将表单数据保存到数据库，之后通过读取数据库信息显示在前端。
如下所示，假设该表单是一个评论功能，后端将表单内容保存到数据库后展示在界面上。如果前端解析表单内容是通过innerHTML,那用户的cookie信息就会被窃取。
- 反射型：经过后端+不经过数据库
反射型攻击有个十分经典的案例，用过qq的小伙伴都知道每年都会爆料某诱骗链接伪造qq登录骗取用户登录信息造成个人数据泄露。这类诱导链接十分有趣，我本人也上当过。它的标题经常是"什么，你竟然和同班xxx一起合过影"等刺激信息诱骗用户点击进而输入个人账号信息。然后攻击者后端会收到用户输入的账号和密码进而盗窃。
- Dom型：前端
谈到dom型攻击，也是十分简单。根据名称就知道和dom元素相关。此类攻击方式是建立在dom节点上。如下例子
//正确的链接
<img src='http://www.baidu.com'/>
//错误的链接
<img src="http://error.com"/ onerror=()=>{alert(document.cookie())}>看了上面的例子，相比有的小伙伴有了点头绪，攻击者修改img标签的src，并给dom添加错误触发事件，当图片无法加载就会触发脚本代码从而获取用户信息。
3.3 CSRF攻击
csrf攻击又称为跨站伪造攻击，具体解释就是你在访问淘宝页面，此时一个yellow网站的弹窗突然出现，由于你经受不住好奇心，于是想一探究竟。然后你就进入这个yellow网站，由于你在淘宝页面有了登录状态，前端自动保存了cookie信息，当你在进入yellow网站时已经向它的后端发起了http请求，此时cookie身份信息就被这个yellow网站窃取了。
4.攻击防御的正确姿势
4.1 SQL注入防御
此处我们只是讨论前端在sql注入的防御措施，通常我们在表单提交时对sql语句的特殊变量进行转译，这样可以将其作为普通字符串处理而组织获取敏感信息。
4.2 XSS防御
- 针对登录方式的，可以采取扫码和动态验证码等结合方式
- 针对窃取用户cookie的，我们可以在后端设置httponly防止前端读取用户的cookie
- 不相信用户输入的任何数据，所有输入的数据应该在前端进行转译和限制，减少innerHTML的使用
4.3 CSRF防御
看了上面的CSRF攻击方式，我们可以总结以下防御手段
- 后端设置secure,这个字段保证了只有是https的网站才会将cookie携带，因为https都是经过安全认证的，一般不会存在问题
- 后端设置SameSites字段是Strict，这个字段称为严格模式，它会校验当前发起后端请求的网站是不是自己站点的，如果不符合不会携带cookie,有效的避免了危机。
- token验证机制，这个很有意思啊，有个面试官曾经问过这么一个问题，听过token可以防止csrf攻击，那你token放在哪里？是cookie还是localstorage上？这个要好好考虑，这个必须是放在localstorage上，如果放在未经后端严格设置的cookie上，还是会被第三方通过cookie获取到你的token密钥。由于localstorage在浏览器上存在同源机制，第三方打死都无法获取你localstoarge的值，除非第三方偷你电脑。所以我们可以将token放到localstorage上预防csrf攻击。
以上就是前端面试之对安全防御的理解分析的详细内容，更多关于前端面试安全防御的资料请关注脚本之家其它相关文章！