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攻击。

以上就是前端面试之对安全防御的理解分析的详细内容,更多关于前端面试安全防御的资料请关注本站其它相关文章!

点赞(0) 打赏

评论列表 共有 0 条评论

暂无评论

微信公众账号

微信扫一扫加关注

发表
评论
返回
顶部