前言

以下总结的为前端常见的安全常识，也是面试必问的。没有大的技术含量，但需要知道。我们在自己的应用开发中，也需要避免这样的低级问题。

sql注入

描述

就是后端依赖前端返回的参数直接拼接sql进行查询数据，导致sql不正常的拼接，造成的安全问题。

解决方案

对前端传递的信息进行层层校验，不直接使用。

备注：由此延伸到，其实任何前端的传递数据都可能是有风险的、不严谨的，因此后端的任何接口针对传递参数都要进行非法校验，业务校验，然后才能实际使用。

XSS（Cross Site Scripting，跨站脚本攻击）

描述

简单来讲就是通过某种方式向你的代码中注入js代码，最常见的是通过表单的提交。然后因为这些代码与你的代码具有同等的权限，因此可以访问到你的数据信息，也可以进行一些数据的上报。因此，危害是很大的。

解决方案

针对一些输入的内容进行替换：

& 替换为：&

< 替换为：<

替换为：>

” 替换为："

‘ 替换为：'

/ 替换为：/

另外针对性的对cookie加强控制，设置http-only,这样js就获取不到cookie的内容。

但是，针对富文本内容，简单的文本替换并不能解决问题，可以通过csp的方式解决，也就是建立白名单。

设置 HTTP Header 中的 Content-Security-Policy
设置 meta 标签的方式 <meta http-equiv="Content-Security-Policy">

如果是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/robinson90 codepen：https://codepen.io/robinson90 personal blog: http://damobing.com yuque docs: https://www.yuque.com/robinson juejin blog: https://juejin.cn/user/377887729918589

个人微信号与公众号

微信：csnikey,或者扫码加我

达摩空间订阅号：damo_kongjian，或者扫描下面的二维码