常见的安全问题和修复建议

概要

主要整理一些工作碰到的系统安全问题和修复方式，不定期维护中

一、明文传输

漏洞现象

在初始密码重置，修改用户信息，重置密码时传输参数直接使用明文展示，暴露了用户信息

修复建议

加密传输，建议使用rsa(md5(明文)+时间戳)，不建议直接使用md5加密

二、弱口令

漏洞现象

在修改用户信息，重置密码时没有对密码强度进行验证，或者初次使用初始密码登录时没有提示进行密码重置

修复建议

1、密码设计遵循密码复杂策略

• 密码长度至少8位
• 大小写字母
• 三种字符（数字、字母、特殊符号）

2、密码避免出现姓名、身份证、生日、单位信息、电话号码等

3、初始密码登录时需要提示用户进行密码重置

三、XSS

漏洞现象

1、DOM型XSS：

基于文档对象模型Document Objeet Model，DOM)的一种漏洞。DOM是一个与平台、编程语言无关的接口，它允许程序或脚本动态地访问和更新文档内容、结构和样式，处理后的结果能够成为显示页面的一部分。DOM中有很多对象，其中一些是用户可以操纵的，如uRI ，location，refelTer等。客户端的脚本程序可以通过DOM动态地检查和修改页面内容，它不依赖于提交数据到服务器端，而从客户端获得DOM中的数据在本地执行，如果DOM中的数据没有经过严格确认，就会产生DOM XSS漏洞。

DOM型XSS其实是一种特殊类型的反射型XSS，它是基于DOM文档对象模型的一种漏洞。

2、存储型XSS<持久化>

代码是存储在服务器中的，如在个人信息或发表文章等地方，加入恶意代码，如果没有过滤或过滤不严，那么这些代码将储存到服务器中，每当有用户访问该页面的时候都会加载恶意代码并触发代码执行，这种XSS非常危险，容易造成蠕虫，大量盗窃cookie。

这种方式相对反射型XSS难度大，但是危害高。

3、反射型XSS<非持久化>：
post型：攻击者事先制作好攻击链接，欺骗用户自己去点击链接才能触发XSS代码（服务器中没有这样的页面和内容），一般容易出现在搜索页面，或者以邮件的方式发送后，欺骗用户点击恶意连接。
（1）随便输入字符qweasd，点击submit

（2）输入

（3）弹出对话框，说明存在xss漏洞，一次性的。

假设输入的脚本是发起一个请求，可是是对我们服务器的请求，用户根本没有操作的情况直接出发了一次新闻发布操作？或者读取当前网站的个人信息发送到攻击者的服务器去，用户信息就被收集走了。

刚才是以POST的方式实现xss注入，反射型好像没啥用？如果以get的方式出现，我们有个后台地址是新闻发布页面是http://IP:port/admin/fabu?type=1 页面，这里可以发布新闻，如果type参数存在xss漏洞，我把他改成http://IP:port/admin/fabu?type=恶意代码，比如发布一个敏感新闻，以邮箱的方式发个你用户；用户在登录页面（或者曾经登录后有免登陆功能），当用户点击后，直接完成一次新闻发布。

修复建议

主要以过滤输入输出内容为主，过滤一些特殊的字符达到防止脚本执行。

四、登录爆破

漏洞现象

在登录页面多次输入错误密码没有进行限制，或者重复使用同一个验证码可以正常登录等

修复建议

1、配置登录锁定，错误次数达上限时锁定账号
2、配置验证码机制，确保验证码一次有效

五、SQL注入漏洞

漏洞现象

使用使用appscan和awvs扫描，可以实现注入拿下库表

修复建议

1、安装防火墙：等等D盾，业务系统需要评估是否有影响
2、SQL注入绕过技术

• 大小写绕过注入
  有些人关键字里面只有小写或者大写，使用大小写混编可以绕过，比如and 写成 And，select 写成Select等等
• 双写绕过注入
  有些是使用关键字过滤，比如and 1=1，过滤后是1=1，那么写成aandnd 1=1，过滤后就是and 1=1
• 编码绕过注入
  比如对参数进行url编码或者base64编码，服务端有可能自动解码，也有可能是程序员有意解码，这样可以绕过检测
• 其他复杂的绕过技术可以查看更多
  3、如何防范sql注入？
• 最简单的就是所有sql入参不能使用字符直接拼接，使用预编译语句，也就是入参一定都是以参数的形式给数据库执行。mybatis表现为，不能使用${参数}这样的格式接收参数，或者直接前端接收后直接拼接大要执行的sql里，所有参数使用#{参数}格式进行入参。
• 如果实在要使用拼接的方式一定要做好验证，比如按类型数字、时间、布尔型直接验证类型再拼接，字符型那就是靠过滤规则来过滤。

修复建议

1、提供二次配置验证权限功能，解决在编码过程中没有考虑越权的事
2、自己写逻辑验证的思路

• 前后端同时对用户输入信息进行校验，双重验证机制
• 调用功能前验证用户是否有权限调用相关功能
• 执行关键操作前必须验证用户身份，验证用户是否具备操作数据的权限
• 直接对象引用的加密资源ID，防止攻击者枚举ID，敏感数据特殊化处理
• 永远不要相信来自用户的输入，对于可控参数进行严格的检查与过滤

六、CSRF

漏洞现象

替换refer链接，可以正常返回接口信息

修改建议

1、增加referer验证（最简单直接，我们也是这么做的，对get请求有问题，但是我们基本是post进行数据处理的）
2、增加token防护 （token验证一次失效，入侵性太强了，虽然安全但是业务项目基本没办法这么做）
3、使用验证码（每次做个请求弹个验证码？不太现实）
4、拓展链接，另外建议使用https加密传输可以有效降低传输数据的泄露，这样想要做个伪造网站之前还得先破解登录机制获取基础的用户权限。

七、越权漏洞

漏洞现象

接口没有进行token验证

八、敏感信息泄露

漏洞现象

如用户信息，部门信息等敏感的接口未授权可以直接访问，中间件的版本号直接展示

修改建议

1、加入用户身份认证机制或token验证，对系统的功能点增加权限控制、设置目录访问权限
2、通过修改配置文件，禁止中间件（如IIS、apache、tomcat）的文件目录索引功能
3、不影响业务或功能的情况下删除或禁止访问泄露敏感信息页面。