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攻击。
以上就是前端面试之对安全防御的理解分析的详细内容,更多关于前端面试安全防御的资料请关注本站其它相关文章!
本站资源均来自互联网,仅供研究学习,禁止违法使用和商用,产生法律纠纷本站概不负责!如果侵犯了您的权益请与我们联系!
转载请注明出处: 免费源码网-免费的源码资源网站 » 前端面试之对安全防御的理解分析
发表评论 取消回复