常见安全漏洞

---

前言

平常项目上线的时候大家都进行过漏洞扫描，漏洞扫描主要针对哪些漏洞呢？这些漏洞都是怎么处理的呢？本文就介绍几个常见的安全漏洞。

一、权限控制

垂直权限

垂直权限漏洞又叫功能权限漏洞，也就是我们上面说的URL访问控制问题。正常情况下我们使用的系统都是用户 -> 角色 ->菜单这种模型的，用户能操作哪些功能主要看用户所属角色是否有该功能的权限，假设系统的对于权限的控制仅仅是基于前端页面的隐藏，那对于大部分开发人员来说这是没有意义的，如果知道了对应菜单的URL就可以直接打开对应的菜单了。

以前就见过几个系统表单的提交和查看是通用一个页面，而且使用的是display：none、readonly：true来控制的，用户可以直接F12打开按钮继续提交修改，当然按钮的操作功能也是属于垂直权限的。

那么垂直权限问题怎么去预防解决呢？这可以在框架中使用一些成熟的RBAC权限框架，例如Shiro和Security等框架，在用户访问URL时需要去服务器验证用户是否真的具有该菜单或者功能的权限，常见的例如@Permission()注解等判定用户是否有接口操作权限，不要吝啬你的那行注解，权限控制不好出了问题就是大问题了。

水平权限

水平权限漏洞又叫数据权限漏洞，由于数据没有隔离，用户看到或操作了了不该看到的数据。假设在某个项目中用户能查看所在部门下面所有人的信息，但是只能修改自己的信息，但是对于程序员来说这些都不是问题，大不了调用接口的时候用户的ID传其他人的ID不就修改了别人的信息了吗。针对数据权限因为其业务性太强，没有专门的框架去支持数据权限，这需要在设计写代码的时候手动的去做校验的，修改或查看的时候在Where条件中加上用户ID或部门ID的判断，这就是为什么我们在创建数据库表的时候后面永远跟着创建人修改人和部门等字段信息，当然要根据业务实际情况判断是否需要增加判断条件。

二、SQL注入

SQL注入产生的主要原因就是后台SQL使用了字符串拼接，并且没有对用户输入的内容做限制。一般情况下用户是不知道系统的数据库类型和SQL语句的写法的，需要进行SQL盲注去试探出具体的信息。假设用户输入了这两种查询条件：实际ID’ and 1=1 # 结果显示查询出来了数据，而用户又输入了实际ID’ and 1=2 # 没有查询出来数据，可以看出来后面加的and条件生效了，存在SQL注入。SQL注入有效后用户就可以进行更多的SQL注入语句来获取数据库中更多的信息，不仅仅是该表数据甚至整个系统的数据库信息 (注入连表查询数据库结构)，最后相当于数据库完全对用户透明了。

怎么进行SQL注入防护呢？初级程序员面试的时候大多数都问过mybatis中#和￥(无法打出来美元符所以使用了这个)符的区别，使用￥就是SQL的拼接存在SQL注入，而#解析为占位符，里面的内容自动加了引号不存在SQL注入的情况。所以在开发过程中尽量避免使用￥拼接字符串。

三、XSS注入攻击

假设在某系统中有个评论功能，正常情况下我们希望用户输入的是文字信息，但是用户没有输入文字信息，而是输入了一段初始js代码，那么当其他人打开页面后，评论就会自动变为js代码执行，可能会出现窃取敏感信息或者跳转其他页面等情况，这是就是XSS攻击(跨站脚本攻击)。XSS攻击分为存储型XSS攻击、反射型XSS攻击和DOM型XSS攻击：存储型XSS的意思是XSS攻击脚本保存到了数据库中，就像我们上面举的例子，最终评论存放到了数据库中，这样的攻击持久性强；反射型XSS是临时性的，不会保存在数据库中，一般存在输入信息未保存数据库直接显示出来的接口；DOM型XSS攻击是不需要与服务器交互的攻击，利用的是DOM文档漏洞对用户看到的页面做了修改，一般存在页面跳转携带参数中携带内容直接加载到HTML中。XSS攻击的危害性也比较大，比如获取cookie信息乱发请求破坏数据、跳转其他网站窃取流量等。

XSS攻击主要的原因是没有对用户输入的信息做限制和处理，其防护就需要系统对输入的内容做过滤，例如有很多开源框架提供的XSS防护过滤器，可以对输入的内容中特殊字符进行转义；服务对于cookie信息一般设置为httpOnly为true，这样就无法在js中直接获取cookie信息；对于输出的DOM代码使用属性转义显示，而不是直接插入。

四、CSRF攻击

CSRF(跨站伪造攻击)，这个攻击与XSS攻击类似，但是攻击的手段略有不同。大家看小说可能看到过这么一个情节：

假设张三此时登录了网购网站，但是此时他的QQ或者邮件中收到了某个邮件，该邮件内部有个链接可能是啥中奖了或者大优惠等信息，张三心动了，于是点开了链接那么攻击就开始了，最后用张三的身份下了一堆订单，具体原理呢是张三此时在已经登录了系统，此时浏览器记录了系统的Cookie信息，当张三打开链接的时候也是在同一个浏览器中打开的，所以该链接的页面可以获取到网购系统中的Cookie，同时链接页面中存在一些脚本自动购买商品，这时采用了张三的Cookie信息发送了一堆订单。

上面所说的案例就是CSRF攻击，CSRF攻击的危害也比较大，而且用户的身份越高造成的危害越大，所以一般未知的连接最好不要随便点击，因为你当前登录的系统不一定是否安全。
CSRF攻击怎么解决呢？一般在服务代码中都会写拦截器对请求头referer来源的判断，如果用户打开某网站的情况下的请求来源判断为当前网站的网址发送过去的请求，例如我在CSDN网站内部发送的请求会携带这么一条信息：referer:https://blog.csdn.net/qq_19586549/category_11604010.html，同样我把该接口直接使用空白页面打开，此时请求头中没有携带referer信息。

五、文件操作漏洞

一般服务都会存在文件操作，包括文件的上传下载等功能，但是如果对应代码编写的不规范同样产生高危漏洞。

假设A网站中某功能中存在一个文件上传功能，但是该功能没有做文件限制，张三通过文件上传传递了一个shell脚本，当然此时shell脚本是无害的，因为没有执行，但是张三查看文件上传信息时由浏览器直接展示出了文件存储的位置等信息，张三通过一些手段访问到了文件存储的目录使shell脚本执行了，可能脚本文件把整个服务器给格式化了，系统直接崩了。

文件操作漏洞的危害也比较大，但是其触发比较难，因为它需要用户操作触发上传的文件后才能造成危害，我们一般在程序的上传功能都会对文件的格式进行限制，而且文件上传后会对其重命名操作，前端页面等显示出来的还是原来的名字但是实际上在服务器的文件已经改名了，同时设置上传文件的文件夹为不可执行的。