漏洞类型

漏洞名称

安全等级

要求内容

注入类

xml注入

高

通过手工篡改应用中xml实体中的头部，加入相关的读取文件或者命令执行等，如果可读取文件或者达到植入命令的效果，则存在该漏洞。

命令注入

高

对通过系统界面提交的已知的有害输入进行过滤，如例如“'”,“--”，“&”，“<”,“>”，“/”，“=”，“#”，“\r\n”，“\n\n”，“；”等字符，防止常见的SQL注入、XSS、等攻击行为。

SQL注入

高

远程代码执行

高

Xpath注入

高

链接注入

高

对通过系统界面（例如输入框、隐藏参数）提交的输入进行编码格式的检查，禁止通过转换编码逃避验证

跨站类

存储型XSS

高

对通过系统界面提交的已知的有害输入进行过滤，如例如“'”,“--”，“&”，“<”,“>”，“/”，“=”，“#”，“\r\n”，“\n\n”，“；”等字符，防止常见的SQL注入、XSS、等攻击行为

反射型XSS

中

DOM型XSS

中

客户端的脚本程序可以通过DOM来动态修改页面内容，从客户端获取DOM中的数据并在本地执行

CSRF跨站

中

html代码模拟提交form表单，查看功能提交结果

SSRF服务器端请求伪造

中

应用程序对用户提供的URL和远端服务器返回的信息是否进行合适的验证和过滤

敏感信息泄露

敏感信息泄露

高

非业务上的必要，敏感信息在终端上展示时应做模糊处理，在应用配置文件中应去除敏感信息，如部分内容以*方式传输及显示

敏感信息未模糊化

高

后台管理界面外网暴露

中

应保证应用系统的管理安全，后台管理界面（包括不限于：可操作管理多个账户，具有账号权限功能增删改权限的用户界面；可发布公告等内容管理的用户界面；可查询应用日志系统日志账户；可更改应用系统界面内容配置账户；）不能向互联网暴露。

js文件敏感信息泄露

中

在前端js文件中，查看是否存在敏感信息，如账户、密码、文件路径等

密码不应返回前端

中

认证数据加密存储：
1、用户名及密码尽可能不在客户端存储，若有必要，如cookie中暂存，应以加密方式存储；
2、密码在服务器或数据库中以摘要值方式存储：使用Hash+Salt,使用SHA2及以上强度的Hash算法。

内部IP地址泄露

中

BS应用页面源文件中不得包含敏感信息：如内部地址及路径等

WEB.XML配置文件泄露

高

配置文件中对敏感信息进行加密，如数据库连接用户密码等

中间件版本信息泄露

中

查看前端返回的信息中是否包含中间件版本信息

测试页面、示例文件未删除

中

1. 严格检查web中可访问的路径下是否存在备份文件，常见备份文件后缀为.jsp.bak、.bak、.sql、.txt、等等。如果有这些文件，直接将该备份文件进行转移到其他目录或者直接删除即可。

2、 严格控制可网站可访问目录下的文件敏感度的存放问题，不要将敏感文件置于该目录。

安装文件未删除

高

对网站直接进行漏洞扫描，查看可能存在的文件（.setup .war）

SVN文件信息泄露

高

不要使用svn checkout和svn up更新服务器上的代码，使用svn export代替。

备份文件泄露

高

对网站直接进行漏洞扫描，查看可能存在的文件（.git .svn .zip）

目录遍历

中

使用web扫描器进行检测，设置不当导致的可向不应能访问的目录遍历

服务器路径泄露

中

配置文件中对敏感信息进行加密，如数据库连接用户密码等

任意文件上传/下载漏洞

任意文件上传

高

文件上传应该验证文件的类型、文件头信息、大小

任意文件下载/读取

高

文件下载应该验证文件的类型、文件头信息、大小、权限

任意文件删除

高

文件删除应该验证文件的类型、权限

不安全的数据传输

启用不安全HTTP方法

中

使用options查看是否启用了put、delete、trace等方法

敏感信息明文传输

高

认证数据（包括用户名和密码）应加密传输：可采用加密的传输通道，或者以摘要方式传输，“互联网传输的BS架构应用应采用VPN链路加密或HTTPS（应采用TLS加密）；（适用于交易、支付类的关键应用系统的敏感数据页面或域名）”，互联网传输的CS架构应用应采用加密方式传输；登入过程口令加密（HASH），密码存储强度SHA 256以上。

敏感数据GET传输

中

1、不要在URL中暴露会话标识符，会话标识符应当只出现在http头信息中，不要将会话标识符以 GET 参数进行传递
2、使用HTTP POST方法代替GET方法来提交敏感信息表单，禁止使用表单的隐藏字段来传递敏感信息；不依赖HTTP头信息，对客户端提交的HTTP头进行过滤

脆弱的加密方式

中

对于互联网传输的敏感信息应采取加密方式传输，如用户名、密码、卡号、ID等。请求中含有敏感参数（如订单号、ID等），应加密处理后传输，防止产生参数遍历获取信息风险

逻辑权限

垂直越权访问

高

越权漏洞（平行，垂直） （更换账号UID OR 直接访问权限外URL）

水平越权访问

高

未授权访问

高

应用系统应具备访问控制功能：权限控制策略（例如权限控制矩阵等），防止越权操作，无账号访问。

用户密码重置漏洞

高

若支持密码重置功能，需通过账号绑定的手机或邮箱发送随机证码方式进行二次认证

支付漏洞

高

对涉及资金交易的传输内容应采取完整性保护措施（如效验参数是否完整、禁止不合法的传输内容被服务器接受并解析执行。）；对涉及资金交易的传输内容应采取完整性保护措施（如效验参数是否完整、禁止不合法的传输内容被服务器接受并解析执行

重放漏洞（认证、交易数据）

高

应采取时间戳、序列号等措施防止重放攻击及重复提交：
1、防认证信息重放：应具备防止通过重放抓取的认证数据报文或者cookie绕过身份验证过程；
2、防止交易数据重复接收处理：应具备防止因网络因素或人为有意行为的交易数据重复接收处理。

防篡改

高

使用签名机制对互联网接口传输数据进行签名，保证传输过程不被篡改。（例如，使用U盾、MAC消息认证码（信息完整性鉴别），对影响价格、会员积分等交易场景的数字参数信息进行效验，保证传输过程不被篡改）； 对涉及资金交易的传输内容应采用数字签名等抗抵赖措施

内网接口无校验访问

中

白名单方式或者登陆等方式对来自接口的任何请求数据。

互联网接口无校验访问

中

针对互联网接口调用，应对接口进行访问控制，防止非授权对象调用。访问控制方式，包括不限于身份认证、证书和IP白名单方式

未验证的URL跳转

中

修改参数中的合法URL为非法URL，然后查看是否能正常跳转

安全功能设计不健全

短信轰炸

高

1、 合理配置后台短信服务器的功能，对于同一手机号码，发送次数不超过3-5次，并且可对发送的时间间隔做限制。
2、 页面前台代码编写时，加入禁止针对同一手机号进行的次数大于N次的发送，或者在页面中加入验证码功能，并且限制发送的时间间隔

短信验证码重复利用

高

在服务端设置校验失效期，每次校验后，无论校验是否通过都对验证码进行刷新处理。

短信验证码未绑定

高

在服务端校将验证码与手机号绑定，确保短信验证码与绑定手机号一一对应。

图形验证码返回到前端

中

禁止将验证码返回给客户端。

短信验证码返回到前端

高

短信验证码可爆破

高

设置验证码的过期时间（5分钟或15分钟失效）且服务器端每次校验后须刷新验证码，防止暴力破解验证码。

登录认证可被绕过

高

修改验证逻辑，如是否登录成功服务器端返回一个参数，但是到此就是最终验证，不需要再对返回的参数进行使用并作为登录是否成功的最终判断依据！

短信内容可控

中

短信验证码应只以短信方式发送到指定手机号，不再客户端进行发送和返回。

邮件验证码安全

中

在服务端中对发送接收的邮箱做二次验证。

验证码可识别

中

采取一定的干扰措施且不可预测，如字体倾斜，加背景噪点、横线等

验证码长度可控

中

验证码不因在前端生成与验证，应由服务端生成并对传来的数据包进行验证码的验证

无图形验证码功能

中

为应用系统加上验证码功能

验证码机制过于简单

中

图形验证码需由服务端生成并进行验证，不在前端与response中返回

前端可控的验证码生成机制

中

验证码不因在前端生成与验证，应由服务端生成并对传来的数据包进行对验证码的验证

图形验证码机制可以被绕过

中

1、 系统在开发时注意验证识别后销毁session中的验证码。
2、 限制用户提交的验证码不能为空
3、 判断提交的验证码与服务器上存储的是否一致
4、 禁止将验证码明文信息发送至客户端

短信验证码机制可以被绕过

高

1. 若存在特权验证码，建议将其删除；
2. 应用服务端应严格校验验证码参数是否为空，格式是否正确；
3. 关键操作每提交一次请求，应发送新的短信验证码，不可继续使用旧的验证码。

更改密码时不需要输入原密码

中

修改密码时需要对当前用户身份进行校验，如对旧密码进行校验或者通过即时的短信验证码进行校验。

验证码可重复利用

中

在服务端进行校验失效期，关键操作每提交一次请求，应刷新验证码，并且不可继续使用旧的验证码。

无账号锁定机制

中

对采用密码进行认证的系统，应防止密码暴力猜测，连续登录失败5次数后锁定账号。账号锁定后可以由系统管理员解锁，也可以在一段时间（30分钟）后自动解锁；

展业系统单因素认证

中

对互联接入的展业系统（除了微信、支付宝以外的应用），应采用两种或两种以上的方式进行身份认证：用户名口令、动态密码、USB证书

用户账户可重复

中

用户帐号（包括管理员及普通用户）应具有唯一性，保证应用系统中不存在重复用户帐号

强密码机制检测

中

应用系统后台未强制用户设置强密码，导致在注册、密码重置等功能模块可以使用弱密码，易被攻击者暴力猜接。

弱口令

高

不可以使用弱密码、弱口令等。

不安全的错误提示（单独提示账户、密码错误等）

中

身份验证的失败提示信息采用模糊处理，比如可以使用“用户名或密码错误”，而不要使用“用户名错误”或者“密码错误”明确提示。（适用于面向客户的系统）

不安全的配置

反序列化漏洞

高

使用扫描器或人工测试，常见中间件，weblogic、websphere等存在java反序列化漏洞

应用程序调试信息泄露

中

当系统发现异常访问或出故障时，统一出错提示，应避免敏感信息泄露及显示详细错误信息

jQuery 版本漏洞

中

应用系统若采用第三方组件，应使用不存在已知安全漏洞的第三方组件版本

Robots文件配置（互联网应用）

中

配置Robots.txt，默认禁止对根目录的爬行。业务按需列出允许爬虫访问范围，防止访问敏感数据

会话管理

会话标识未更新

中

用户登录后需要使用新的会话标识，并且会话标识的生成应具有随机性

登录信息直接写入cookie

中

认证数据加密存储：
1、用户名及密码尽可能不在客户端存储，若有必要，如cookie中暂存，应以加密方式存储；
2、密码在服务器或数据库中以摘要值方式存储：使用Hash+Salt,使用SHA2及以上强度的Hash算法。

会话固定

中

用户注销会话后，不能通过使用浏览器的回退按钮来显示

账号可同时登陆

中

应能对单个账号的重复登录（同一账号同时在不同的终端上登录）进行限制（原则上不超过2个），出现重复登录时，给出明确提示

未启用会话超时功能

中

具有登录功能的互联网网站及APP应具有会话超时退出机制，系统涉及交易支付和查询、个人信息修改等页面，需重新对用户进行认证且会话超时时间不得大于15分钟，认证方式可选择密码、短信等”

cookie属性安全

中

应保证cookie安全性：如启用HttpOnly属性，使用临时性Cookie取代永久性Cookie，不使用Cookie定制信息，敏感Cookie需加密保存，HTTPS协议下应启用Secure属性；

其他

JBOSS远程代码执行

高

JBOSS默认配置会有一个后台漏洞，漏洞发生在jboss.deployment命名空间中的addURL()函数,该函数可以远程下载一个包含shell的war压缩包并解压，给jmx-console加上访问密码

Struts2远程代码执行

高

检测方式查看web目录下/WEB-INF/lib/目录下的struts-core.x.x.jar，如版本在Struts2.3.5 到 Struts2.3.31 以及 Struts2.5 到 Struts2.5.10之间则存在漏洞，更行至Strusts2.3.32或者Strusts2.5.10.1，或使用第三方的防护设备进行防护。

WebLogic Server远程代码执行漏洞

高

目前， Oracle官方已经发布补丁修复了漏洞，建议用户及时确认是否受到漏洞影响。