常见的web安全面试题
前言
以下总结的为前端常见的安全常识,也是面试必问的。没有大的技术含量,但需要知道。我们在自己的应用开发中,也需要避免这样的低级问题。
sql注入
描述
就是后端依赖前端返回的参数直接拼接sql进行查询数据,导致sql不正常的拼接,造成的安全问题。
解决方案
对前端传递的信息进行层层校验,不直接使用。
备注:由此延伸到,其实任何前端的传递数据都可能是有风险的、不严谨的,因此后端的任何接口针对传递参数都要进行非法校验,业务校验,然后才能实际使用。
XSS(Cross Site Scripting,跨站脚本攻击)
描述
简单来讲就是通过某种方式向你的代码中注入js代码,最常见的是通过表单的提交。然后因为这些代码与你的代码具有同等的权限,因此可以访问到你的数据信息,也可以进行一些数据的上报。因此,危害是很大的。
解决方案
针对一些输入的内容进行替换:
& 替换为:&
< 替换为:<
> 替换为:>
” 替换为:"
‘ 替换为:'
/ 替换为:/
另外针对性的对cookie加强控制,设置http-only,这样js就获取不到cookie的内容。
但是,针对富文本内容,简单的文本替换并不能解决问题,可以通过csp的方式解决,也就是建立白名单。
- 设置 HTTP Header 中的
Content-Security-Policy
- 设置
meta
标签的方式
如果是http,header的话,设置可以是这样:Content-Security-Policy: default-src ‘self’,这样就是只允许本网站的资源了。
CSRF(Cross-site request forgery,跨站请求伪造)
描述
CSRF 是借用了当前操作者的权限来偷偷地完成某个操作,而不是拿到用户的信息。
其借助的原理是:cookie的同源策略,只要登录之后,同域名的请求都不需要进行用户的验证。
解决方案
- 针对需要进行校验的操作,设置额外的验证,比如验证码、密码、指纹等;
- get请求改为post请求,更加安全;让get请求更多的只负责读操作;
- 验证document.referer,判断网页的上一个页面来源,微信支付就有这个验证的机制;
- token时效性机制,在进行某操作时,发送一个时效性的token,在进行某操作后续操作时,验证token是否相同;
- 验证网络ip,因为如果是非本机设备发起的请求,那么ip也会相比原来的ip是不同的,通过ip的对比也可以去除不安全的因素。
网页嵌套攻击
描述
通过iframe嵌套网站的页面,然后设计嵌套透明化,通过界面点击时,触发自己的事件。
解决方案
第一种: header设置不允许嵌套
X-FRAME-OPTIONS
是一个 HTTP 响应头,在现代浏览器有一个很好的支持。这个 HTTP 响应头 就是为了防御用 iframe
嵌套的点击劫持攻击。
该响应头有三个值可选,分别是
DENY
,表示页面不允许通过iframe
的方式展示SAMEORIGIN
,表示页面可以在相同域名下通过iframe
的方式展示ALLOW-FROM
,表示页面可以在指定来源的iframe
中展示
第二种:我们可以通过简单的js去判断当前界面是不是顶层窗口就可以解决这种问题了。
if(top.location!=self.location){
top.location.href = window.location.href;
}else{
alert("是顶层窗口");
}
中间人攻击
描述
也就是请求被拦截,然后可能被改写,或者被抽取重要信息,继续继续请求
解决方案
简单有效的:升级https方案
更多文档
- web安全面试题:链接
关于我
我是一名前端Coder,热爱分享生活与技术中的经验与心得。我是一名旅游爱好者,爱好拍摄旅途中的风景与人物。我是一名写作狂人,基本每天都有新文章产出,笔耕不辍。
个人站点
GitHub:http://github.com/robinson90codepen:https://codepen.io/robinson90personal blog: http://damobing.comyuque docs: https://www.yuque.com/robinsonjuejin blog: https://juejin.im/user/5a30ce0c51882561a20a768b
个人微信号与公众号
微信:csnikey,或者扫码加我
达摩空间订阅号:damo_kongjian,或者扫描下面的二维码