前端安全之常见漏洞及防御
随着项目复杂度的提升以及用户体量的增大，前端安全变得越来越重要。平时系统运行正常，一旦出现安全问题，轻者部门扣分，严重的可能对公司造成严重损失。了解一些常见漏洞，平时coding时注意，防患于未然。
一. 漏洞分类
分类 | 特点 |
|---|---|
跨站脚本攻击 | 任意内容在展示到页面之前，对内容中的特殊字符进行转义，避免产生XSS跨站脚本攻击等前端漏洞。 |
跨站请求伪造 | 网站必须部署防御 CSRF 攻击的解决方案，每个接口都需要校验 Referer 和 csrf_token。重要接口需要对重放攻击进行防御 |
服务端请求伪造 | 程序中如有对外发送请求的功能，必须严格限制发送的目标和内容的类型；对于只需要请求公网的功能点，必须限制其向内网发送请求。 |
任意文件读取 | 程序在读取本地文件时，需要对读取的目录范围和文件名称禁止限制，避免跨目录读取敏感文件； |
任意文件上传 | 若程序带有文件上传功能，必须在服务端代码中严格限制允许上传的文件类型；存放文件的目录需要与程序代码隔离 |
SQL注入 | 程序中应具有抵御SQL注入漏洞的能力。需采用预编译等方式执行数据库操作，禁止把传入参数直接拼接在SQL语句中。 |
命令注入 | 避免程序直接调用操作系统命令，在执行前必须检查命令中的是否有非法的特殊字符。 |
跳转漏洞 | 进行url跳转时，禁止跳转到其他非相关域名，含非公司域名及公司其他非相关业务域名 |
越权漏洞 | 在执行用户提交的操作前，必须校验提交者与操作目标的关系，禁止未经授权操作其它用户的数据，同时也需要避免普通用户执行管理员层级的操作，避免产生权限绕过、水平越权和垂直越权漏洞。 |
二. 常见漏洞
XSS漏洞
通过将恶意得Script代码注入到Web页面中，当用户浏览该页之时，嵌入其中Web里面的Script代码会被执行，从而达到恶意攻击用户的目的。
场景
盗取账户，网站挂马，植入广告或垃圾信息，篡改页面等。
Xss分类
- 反射型xss 原理：发出请求时，XSS代码出现在url中，作为输入提交到服务器端，服务器端解析后响应，XSS代码随响应内容一起传回给浏览器，最后浏览器解析执行XSS代码。这个过程像一次反射，所以叫反射型XSS，可能引导用户点击链接盗取用户信息
- 存储型xss 又叫持久型，它是三种xss里危害最大的一种。是由于恶意攻击代码被持久化保存到服务器上，然后被显示到HTML页面之中。这类漏洞经常出现在用户评论的页面，攻击者精心构造XSS代码，保存到数据库中，当其他用户再次访问这个页面时，就会触发并执行恶意的XSS代码，从而窃取用户的敏感信息
- DOM型xss 基于dom的漏洞，它的攻击代码并不需要服务器解析响应，触发XSS靠的是浏览器端的DOM解析。客户端上的JavaScript脚本可以访问浏览器的DOM并修改页面的内容，不依赖服务器的数据，直接从浏览器端获取数据并执行。比如读取url或外部输入插入到网页中，如果没有xss过滤转义，极易触发DOM型XSS漏洞。
防御
- Url、表单输入过滤。将用户输入的内容进行过滤。对所有用户提交内容进行可靠的输入验证，包括对 URL、查询关键字、POST数据等，仅接受指定长度范围内、采用适当格式、采用所预期的字符的内容提交，对其他的一律过滤。(客户端和服务器都要)
- 输入转义。往html中插入数据、把字符串转成html时，对数据进行字符实体编码
function htmlEncodeByRegExp (str){
var s = "";
if(str.length == 0) return "";
s = str.replace(/&/g,"&");
s = s.replace(/</g,"<");
s = s.replace(/>/g,">");
s = s.replace(/ /g," ");
s = s.replace(/\'/g,"'");
s = s.replace(/\"/g,""");
return s;
}- cookie设置为httponly。浏览器端不能访问cookie
CSRF漏洞（Cross Site Request Forgery，跨站请求伪造）
跨站点请求伪造漏洞：用户以当前身份浏览到flash或者第三方网站时，JS/flash可以迫使用户浏览器向任意CGI发起请求，此请求包含用户身份标识，CGI如无限制则会以用户身份进行操作。
场景
- 登录受信任网站A，并在本地生成Cookie。（如果用户没有登录网站A，那么网站B在诱导的时候，请求网站A的api接口时，会提示你登录）
- 在不登出A的情况下，访问危险网站B，网站B请求网站A的接口（其实是利用了网站A的漏洞）
防御
- 设置referer白名单，验证 HTTP Referer 字段。如果是以自身安全网站开头的域名，则说明该请求是是合法的。如果 Referer 是其他网站的话，则有可能是黑客的 CSRF 攻击，拒绝该请求。
- 在请求地址中添加token并验证。重要信息不通过cookie，在请求中以参数形式加入一个随机产生的token，并在服务器验证该token，不正确则拒绝该请。
- 在http头中添加自定义属性并验证。和token类似，只是把token放在自定义头信息中.
- 重要操作添加验证码。
SSRF漏洞 （Server-Side Request Forgery，服务器端请求伪造）
危害为服务器代替攻击者发送一个外界不可达的请求（服务器本机或所处内网），导致安全边界内资产遭受攻击或者信息被暴露的漏洞，在庞大的内网环境下，ssrf被评为高危漏洞。
场景：访问node提供的服务，下载其他存储桶的cos文件，由于没有校验域名，导致cos回源暴露内网信息，该漏洞被内网安全扫描检测到。
防御
- 校验外部传入的域名是否在白名单。设置一个域名白名单，判断域名合法性。适用场景：拉取文件或接口资源时没有对导致进行判断导致请求外部传入的恶意地址
- 校验外部传入的域名是否恶意。判断ip是否指向内网。
- 物理隔离下载代理。可对发送请求的机器使用iptables进行物理隔离；也可配置专用下载proxy，对代理机器进行物理隔离。ssrf的根本在与发送内网和本地资源的攻击请求，因此适用云服务器和物理隔离服务器。
其他防御方式 更多漏洞待更新