漏洞名称

目录索引漏洞

漏洞地址

漏洞等级

中危

漏洞描述

Web应用架构中的目录都采用常见的目录名，如图片目录images，javascript目录js，不同的目录潜在的危险是不同的。攻击者一般利用常见目录中可能包含的敏感文件获取敏感信息。自动目录索引是Web服务器的一个功能，如果请求目录中不存在常规文件（index.html，home.html，default.html），Web服务器会枚举该目录下所有的文件，攻击者可以通过返回的目录索引信息获得当前目录下的文件列表，从而根据文件中可能存在的漏洞攻击服务器。

漏洞成因

中间件配置错误导致攻击者可以通过返回的目录索引信息获得当前目录下的文件列表，从而根据文件中可能存在的漏洞攻击服务器。

漏洞危害

攻击者可以通过返回的目录索引信息获得当前目录下的文件列表，从而根据文件中可能存在的漏洞攻击服务器。

修复方案

Apache

修改站点目录对应的配置文件httpd.conf

  Options FollowSymLinks

  AllowOverride All

  Order allow,deny

  Allow from all

  Require all granted

大家都见过很多框架的每个目录都有一个index.html文件，这个文件的存在是非常有意义的，很多线上的Web服务器都没有合格配置列出目录索引，导致网站内部许多文件都能被攻击者查看，从而泄漏大量信息。

为了防止列出目录索引，我们可以在站点的每个文件夹中创建一个index.html，这个文件内容是什么都无所谓。当攻击者想通过列目录的手法访问你站点文件夹的时候，Web服务器将会判断当前目录下有没有DirectoryIndex默认首页，如果存在就显示DirectoryIndex对应的文件名的内容，这样攻击者就无法查看该目录下有什么文件。

Tomcat

修改conf/web.xml配置文件

  listings 

  false

Nginx

修改conf/nginx.conf配置文件

location / {

  index  index.html index.htm index.php l.php;

  autoindex off; 

}

IIS

设置“目录浏览”权限。

测试过程

复测过程

复测结果

未修复

漏洞名称

CSRF跨站请求伪造漏洞

漏洞地址

漏洞等级

中危

漏洞描述

跨站请求伪造(也称为CSRF)是一个Web安全漏洞，它允许攻击者诱导用户执行他们不打算执行的操作。它允许攻击者绕过部分同源策略，该策略旨在防止不同网站之间相互干扰。

漏洞成因

数据采用GET或POST请求，数据包中各参数均为用户可控参数，没有设置CSRF-Token，没有验证Referer字段，没有图形验证码和短信、邮件验证码，同时也没有校验非标准Http头部X-Requested-With: XMLHttpRequest，没有设置自定义的Http头部字段，所以综上判断存在网站存在CSRF漏洞。

漏洞危害

在成功的CSRF攻击中，攻击者会有意识地引导受害用户执行一个操作。例如，这可能是更改他们账户上的电子邮件地址，更改他们的密码或进行资金转账。根据动作的性质，攻击者可能能够获得对用户帐户的完全控制。如果被攻击的用户在应用程序中拥有特权角色，那么攻击者可能能够完全控制应用程序的所有数据和功能。

修复方案

1.使用CSRF-Token：业界一致的做法是使用一个CSRF-Token。

CSRF攻击之所以能够成功是因为攻击者可以伪造用户的请求，对此最好的防御手段就是让攻击者无法伪造这个请求。因此，我们可以在Http请求中（千万不要放在Cookie中）以参数的形式添加一个随机的CSRF-Token，并在服务端检查这个CSRF-Token是否正确，如不正确或不存在，则可以认为是不安全的请求，拒绝提供相关服务。

注意：

如果网站同时还存在XSS漏洞时，上述CSRF-Token的方法将可能失效，因为XSS可以模拟浏览器执行操作，攻击者通过XSS漏洞读取CSRF-Token值后，便可以构造出合法的用户请求了。所以在做好CSRF防护的同时，相应的安全防护也应做好。

2.验证Referer字段

在通常情况下，访问一个安全受限页面的请求来自于同一个网站，Http头部中的Referer字段记录了该Http请求的来源地址，如果Referer中的地址不是来源于本网站或不存在则可认为是不安全的请求，对于该请求应予以拒绝。这种方法简单易行，对于现有的系统只需在加上一个检查Referer值的过滤器，无需改变当前系统的任何已有代码和逻辑。

但是，这种方法存在一些问题需要考虑：首先，Referer的值是由浏览器提供的，虽然Http协议上有明确的要求，但是每个浏览器对于Referer的具体实现可能有差别，并且不能保证浏览器自身没有安全漏洞，将安全性交给第三方（即浏览器）保证，从理论上来讲是不可靠的；其次，用户可能会出于保护隐私等原因禁止浏览器提供Referer，这样的话正常的用户请求也可能因没有Referer信息被误判为不安全的请求，无法提供正常的使用。

注意：

如果网站同时还存在XSS漏洞时，上述方法将可能失效，因为XSS可以模拟浏览器执行操作，构造出合法的用户请求，这样Referer字段记录的依然是本网站的地址从而可以绕过Referer校验。所以在做好CSRF防护的同时，相应的安全防护也应做好。

3.添加验证码机制（图形验证码或者短信验证码、邮件验证码）

在用户提交数据之前，让用户输入验证码，或者用户在进行关键操作时，让用户重新输入密码进行验证。

4.校验非标准Http头部X-Requested-With

XMLHttpRequest，我们可以在服务端检查这个非标准Http头部X-Requested-With:XMLHttpRequest是否存在，如不存在，则可以认为是不安全的请求，拒绝提供相关服务。

注意：

如果网站同时还存在XSS漏洞或者开启CORS支持时，上述方法将可能失效，因为XSS可以模拟浏览器执行操作，构造出合法的AJAX用户请求，从而绕过非标准Http头部X-Requested-With:XMLHttpRequest校验，所以在做好CSRF防护的同时，相应的安全防护也应做好。

5.设置自定义的Http头部字段，比如CSRF:Token

我们可以在服务端检查这个自定义的Http头部字段是否存在，如不存在，则可以认为是不安全的请求，拒绝提供相关服务。

注意：

如果网站同时开启CORS支持时，上述方法将可能失效，因为攻击者可以模拟浏览器执行操作，构造出合法的AJAX用户请求，从而绕过自定义的Http头部字段校验，所以在做好CSRF防护的同时，相应的安全防护也应做好。

测试过程

数据采用GET或POST请求，数据包中各参数均为用户可控参数，没有设置CSRF-Token，没有验证Referer字段，没有图形验证码和短信、邮件验证码，同时也没有校验非标准Http头部X-Requested-With: XMLHttpRequest，没有设置自定义的Http头部字段，所以综上判断存在网站存在CSRF漏洞。

构造CSRF利用代码：

GET请求：

         history.pushState('', '', '/');

复测过程

复测结果

未修复

漏洞名称

CORS跨域资源读取漏洞

漏洞地址

漏洞等级

中危

漏洞描述

跨域资源共享(CORS)是一种放宽同源策略的机制，它允许浏览器向跨源服务器，发出 XMLHttpRequest 请求，从而克服了AJAX只能同源使用的限制，以使不同的网站可以跨域获取数据，跨域资源共享CORS漏洞主要是由于程序员配置不当，对于 Origin 源校验不严格，从而造成跨域问题，攻击者可以利用CORS错误配置漏洞，从恶意网站跨域读取受害网站的敏感信息。

漏洞成因

程序员配置不当，对于Origin源校验不严格。

漏洞危害

攻击者可以利用CORS错误配置漏洞，从恶意网站跨域读取受害网站的敏感信息。

修复方案

1.禁止配置“Access-Control-Allow-Origin”为“*”和“null”；

2.严格校验“Origin”值，避免出现权限泄露；

3.避免使用“Access-Control-Allow-Credentials:true”；

4.减少“Access-Control-Allow-Methods”所允许的方法。

测试过程

数据采用GET或POST请求，数据包中各参数均为用户可控参数，没有设置CSRF-Token，没有验证Referer字段，没有图形验证码和短信、邮件验证码，同时也没有校验非标准Http头部X-Requested-With: XMLHttpRequest，没有设置自定义的Http头部字段，access-control-allow-credentials: true同时access-control-allow-origin的值随着Origin的值而变化，所以综上判断存在网站存在CORS跨域资源读取漏洞。

构造CORS跨域资源读取漏洞利用代码：

GET请求：

复测过程

复测结果

未修复

漏洞名称

弱口令漏洞

漏洞地址

漏洞等级

高危

漏洞描述

1.连续或重复的数字，如123123、123456、987654、111111、222333等；

2.连续或重复的字母，如aaa、abc、abcdef、zyx等；

3.键盘上常见的连续按键，如：[email protected]、qwert、asdfghjkl;、！@#、147258369（数字键盘）等；

4.日期或年份，如800128（生日）、2012、19251120等；

5.与用户相关的名称信息，如newdoone（公司名称）、shaoyuanming（姓名全拼）、sym（姓名缩写）、oa（产品名称）、admin（用户名）、手机号等；

6.具有特殊含义的字符串，如520、1314、woaini；

7.其他常用的字符串：root、abc123！、administrator、test等。

以上元素被许多人用来构成好记的口令，而攻击者也会使用上述素材相互组合来生成弱口令字典。如newdoone123（公司名称+连续数字）、[email protected]#（连续字母+键盘按键）、asdf520（键盘按键+特殊含义字符）、shaoyuanming2012（用户名+年份）等，符合上述规律的都可以认为是弱口令。

漏洞成因

造成弱口令的主要原因是系统的运维人员、管理人员安全意识不足。

漏洞危害

攻击者利用该漏洞可以访问成功登录应用系统后台，导致敏感信息泄露，甚至可以获取管理员权限。

修复方案

使用相对安全的口令，防止口令被穷举或字典法猜出，还应加强口令安全。

主要措施如下：

（1）口令长度不小于8位，并应包含大写/小写字母，数字和特殊字符，并且不包含全部或部分的用户账号名；

（2）避免使用英文单词、生日、姓名、电话号码或这些信息的简单组合作为口令；

（3）不要在不同的系统上使用相同的口令；

（4）定期或不定期地修改口令；

（5）使用口令设置工具生成健壮的口令；

（6）对用户设置的口令进行检测，及时发现弱口令；

（7）限制某些网络服务的登录次数，防止远程猜测、字典法、穷举法等攻击。另外还需加强员工安全意识培训，登录口令，如系统/管理后台等最好升级为双因子认证方式。

测试过程

复测过程

复测结果

未修复

漏洞名称

明文传输漏洞

漏洞地址

漏洞等级

中危

漏洞描述

应用系统采用http协议传输敏感数据，登录、注册等功能模块请求数据未采用强加密传输方式，用户名、口令或者其他敏感数据未经强加密即进行了数据传输。

http网站是明文传输，从浏览器到服务器之间的传输的信息是明文，非常容易被非法侦听、非法窃取和非法篡改！

https网站是加密传输，从浏览器到服务器之间的传输的信息是密文，防止非法侦听、非法窃取和非法篡改！

漏洞成因

应用系统采用http协议传输敏感数据，登录、注册等功能模块请求数据未采用强加密传输方式，用户名、口令或者其他敏感数据未经强加密即进行了数据传输。

http网站是明文传输，从浏览器到服务器之间的传输的信息是明文，非常容易被非法侦听、非法窃取和非法篡改！

https网站是加密传输，从浏览器到服务器之间的传输的信息是密文，防止非法侦听、非法窃取和非法篡改！

漏洞危害

攻击者可以窃听网络以劫获用户密码等敏感信息。

修复方案

1.应用系统采用https协议传输敏感数据。

2.敏感字段采用强加密传输，至少应采用md5($pass.$salt)或者md5($salt.$pass)强度加密方式，禁止采用简单MD5加密甚至base64编码或者变形处理。

测试过程

复测过程

复测结果

未修复

漏洞名称

未加密登录请求漏洞

漏洞地址

漏洞等级

中危

漏洞描述

登录、注册等功能模块请求数据未采用强加密传输方式，用户名、口令或者其他敏感数据未经强加密即进行了数据传输。

漏洞成因

登录、注册等功能模块请求数据未采用强加密传输方式，用户名、口令或者其他敏感数据未经强加密即进行了数据传输。

漏洞危害

攻击者可以窃听网络以劫获用户密码等敏感信息或者通过暴力猜解等手段登入应用系统后台。

修复方案

敏感字段采用强加密传输，至少应采用md5($pass.$salt)或者md5($salt.$pass)强度加密方式，禁止采用简单MD5加密甚至base64编码或者变形处理。

测试过程

复测过程

复测结果

未修复

漏洞名称

SQL注入漏洞

漏洞地址

漏洞等级

高危

漏洞描述

SQL注入是开发者对用户输入的参数过滤不严格，通过把SQL命令插入到Web表单提交、输入域名或页面请求的查询字符串，最终达到欺骗服务器执行恶意的SQL命令，导致用户输入的数据能够影响预设查询功能的一种技术。它是一种通过在用户可控参数中注入SQL语句，破坏原有的SQL结构，达到编写程序时意料之外结果的攻击行为。

按照构造和提交SQL语句的方式进行划分，SQL注入又分为GET型注入、POST型注入和Cookies型注入。

GET 型 SQL 注入提交数据的方式为 GET , 注入点的位置在 GET 参数部分，通常发生在网页的 URL。

POST 型 SQL 注入使用 POST 方式提交数据，注入点位置在 POST 数据部分，通常发生在表单输入框中。

Cookie 型 SQL 注入HTTP 请求时通常有客户端的 Cookie, 注入点存在 Cookie 的某个字段中。

漏洞成因

Web应用程序对用户输入的数据校验处理不严或者根本没有校验，使用字符串拼接的方式构造SQL语句，同时未对用户可控参数进行足够过滤，致使用户可以拼接执行SQL命令造成SQL注入漏洞。

漏洞危害

1.在有写文件权限的情况下，直接用INTO OUTFILE或者DUMPFILE向Web目录写文件，或者写文件后结合文件包含漏洞达到代码执行的效果。

2.在有读文件权限的情况下，用load_file()函数读取网站源码和配置文件，获取敏感数据。

3.提升权限，获得更高的用户权限或者管理员权限，绕过登录，添加用户，调增用户权限等，从而拥有更多的网站功能。

4.通过注入控制数据库查询出来的数据，控制如模板、缓存等文件的内容来获取权限，或者删除、读取某些关键文件。

5.在可以执行多语句的情况下，控制整个数据库，包括控制任意数据、任意字段长度等。

6.在SQL Server这类数据库中可以直接执行系统命令。

7.数据库原有数据泄露、篡改甚至删除，甚至导致攻击者完全控制服务器。

修复方案

参考资料：

https://github.com/Tencent/secguide/blob/main/Java%E5%AE%89%E5%85%A8%E6%8C%87%E5%8D%97.md

1.Web后台系统应默认使用预编译绑定变量的形式创建sql语句，保持查询语句和数据相分离。以从本质上避免SQL注入风险。

如使用Mybatis作为持久层框架，应通过#{}语法进行参数绑定，MyBatis 会创建 PreparedStatement 参数占位符，并通过占位符安全地设置参数。

示例：JDBC

String custname = request.getParameter("name");

String query = "SELECT * FROM user_data WHERE user_name = ? ";

PreparedStatement pstmt = connection.prepareStatement( query );

pstmt.setString( 1, custname);

ResultSet results = pstmt.executeQuery( );

示例：Mybatis

2.应避免外部输入未经过滤直接拼接到SQL语句中，或者通过Mybatis中的传入语句（即使使用，语句直接拼接外部输入也同样有风险。例如中部分参数通过{}传入SQL语句后实际执行时调用的是PreparedStatement.execute()，同样存在注入风险）。

3.对于表名、列名等无法进行预编译的场景，比如外部数据拼接到order by, group by语句中，需通过白名单的形式对数据进行校验，例如判断传入列名是否存在、升降序仅允许输入“ASC”和“DESC”、表名列名仅允许输入字符、数字、下划线等。

参考示例：

public String someMethod(boolean sortOrder){

 String SQLquery = "some SQL ...order by Salary " + (sortOrder ? "ASC" : "DESC");`

 ...

4.Web应用程序接入数据库服务器使用的用户禁用系统管理员，用户角色应遵循最小权限原则。

5.定期审计数据库执行日志，查看是否存在应用程序正常逻辑之外的SQL语句执行痕迹。

【特别注意】：

Order By 注入修复方案

开发者在编写系统框架时无法使用预编译的办法处理这类参数，只要对输入的值进行白名单比对，基本上就能防御这种注入。

1.通过正则表达式进行字符串过滤，只允许字段中出现字母、数字、下划线。

2.通过白名单思路，使用间接对象引用。前端传递引用数字或者字符串等，用于与后端做数组映射，这样可以隐藏数据库数据字典效果，避免直接引用带来的危害。

编程代码参考：

设置一个枚举或者MAP变量，然后拿用户输入passwd进行比对返回序号，然后拿序号预编译。

int index = map.get("passwd"); //从map获取对应序号

String sql02 = "select * from test01 order by ?";

PreparedStatement preSql02 = conn.prepareStatement(sql02);

preSql02.setInt(1,index);

测试过程

复测过程

复测结果

未修复

漏洞名称

存储（反射/DOM）XSS漏洞

漏洞地址

漏洞等级

高危（中危）

漏洞描述

跨站脚本（Cross-Site Scripting，XSS）是一种网站应用程序的安全漏洞攻击，是代码注入的一种，允许恶意用户将代码注入网页，其他用户在观看网页时会受到影响。这类攻击通常包含HTML和用户端脚本语言。XSS攻击通常是指通过利用网页开发时留下的漏洞，巧妙注入恶意指令代码到网页，使用户加载并执行攻击者恶意制造的网页程序。这些恶意网页程序通常是JavaScript，但实际上可以包括Java、VBScript、ActiveX、Flash或者普通的HTML。攻击成功后，攻击者可能得到更高的权限（如执行一些操作）、私密网页内容、会话和Cookie等内容。

跨站脚本攻击是一种迫使Web站点回显可执行代码的攻击技术，而这些可执行代码由攻击者提供、最终为用户浏览器加载。不同于大多数攻击（一般只涉及攻击者和受害者），XSS涉及到三方，即攻击者、客户端与网站。XSS的攻击目标是为了盗取客户端的Cookie或者其他网站用于识别客户端身份的敏感信息。获取到合法用户的信息后，攻击者甚至可以假冒最终用户与网站进行交互。

XSS 全称 (Cross Site Scripting)跨站脚本攻击， 指攻击者在网页中嵌入客户端脚本(例如 JavaScript), 当用户浏览此网页时，脚本就会在用户的浏览器上执行，从而达到攻击者的目的。比如获取用户的Cookie，导航到恶意网站,携带木马等。

XSS又分为存储型、反射型和DOM型。

存储型跨站脚本攻击漏洞是指攻击者注入的跨站脚本长期性地存储到服务器，当任何用户访问存在跨站脚本的页面时，都会遭到跨站脚本攻击。

反射型跨站脚本攻击漏洞是简单地把用户输入的数据“反射”给浏览器。攻击脚本未存储在服务端，客户端每次访问需要携带攻击脚本才能中招。

DOM型跨站脚本攻击漏洞是客户端脚本（一般是 javascript）处理用户输入时，没有做充分的过滤，并且将用户的输入赋给 DOM 树中 某些对象的属性，比如通过 document.write，window.location 等。这些操作支持执行 javascript,造成用户的输入被执行。

漏洞成因

由于动态网页的Web应用对用户提交请求参数未做充分的检查过滤，允许用户在提交的数据中掺入HTML代码（最主要的是“>”、“<”），然后未加编码地输出到第三方用户的浏览器，这些攻击者恶意提交代码会被受害用户的浏览器解释执行。由于动态网页的Web应用对用户提交请求参数未做充分的检查过滤，允许用户在提交的数据中掺入HTML代码（最主要的是“>”、“<”），然后未加编码地输出到第三方用户的浏览器，这些攻击者恶意提交代码会被受害用户的浏览器解释执行。

漏洞危害

获取用户的Cookie，导航到恶意网站,携带木马等。

修复方案

通用方案：

1.将重要的Cookie标记为 http only，使javascript中的document.cookie语句不能获取到Cookie。

2.输入检查：

在构造白名单的过程中需要保证在不影响用户体验的同时，尽可能杜绝一切不必要的输入内容，只允许用户输入我们期望的数据。 例如：

年龄的textbox中，只允许用户输入数字，而数字之外的字符都过滤掉。

3.输出检查：

对数据进行html encode处理，过滤移除特殊的html标签。

例如：

过滤javascript事件的标签。

例如：

onclick=，onfocus 等等

建议过滤关键字为：

[1] < 左尖括号

[2] > 右尖括号

[3] " 双引号

[4] ' 单引号

[5] \`` 反引号

[6]%百分号

[7](左圆括号

[8])右圆括号

[9];分号

[10]/正斜杠

[11]` 反斜杠

[12] [ 左中括号

[13] ] 右中括号

[14] & 连接符号

[15] # 井号

比如把<编码为<。< span="">

4.其他参考：

富文本过滤库

ruby：             https://github.com/rgrove/sanitize

php：              https://github.com/ezyang/htmlpurifier

javascript：       https://github.com/leizongmin/js-xss

                https://github.com/cure53/DOMPurify

更多：            

https://github.com/search?o=desc&q=xss&ref=searchresults&s=stars&type=Repositories&utf8=%E2%9C%93

PHP

建议采用以下函数进行实体编码或者过滤特殊字符建议采用以下函数进行实体编码或者过滤特殊字符

strip_tags($str, [允许标签])#从字符串中去除 HTML 和 PHP 标记

htmlentities($str)#转义html实体

html_entity_decode($str)#反转义html实体

addcslashes($str,'字符')#给某些字符加上反斜杠

stripcslashes($str)#去掉反斜杠

addslashes ($str )#单引号、双引号、反斜线与 NULL加反斜杠

stripslashes($str)#去掉反斜杠

htmlspecialchars()#特殊字符转换为HTML实体

htmlspecialchars_decode()#将特殊的 HTML 实体转换回普通字符

Java

1.特殊字符替换

public static String html(String content){

   if(content==null)return "";       

   String html = content;

   html = html.replace( "'", "&apos;");

   html = html.replaceAll( "&", "&");

   html = html.replace( "\"", """);  //"

   html = html.replace( "\t", "  ");// 替换跳格

   html = html.replace( " ", " ");// 替换空格

   html = html.replace("<", "<");

   html = html.replaceAll( ">", ">");

   return html;

}

2.apache工具包common-lang中有一个很有用的处理字符串的工具类，其中之一就是StringEscapeUtils,这个工具类是在2.3版本以上加上的去的，利用它能很方便的进行html,xml,java等的转义与反转义

org.apache.commons.lang3包有个StringEscapeUtils

StringEscapeUtils.unescapeHtml4(str);

3.org.springframework.web.util.HtmlUtils 可以实现HTML标签及转义字符之间的转换。

/** HTML转义 **/ 

String s = HtmlUtils.htmlEscape("

hello world

System.out.println(s); 

String s2 = HtmlUtils.htmlUnescape(s); 

System.out.println(s2);。

测试过程

复测过程

复测结果

未修复

漏洞名称

XXE(XML实体注入)漏洞

漏洞地址

漏洞等级

高危

漏洞描述

XML 外部实体注入漏洞也就是我们常说的 XXE 漏洞。XML 作为一种使用较为广泛的数据传输格式，很多应用程序都包含有处理 xml 数据的代码，默认情况下，许多过时的或配置不当的 XML 处理器都会对外部实体进行引用。如果攻击者可以上传 XML 文档或者在 XML 文档中添加恶意内容，通过易受攻击的代码、依赖项或集成，就能够攻击包含缺陷的XML处理器。XXE 漏洞的出现和开发语言无关，只要是应用程序中对 xml 数据做了解析，而这些数据又受用户控制，那么应用程序都可能受到 XXE 攻击。

漏洞成因

漏洞危害

修复方案

测试过程

复测过程

复测结果

未修复

漏洞名称

远程代码执行漏洞

漏洞地址

漏洞等级

超危

漏洞描述

用户通过浏览器注入一些特殊字符提交执行代码，由于服务端没有针对执行函数做过滤，导致攻击者在没有指定绝对路径的情况下就执行代码，可能会允许攻击者通过改变$PATH或程序执行环境的其他方面来执行恶意构造的代码，改变原本的执行意图，从而执行攻击者指定的代码。

漏洞成因

在各类编程语言中，为了方便程序处理，通常会存在各种执行外部程序的函数，当调用函数执行命令且服务端未对执行函数输入结果做过滤时，导致在没有指定绝对路径的情况下就执行命令，攻击者通过注入恶意命令，造成巨大的危害。

在Web应用中有时候程序员为了考虑灵活性、简洁性，会在代码调用eval函数(PHP函数)去处理，比如当应用在调用一些能将字符串转化成代码的函数时，没有考虑用户是否能控制这个字符串，将造成代码执行漏洞。

由于开发人员编写程序时没有针对代码中可执行的特殊函数入口做过滤，导致客户端可以提交恶意构造语句提交，并交由服务端执行。命令注入攻击中WEB服务器没有过滤类似system()，eval()，exec()，assert()，preg replace()+ /e 模式等函数是该漏洞攻击成功的最主要原因。

漏洞危害

攻击者在没有指定绝对路径的情况下就执行代码，可能会允许攻击者通过改变$PATH或程序执行环境的其他方面来执行恶意构造的代码，改变原本的执行意图，从而执行攻击者指定的代码。

修复方案

通用方案

1.使用低权限用户执行应用程序。

2.升级组件到最新版本。

3.配置或代码过滤危险函数，例如eval()、assert()、preg replace()+/e模式等。

PHP

1.对于eval()和assert()函数一定要保证用户不能轻易接触eval()和assert()的参数或者用正则严格判断输入的数据格式。

2.对于字符串一定要使用单引号包裹可控代码，并且插入前进行addslashes。

3.对于preg replace()放弃使用/e修饰符。如果必须要用/e修饰符，请保证第二个参数中，对于正则匹配出的对象，用单引号包裹。

测试过程

复测过程

复测结果

未修复

漏洞名称

远程命令执行漏洞

漏洞地址

漏洞等级

超危

漏洞描述

命令执行通常因为指Web应用在服务器上拼接系统命令而造成的漏洞。

该类漏洞通常出现在调用外部程序完成一些功能的情景下。比如一些Web管理界面的配置主机名/IP/掩码/网关、查看系统信息以及关闭重启等功能，或者一些站点提供如ping、nslookup、提供发送邮件、转换图片等功能都可能出现该类漏洞。

漏洞成因

用户可控点可以使用管道符进行命令拼接

参数点的过滤不严格，或者可以被绕过

相关函数

system()有回显， 输出并返回最后一行shell结果。

passthru()(有回显)，只调用命令，把命令的运行结果原样地直接输出到标准输出设备上。

exec()（回显最后一行-必须echo输出）不输出结果，返回最后一行shell结果，所有结果可以保存到一个返回的数组里面。

shell_exec()（无回显-必须输出）

反引号：``

popen(handle,mode)(无回显，返回指针，需要将结果存到文件中)不会直接返回执行结果，而是返回一个文件指针

proc_open(‘cmd’,‘flag’,‘flag’)（无回显）不会直接返回执行结果，而是返回一个文件指针。

常见注入方式

分号分割

分割

管道符

换行

反引号解析

替换

无回显技

bash反弹shell

DNS带外数据

http带外

无带外时利用 或其他逻辑构造布尔条件

命令执行绕过

Windows:

WINDOWS：用^转义

LINUX：需要用\来转义

echo 3c3f706870206576616c28245f504f53545b6b616e675d293b203f3e|xxd -r -ps > web可写目录加文件完整名字

管道符说明：

|：管道符，将一个程序的输出作为另一个程序的输入

>:输出重定向，将程序的输出流入到某个程序或者文本中

>>：追加输出重定向，将输出的内容追加到一个文件的末尾

其他特殊符号：

Windows平台：

| 直接执行后面的语句 ping 127.0.0.1|whoami

|| 前面出错执行后面的 ，前面为假 ping 2 || whoami

& 前面的语句为假则直接执行后面的,前面可真可假 ping 127.0.0.1&whoami

&& 前面的语句为假则直接出错，后面的也不执行，前面只能为真 ping 127.0.0.1&&whoami。

漏洞危害

继承Web服务器程序的权限，去执行系统命令

继承Web服务器程序的权限，读写文件

反弹shell

写Webshell

控制整个网站

甚至控制整个服务器。

修复方案

从架构和设计的角度来说：

①要用最小权限去运行程序，不要给予程序多余的权限，最好只允许在特定的路径下运行，可以通过明确的路径运行命令;

②尽可能使用库或框架：使用不允许此弱点出现的经过审核的库或框架，或提供更容易避免此弱点的构造。尽可能地使用库调用，而不是调用外部进程来完成所需功能。

③减少被攻击面：对于那些被用于生成待执行命令的数据，尽可能避免其被外部可控的数据污染。

从实现的角度来说：

①虽然使用动态生成的查询字符串，代码或命令将控制和数据混合在一起是有风险的，但有时它可能是不可避免的。正确引用参数并转义这些参数中的任何特殊字符。最保守的方法是转义或过滤所有未通过极其严格的白名单的字符(例如不是字母数字或空格的所有内容)。如果仍然需要一些特殊字符，例如空格，则在转义/过滤步骤之后将每个参数包装在引号中;

②如果只允许运行有限的命令，使用白名单方式过滤。

测试过程

复测过程

复测结果

未修复

漏洞名称

GET请求传输敏感信息漏洞

漏洞地址

漏洞等级

中危

漏洞描述

GET请求中包含敏感信息，如token、ticket、账号、口令、手机号、身份证号等信息。

漏洞成因

在传输token、ticket、账号、口令、手机号、身份证号等参数时使用GET方式进行提交。

漏洞危害

攻击者可能获取到此GET请求中的敏感参数，造成敏感信息泄漏以及在获取到用户认证信息后进行登录等。

修复方案

1.采用POST方法传输敏感数据。

2.敏感字段采用强加密传输，至少应采用md5($pass.$salt)或者md5($salt.$pass)强度加密方式，禁止采用简单MD5加密甚至base64编码或者变形处理。

测试过程

复测过程

复测结果

未修复

漏洞名称

任意文件读取漏洞

漏洞地址

漏洞等级

高危

漏洞描述

攻击者通过Web Server自身的安全问题或不安全的服务器配置可以读取服务器上开发者不允许读取的文件，进而造成诸如非预期读取文件、错误地把代码类文件当作资源文件等情况的发生，读取操作涉及内容包括服务器的各种配置文件、文件形式存储的密钥、服务器信息（包括正在执行的进程信息）、历史命令、网络信息、应用源码及二进制程序等。

漏洞成因

由于一些网站的业务需要,往往需要提供文件读取或下载的一个模块,但如果没有对读取或下载做一个白名单或者限制，可能导致恶意攻击者读取下载一些敏感信息(etc/passwd 等),对服务器做下一步的进攻与威胁。

攻击者通过Web Server自身的安全问题或不安全的服务器配置可以读取服务器上开发者不允许读取的文件，进而造成诸如非预期读取文件、错误地把代码类文件当作资源文件等情况的发生，读取操作涉及内容包括服务器的各种配置文件、文件形式存储的密钥、服务器信息（包括正在执行的进程信息）、历史命令、网络信息、应用源码及二进制程序等。

漏洞危害

通过任意文件下载，可以下载服务器的任意文件，web业务的代码，服务器和系统的具体配置信息，也可以下载数据库的配置信息，以及对内网的信息探测等等。

攻击者通过Web Server自身的安全问题或不安全的服务器配置可以读取服务器上开发者不允许读取的文件，进而造成诸如非预期读取文件、错误地把代码类文件当作资源文件等情况的发生，读取操作涉及内容包括服务器的各种配置文件、文件形式存储的密钥、服务器信息（包括正在执行的进程信息）、历史命令、网络信息、应用源码及二进制程序等。

修复方案

1.php.ini 配置 open_basedir（针对PHP应用程序）。

2.用户输入配置白名单，对文件下载类型进行检查，判断是否为允许下载类型。

3.过滤路径回溯符../，或者直接将..替换成空。对参数进行过滤，依次过滤“.”、“..”、“/”、“\”等字符。

4.对于下载文件的目录做好限制，只能下载指定目录下的文件，或者将要下载的资源文件路径存入数据库，附件下载时指定数据库中的id即可，id即对应的资源。

测试过程

复测过程

复测结果

未修复

漏洞名称

任意文件上传漏洞

漏洞地址

漏洞等级

高危

漏洞描述

上传文件的时候，如果服务器端脚本语言，未对上传的文件进行严格的验证和过滤，就有可能上传恶意的脚本文件，从而控制整个网站，甚至是服务器上传文件的时候，如果服务器端脚本语言，未对上传的文件进行严格的验证和过滤，就有可能上传恶意的脚本文件，从而控制整个网站，甚至是服务器。

漏洞成因

在网站运营过程中，不可避免地要对网站的某些页面或者内容进行更新，这个时候需要使用到网站的文件上传功能。如果不对被上传的文件进行限制或者限制被绕过，该功能便有可能会被利用上传可执行文件、脚本到服务器上，进而进一步导致服务器沦陷。

漏洞危害

文件上传在Web业务中很常见，如用户上传头像、编写文章上传图片等。在实现文件上传时，如果后端没有对用户上传的文件做好处理，会导致非常严重的安全问题，如服务器被上传恶意木马或者垃圾文件。如果不对被上传的文件进行限制或者限制被绕过，该功能便有可能会被利用上传可执行文件、脚本到服务器上，进而进一步导致服务器沦陷。

修复方案

1.在服务器后端控制上传文件类型，处理时强制使用随机数改写文件名和文件路径,不要使用用户自定义的文件名和文件路径。

2.在服务器后端建议使用白名单的方法对上传的文件进行过滤，上传的目录不进行解析，只提供下载权限。

3.开源编辑器上传漏洞：若新版编辑器已修复漏洞，请更新编辑器版本。

4.除了以上的方法之外，还可将被上传的文件限制在某一路径下，并在文件上传目录禁止脚本解析。

测试过程

复测过程

复测结果

未修复

漏洞名称

任意密码重置漏洞

漏洞地址

漏洞等级

高危

漏洞描述

密码重置过程中，通过修改数据包中的参数和对应的值，参数名一般可以在其他地方找到，替换隐藏参数即可修改他人的密码等信息。

漏洞成因

密码重置过程中未对数据包中参数和对应的值进行校验。

漏洞危害

任意密码重置。

修复方案

1.用户操作个人信息（读取、修改）时，服务端要对当前用户身份进行验证，防止越权操作；

2.用来标识用户身份的手机号、用户名或 ID 可以使用自定义加密，也可以隐藏这些参数，直接从Cookie 中获取用户信息；

3.用户修改密码时应该先对旧密码进行验证，或者使用手机短信验证；

4.用户修改手机号时需要先对原手机号进行验证。

测试过程

复测过程

复测结果

未修复

漏洞名称

任意用户注册漏洞

漏洞地址

漏洞等级

中危

漏洞描述

应用系统对图形验证码和短信验证码校验不合理导致任意用户注册漏洞。

漏洞成因

应用系统对图形验证码和短信验证码校验不合理导致任意用户注册漏洞。

漏洞危害

攻击者通过自己手机短信验证码，通过修改注册手机号码，注册他人手机账号，可以通过这个漏洞批量注册新用户，同时导致其他用户无法进行注册。

修复方案

针对图形验证码和短信验证码采用服务器端校验，登录失败一次，验证码变换一次。

测试过程

复测过程

复测结果

未修复

漏洞名称

接口遍历漏洞

漏洞地址

漏洞等级

高危

漏洞描述

通过修改接口的用户id，可以直接遍历到其他用户投稿文件，甚至修改、删除。

漏洞成因

通过修改接口的用户id，可以直接遍历到其他用户投稿文件，甚至修改、删除。

漏洞危害

通过修改接口的用户id，可以直接遍历到其他用户投稿文件，甚至修改、删除。

修复方案

1.用户操作个人信息（读取、修改）时，服务端要对当前用户身份进行验证，防止越权操作；

2.用来标识用户身份的手机号、用户名或 ID 可以使用自定义加密，也可以隐藏这些参数，直接从Cookie 中获取用户信息；

3.用户修改密码时应该先对旧密码进行验证，或者使用手机短信验证；

4.用户修改手机号时需要先对原手机号进行验证。

测试过程

复测过程

复测结果

未修复

漏洞名称

敏感信息泄露漏洞

漏洞地址

漏洞等级

中危

漏洞描述

敏感数据包括但不限于：口令、密钥、证书、会话标识、License、隐私数据(如短消息的内容)、授权凭据、个人数据(如姓名、住址、电话等)等。

在程序文件、配置文件、日志文件、备份文件及数据库中都有可能包含敏感数据。主要分为由版本管理软件导致的泄露, 文件包含导致的泄露和配置错误导致的泄露。

漏洞成因

1.未能从公共内容中删除内部内容。例如，在生产环境中，用户有时可以看到开发人员在加价中的评论。

2.网站及相关技术配置不安全。例如，如果无法禁用调试和诊断功能，有时可能会为攻击者提供有用的工具，帮助他们获取敏感信息。默认配置也会使网站变得脆弱，例如，通过显示过于冗长的错误消息。

3.应用程序的设计和行为缺陷。例如，如果网站在出现不同错误状态时返回不同的响应，这也可以允许攻击者列举敏感数据，例如有效的用户凭据。

4.出于调试目的，许多网站生成自定义错误消息和日志，其中包含有关应用程序行为的大量信息。虽然此信息在开发过程中是有用的，但如果在生产环境中泄露，它对攻击者也非常有用。调试消息有时可能包含用于开发的重要信息，包括：

（1） 可以通过用户输入操作的关键会话变量的值

（2） 后端组件的主机名和凭据

（3） 服务器上的文件和目录名称

（4） 用于加密通过客户端传输的数据的密钥调试信息有时可能记录在单独的文件中。如果攻击者能够访问此文件，它可以作为了解应用程序运行时状态的有用参考。

漏洞危害

1.扫描内网开放服务

2.向内部任意主机的任意端口发送payload来攻击内网服务

3.DOS攻击（请求大文件，始终保持连接Keep-Alive Always）

4.攻击内网的web应用，例如直接SQL注入、XSS攻击等

5.利用file、gopher、dict协议读取本地文件、执行命令等

修复方案

1.后端控制严谨，用*号来隐藏敏感信息展现。

2.密码策略要足够复杂，开启二步验证。

3.服务配置严谨，对测试和生产资源做好访问控制。

4.对员工培训相关安全意识。

具体修复手段：

1.确保参与制作网站的每个人都充分了解哪些信息被认为是敏感的。有时看似无害的信息对攻击者比人们意识到的要有用得多。突出这些危险有助于确保你的组织更安全地处理敏感信息。

2.尽可能多地使用通用错误消息。

3.仔细检查生产环境中是否禁用任何调试或诊断功能

4.确保你充分了解你实施的任何第三方技术的配置设置和安全影响。花时间调查和禁用任何你实际上不需要的功能和设置。

此外：

1.禁止在代码中存储敏感数据：禁止在代码中存储如数据库连接字符串、口令和密钥之类的敏感数据，这样容易导致泄密。用于加密密钥的密钥可以硬编码在代码中。

2.禁止密钥或帐号的口令以明文形式存储在数据库或者文件中：密钥或帐号的口令必须经过加密存储。例外情况，如果Web容器的配置文件中只能以明文方式配置连接数据库的用户名和口令，那么就不用强制遵循该规则，将该配置文件的属性改为只有属主可读写。

3.禁止在cookie中以明文形式存储敏感数据：cookie信息容易被窃取，尽量不要在cookie中存储敏感数据；如果条件限制必须使用cookie存储敏感信息时，必须先对敏感信息加密再存储到cookie。

4.禁止在隐藏域中存放明文形式的敏感数据。

5.禁止用自己开发的加密算法，必须使用公开、安全的标准加密算法。

6.禁止在日志中记录明文的敏感数据：禁止在日志中记录明文的敏感数据(如口令、会话标识jsessionid等)，防止敏感信息泄漏。

7.禁止带有敏感数据的Web页面缓存：带有敏感数据的Web页面都应该禁止缓存，以防止敏感信息泄漏或通过代理服务器上网的用户数据互窜问题。

8.应根据业务特点定义出系统存储的敏感信息。

9.敏感信息在存储、传输、显示时应进行安全处理，可采用的处理方式为加密或脱敏。

10.敏感信息不应使用GET方式提交到服务器。

11.用户密码为最高级别的敏感信息，在存储、传输、显示时都必须加密。

12.需要选择可靠的加密算法，优先选择不对称加密算法，不得使用BASE64等编码方式进行“加密” 。

13.对于一些系统默认报错页面应重新进行设计自定义报错页面，以免暴露系统敏感信息。

测试过程

复测过程

复测结果

未修复

漏洞名称

文件解析漏洞

漏洞地址

漏洞等级

中危

漏洞描述

文件上传漏洞通常与Web容器的解析漏洞配合利用，常见Web容器有IIS、Nginx、Apache、Tomcat等。

漏洞成因

IIS5.x-6.x

IIS 6中存在两个解析漏洞：“*.asp”文件夹下的所有文件会被当做脚本文件进行解析，文件名为“yu.asp；a.jpg”的文件会被解析为ASP文件，上传“x.asp，a.jpg”文件获取到的后缀为jpg，能够通过白名单的校验。

使用iis5.x-6.x版本的服务器，大多为windows server 2003，网站比较古老，开发语言一般为asp；该解析漏洞也只能解析asp文件，而不能解析aspx文件。

1.当建立*.asp、*.asa格式的文件夹时，其目录下任意文件都会被iis当作asp文件来解析。

2.当文件为*.asp;1.jpg时，IIS6.0同样会以ASP脚本来执行。

目录解析(6.0)

形式：www.xxx.com/xx.asp/xx.jpg

原理: 服务器默认会把.asp，.cer，.asa，.cdx目录下的文件都解析成asp文件。

文件解析

形式：www.xxx.com/xx.asp;.jpg

原理：服务器默认不解析;号后面的内容，因此xx.asp;.jpg便被解析成asp文件了。

解析文件类型

IIS6.0 默认的可执行文件除了asp还包含这三种 :

    /test.asa

    /test.cer

    /test.cdx

Apache

Apache 解析文件的规则是从右到左开始判断解析,如果后缀名为不可识别文件解析,就再往左判断。比如 test.php.owf.rar “.owf”和“.rar” 这两种后缀是apache不可识别解析,apache就会把xxxx.php.owf.rar解析成php。

在Apache 1.x和Apache 2.x中存在解析漏洞。

Apache在解析文件时有一个原则，当碰到不认识的扩展名时，将会从后向前解析，直到碰到认识的扩展名为止，如果都不认识，则会暴露其源代码。

如：1.php.rar.sa.xs就会被解析为php，可以据此来绕过文件名限制

可以在Apache安装目录下的文件“/conf/mime.types”中配置Apache可以识别的文件名。

Nginx

Nginx的解析漏洞为配置不当造成的问题，在Nginx未配置try_files且FPM未设置security.limit_extensions的场景下，可能出现解析漏洞。

先上传x.jpg文件，再访问x.jpg/1.php，location为.php结尾，会交给FPM处理，此时$fastcgi_script_name的值为x.jpg/1.php；在PHP开启cgi.fix_pathinfo配置时，x.jpg/1.php文件不存在，开始fallback去掉最右边的“/”及后续内容，继续判断x.jpg是否存在；这时若x.jpg存在，则会用PHP处理该文件，如果FPM没有配置security.limit_extensions限制执行文件后缀必须为php，则会产生解析漏洞。

Nginx默认是以CGI的方式支持PHP解析的，普遍的做法是在Nginx配置文件中通过正则匹配设置SCRIPT_FILENAME。当访问www.xx.com/phpinfo.jpg/1.php这个URL时，$fastcgi_script_name会被设置为“phpinfo.jpg/1.php”，然后构造成SCRIPT_FILENAME传递给PHP CGI，但是PHP为什么会接受这样的参数，并将phpinfo.jpg作为PHP文件解析呢?这就要说到fix_pathinfo这个选项了。 如果开启了这个选项，那么就会触发在PHP中的如下逻辑：

PHP会认为SCRIPT_FILENAME是phpinfo.jpg，而1.php是PATH_INFO，所以就会将phpinfo.jpg作为PHP文件来解析了。

对低版本的Nginx可以在任意文件名后添加%00.php进行解析攻击

如：上传图片xx.jpg，然后通过改名为xx.jpg%00.php就会解析为php。

IIS7.5

IIS7.5的漏洞与nginx的类似，都是由于php配置文件中，开启了cgi.fix_pathinfo，而这并不是nginx或者iis7.5本身的漏洞。

当php的配置文件中的选项cgi.fix_pathinfo = 1开启时，当访问http://www.xxx.com/x.txt/x.php

时，若x.php不存在，则PHP会递归向前解析，将x.txt当作php脚本来解析。

IIS中：任意文件名/任意文件名.php就会被解析为php

Nginx中：任意文件名/任意文件名.php就会被解析为php。

漏洞危害

文件解析漏洞配合文件上传漏洞、文件包含漏洞利用，攻击者可以通过上传WebShell控制服务器。

修复方案

IIS 5.x-6.x

1.目前尚无微软官方的补丁，可以通过自己编写正则，阻止上传xx.asp;.jpg类型的文件名

2.做好权限设置，限制用户创建文件夹

Apache

1.apache配置文件，禁止.php.这样的文件执行，配置文件里面加入：

    <files </files~ ".(php.|php3.)">

       Order Allow,Deny

       Deny from all

2.用伪静态能解决这个问题，重写类似.php.*这类文件，打开apache的httpd.conf找到LoadModule rewrite_module modules/mod_rewrite.so

  把#号去掉，重启apache,在网站根目录下建立.htaccess文件,代码如下:

    <ifmodule </ifmodulemod_rewrite.c>

       RewriteEngine On

       RewriteRule .(php.|php3.)/index.php

       RewriteRule .(pHp.|pHp3.)/index.php

       RewriteRule .(phP.|phP3.)/index.php

       RewriteRule .(Php.|Php3.)/index.php

       RewriteRule .(PHp.|PHp3.)/index.php

       RewriteRule .(PhP.|PhP3.)/index.php

       RewriteRule .(pHP.|pHP3.)/index.php

       RewriteRule .(PHP.|PHP3.)/index.php

Nginx

1.修改php.ini文件，将cgi.fix_pathinfo的值设置为0，然后重启php-cgi。此修改会影响到使用PATH_INFO伪静态的应用。

2.在Nginx配置文件中添加以下代码：

    if ( $fastcgi_script_name ~\..*\/.*php ){

    return 403;

    }

这行代码的意思是当匹配到类似test.jpg/a.php的URL时，将返回403错误代码。

或

    location ~* .*\.php($|/)

    {

       if ($request_filename ~* (.*)\.php){

          set $php_url $1;

       }

       if (!-e $php_url.php){

                return 403;

       }

       fastcgi_pass  127.0.0.1:9000;

       fastcgi_index index.php;

       include fcgi.conf;

    }

3.对于存储图片的location{...}，或虚拟主机server{...}，只允许纯静态访问，不配置PHP访问。

IIS 7&7.5

1.配置cgi.pathinfo(php.ini中)为0并重启php-cgi程序。

2.在“Handler Mapping”勾选php-cgi.exe程序的“Invoke handler only if request is mapped to”。

3.重新配置iis，使用ISAPI的方式(注意：PHP5.3.1已经不支持ISAPI方式)。

测试过程

复测过程

复测结果

未修复

漏洞名称

HTTP.sys 远程代码执行漏洞

漏洞地址

漏洞等级

高危

漏洞描述

HTTP 协议堆栈 (HTTP.sys)中存在一个远程代码执行漏洞，当 HTTP.sys 错误地解析特制 HTTP 请求时，会导致该漏洞。成功利用此漏洞的攻击者可以在系统帐户的上下文中执行任意代码。

对于 Windows 7、Windows Server 2008 R2、Windows 8、Windows Server 2012、Windows 8.1 和Windows Server 2012 R2 的所有受支持版本，此安全更新的等级为“高危”。

漏洞成因

HTTP 协议堆栈 (HTTP.sys)中存在一个远程代码执行漏洞，当 HTTP.sys 错误地解析特制 HTTP 请求时，会导致该漏洞。成功利用此漏洞的攻击者可以在系统帐户的上下文中执行任意代码。

漏洞危害

攻击者可以通过向受影响的系统发送特制 HTTP 请求，在系统帐户的上下文中执行任意代码。

修复方案

微软官方已提供此问题的安全更新。建议尽快应用此更新。

测试过程

复测过程

复测结果

未修复

漏洞名称

Apache Shiro 反序列化命令执行漏洞

漏洞地址

漏洞等级

超危

漏洞描述

Apache Shiro 是一款开源Java安全框架，提供身份验证、授权、密码学和会话管理。Shiro 框架直观、易用，同时也能提供健壮的安全性。

Apache Shiro 1.2.4 及以前版本中，加密的用户信息序列化后存储在名为 remember-me 的 Cookie 中。只要rememberMe的AES加密密钥泄露，无论shiro是什么版本都会导致反序列化漏洞。攻击者可以使用 Shiro 的默认密钥伪造用户 Cookie，触发 Java 反序列化漏洞，进而在目标机器上执行任意命令。

漏洞成因

Apache Shiro框架提供了记住我（RememberMe）的功能，关闭了浏览器下次再打开时还是能记住你是谁，下次访问时无需再登录即可访问。

Shiro对rememberMe的cookie做了加密处理，shiro在CookieRememberMeManaer类中将cookie中rememberMe字段内容分别进行序列化、AES加密、Base64编码操作。

在识别身份的时候，需要对Cookie里的rememberMe字段解密。根据加密的顺序，不难知道解密的顺序为：

1.获取rememberMe cookie

2.base64 decode

3.解密AES（加密密钥硬编码）

4.反序列化（未作过滤处理）

但是，AES加密的密钥Key被硬编码在代码里，意味着每个人通过源代码都能拿到AES加密的密钥。因此，攻击者构造一个恶意的对象，并且对其序列化，AES加密，base64编码后，作为cookie的rememberMe字段发送。Shiro将rememberMe进行解密并且反序列化，最终造成反序列化漏洞。

漏洞危害

影响Shiro <= 1.2.4版本，当未设置用于“remember me”特性的AES密钥时，存在反序列化漏洞，可远程命令执行。

修复方案

1.升级Shiro版本到1.2.5及以上，建议直接升级到最新版本。

2.现在使用的rememberMe的AES加密密钥泄露，请自己base64一个AES的密钥，或者利用官方提供的方法生成密钥。

org.apache.shiro.crypto.AbstractSymmetricCipherService #generateNewKey()。

测试过程

复测过程

复测结果

未修复

漏洞名称

WebLogic 反序列化命令执行漏洞

漏洞地址

漏洞等级

超危

漏洞描述

由于在处理反序列化信息时没有合理进行过滤，攻击者可以通过发送精心构造的恶意HTTP请求来利用该漏洞，从而获取服务器权限并在未授权情况下远程执行任意代码。

漏洞成因

由于在处理反序列化信息时没有合理进行过滤，攻击者可以通过发送精心构造的恶意HTTP请求来利用该漏洞，从而获取服务器权限并在未授权情况下远程执行任意代码。

漏洞危害

攻击者利用该漏洞可以访问成功登录应用系统后台，导致敏感信息泄露，甚至可以获取管理员权限。

修复方案

1.Oracle目前已发布补丁修复了上述漏洞，请用户参考官方通告及时下载受影响产品更新补丁，并参照补丁安装包中的readme文件进行安装更新，以保证长期有效的防护。

注：Oracle官方补丁需要用户持有正版软件的许可账号，使用该账号登录https://support.oracle.com后，可以下载最新补丁。

2.临时缓解措施

如果用户暂时无法安装更新补丁，可通过下列措施对漏洞（CVE-2020-14841），(CVE-2020-14825)与(CVE-2020-14859)进行临时防护：

2.1 限制T3协议访问

用户可通过控制T3协议的访问来临时阻断针对利用T3协议漏洞的攻击。Weblogic Server 提供了名为 weblogic.security.net.ConnectionFilterImpl 的默认连接筛选器，此连接筛选器接受所有传入连接，可通过此连接筛选器配置规则，对T3及T3s协议进行访问控制，详细操作步骤如下：

(1).进入Weblogic控制台，在base_domain的配置页面中，进入“安全”选项卡页面，点击“筛选器”，进入连接筛选器配置。

(2).在连接筛选器中输入：weblogic.security.net.ConnectionFilterImpl，参考以下写法，在连接筛选器规则中配置符合企业实际情况的规则：

127.0.0.1 * * allow t3 t3s

本机IP ** allow t3 t3s

允许访问的IP  * * allow t3 t3s

* * * deny t3 t3s

连接筛选器规则格式如下：target localAddress localPort action protocols，其中：

target 指定一个或多个要筛选的服务器。

localAddress 可定义服务器的主机地址。(如果指定为一个星号 (*)，则返回的匹配结果将是所有本地 IP 地址。)

localPort 定义服务器正在监听的端口。(如果指定了星号，则匹配返回的结果将是服务器上所有可用的端口)。

action 指定要执行的操作。(值必须为“allow”或“deny”。)

protocols 是要进行匹配的协议名列表。(必须指定下列其中一个协议：http、https、t3、t3s、giop、giops、dcom 或 ftp。)如果未定义协议，则所有协议都将与一个规则匹配。

(3).保存后若规则未生效，建议重新启动Weblogic服务（重启Weblogic服务会导致业务中断，建议相关人员评估风险后，再进行操作）。以Windows环境为例，重启服务的步骤如下：

进入域所在目录下的bin目录，在Windows系统中运行stopWebLogic.cmd文件终止weblogic服务，Linux系统中则运行stopWebLogic.sh文件。

待终止脚本执行完成后，再运行startWebLogic.cmd或startWebLogic.sh文件启动Weblogic，即可完成Weblogic服务重启。

若参考上述操作配置了连接筛选器后，导致Weblogic无法启动，可参考“附录A Weblogic服务恢复”章节，及时进行业务恢复。

2.2 禁用IIOP协议

用户可通过关闭IIOP协议阻断针对利用IIOP协议漏洞的攻击，操作如下：

在Weblogic控制台中，选择“服务”->”AdminServer”->”协议”，取消“启用IIOP”的勾选。并重启Weblogic项目，使配置生效。

测试过程

复测过程

复测结果

未修复

漏洞名称

Fastjson 反序列化命令执行漏洞

漏洞地址

漏洞等级

超危

漏洞描述

fastjson已使用黑白名单用于防御反序列化漏洞，经研究该利用在特定条件下版本号 ≤1.2.80 可绕过默认autoType关闭限制，攻击远程服务器，风险影响较大。建议fastjson用户尽快采取安全措施保障系统安全。

漏洞成因

fastjson已使用黑白名单用于防御反序列化漏洞，经研究该利用在特定条件下版本号 ≤1.2.80 可绕过默认autoType关闭限制，攻击远程服务器，风险影响较大。建议fastjson用户尽快采取安全措施保障系统安全。

漏洞危害

fastjson已使用黑白名单用于防御反序列化漏洞，经研究该利用在特定条件下版本号 ≤1.2.80 可绕过默认autoType关闭限制，攻击远程服务器，风险影响较大。建议fastjson用户尽快采取安全措施保障系统安全。

修复方案

1.升级到最新版本1.2.83

https://github.com/alibaba/fastjson/releases/tag/1.2.83

2.safeMode加固

fastjson在1.2.68及之后的版本中引入了safeMode，配置safeMode后，无论白名单和黑名单，都不支持autoType，可杜绝反序列化Gadgets类变种攻击（关闭autoType注意评估对业务的影响）。

开启方法

参考 https://github.com/alibaba/fastjson/wiki/fastjson_safemode

使用1.2.83之后的版本是否需要使用safeMode

1.2.83修复了此次发现的漏洞，开启safeMode是完全关闭autoType功能，避免类似问题再次发生，这可能会有兼容问题，请充分评估对业务影响后开启。

开启了safeMode是否需要升级

开启safeMode不受本次漏洞影响，可以不做升级。

3.升级到fastjson v2

fastjson v2地址 https://github.com/alibaba/fastjson2/releases

fastjson已经开源2.0版本，在2.0版本中，不再为了兼容提供白名单，提升了安全性。fastjson v2代码已经重写，性能有了很大提升，不完全兼容1.x，升级需要做认真的兼容测试。

4.noneautotype版本

在5月26日后，为了方便使用老版本用户兼容安全加固需求，提供了noneautotype版本，效果和1.2.68的safeMode效果一样，完全禁止autotype功能。使用noneautotype版本的用户也不受此次漏洞影响。

https://repo1.maven.org/maven2/com/alibaba/fastjson/1.2.8_noneautotype/

https://repo1.maven.org/maven2/com/alibaba/fastjson/1.2.48_noneautotype/

https://repo1.maven.org/maven2/com/alibaba/fastjson/1.2.50_noneautotype/

https://repo1.maven.org/maven2/com/alibaba/fastjson/1.2.54_noneautotype/

https://repo1.maven.org/maven2/com/alibaba/fastjson/1.2.60_noneautotype/

https://repo1.maven.org/maven2/com/alibaba/fastjson/1.2.71_noneautotype/。

测试过程

复测过程

复测结果

未修复

漏洞名称

未授权访问漏洞

漏洞地址

漏洞等级

高危

漏洞描述

未授权访问指 Web 站点准许攻击者访问敏感内容或功能而未对其访问许可权进行适当认证。认证鉴权机制存在缺陷，未经授权的用户绕过认证鉴权，从而访问非授权的资源。

漏洞成因

认证鉴权机制存在缺陷，未经授权的用户绕过认证鉴权，从而访问非授权的资源。

漏洞危害

认证鉴权机制存在缺陷，未经授权的用户绕过认证鉴权，从而访问非授权的资源。

修复方案

1.使用安全配置，对敏感服务接口使用白名单访问控制列表。

2.验证一切来自客户端的参数，重点是和权限相关的参数，比如用户ID或者角色权限ID等。

3.session ID 和认证的token做绑定，放在服务器的会话里，不发送给客户端。

4.对于用户登录后涉及用户唯一信息的请求，每次都要验证检查所有权，敏感信息页面加随机数的参数，防止浏览器缓存内容。

5.把程序分成匿名，授权和管理的区域，通过将角色和数据功能匹配。

6.不使用参数来区分管理员和普通用户。

测试过程

复测过程

复测结果

未修复

漏洞名称

垂直（平行）越权漏洞

漏洞地址

漏洞等级

高危

漏洞描述

越权漏洞又分为垂直越权和平行越权，简单来理解的话，就是普通用户操作的权限，可以经过漏洞而变成管理员的权限，或者是可以操作其它人账号的权限，正常如果访问管理员的一些操作，是需要有安全验证的，而越权导致的就是绕过验证，可以访问管理员的一些敏感信息，一些管理员的操作，导致数据机密的信息泄露。

垂直越权漏洞可以使用低权限的账号来执行高权限账号的操作，比如可以操作管理员的账号功能。

平行越权漏洞是可以操作同一个层次的账号权限之间进行操作，以及访问到一些账号敏感信息，比如可以修改任意账号的资料，包括查看会员的手机号，姓名，充值记录，撤单记录，提现记录，注单记录等等，也可以造成使用平行越权来执行其他用户的功能，比如删除银行卡，修改手机号，密保答案等等。

漏洞成因

一般越权漏洞容易出现在权限页面（需要登录的页面）增、删、改、查的的地方，当用户对权限页面内的信息进行这些操作时，后台需要对当前用户的权限进行校验，看其是否具备操作的权限，从而给出响应，而如果校验的规则过于简单则容易出现越权漏洞。

漏洞危害

普通用户操作的权限，可以经过漏洞而变成管理员的权限，或者是可以操作其它人账号的权限。

修复方案

对于非公共操作，应当校验当前访问账号进行操作权限（常见于CMS）和数据权限校验。

1.验证当前用户的登录态。

2.从可信结构中获取经过校验的当前请求账号的身份信息（如：session），禁止从用户请求参数或Cookie中获取外部传入不可信用户身份直接进行查询。

3.校验当前用户是否具备该操作权限。

4.校验当前用户是否具备所操作数据的权限，避免越权。

5.校验当前操作是否账户是否预期账户。

6.基于资源限定的角色来进行垂直越权控制（如:shiro）

在controller类上增加注解@RequiresPermissions()，表示哪些角色可以访问当前这个资源。

示例: 拥有admin,leader角色权限的可以访问这个接口

@RestController

@RequiresPermissions("admin,leader")

public class AuthTest {

    @GetMapping(value = "/user")

    public String getUser(){

        return "zhang";

}

在controller类方法上增加注解@RequiresPermissions()

示例: 拥有admin,leader角色权限的可以访问这个接口

@RestController

public class AuthTest {

   @RequiresPermissions("admin,leader")

    @GetMapping(value = "/user")

    public String getUser(){

        return "zhang";

}@RestController

public class AuthTest {

   @RequiresPermissions("admin,leader")

    @GetMapping(value = "/user")

    public String getUser(){

        return "zhang";

}

7.基于资源和角色的配置关系进行垂直越权控制

@RestController

public class AuthTest {

    @GetMapping(value = "/user")

    public String getUser(){

        return "zhang";

}

增加拦截器

@Configuration

public class AuthConfig implements WebMvcConfigurer {

@Autowired

private ResourceUrlAuthInterceptor resourceCodeBasedAuthInterceptor;

    @Override

    public void addInterceptors(InterceptorRegistry registry){

        registry.addInterceptor(resourceCodeBasedAuthInterceptor);

    }

}

拦截器越权控制

@Component

public class ResourceUrlAuthInterceptor implements HandlerInterceptor {

    @Override

    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler){

        String requestUrl = request.getRequestURI();

        String requestMethod = request.getMethod();

        checkRolePermission(requestUrl,requestMethod);

        return true;

    }

 /**

     * 校验权限

     * @param requestUrl

     * @param requestMethod

     */

    private void checkRolePermission(String requestUrl,String requestMethod){

        //获取当前用户的resource

        ShiroUser user = ShiroSession.getSessionUser();

        List resourceUrlList = user.getResourceUrlList();

 if (CollectionUtils.isEmpty(resourceUrlList))throw new UnauthorizedException();

        //匹配已有权限

        for (String patten:resourceUrlList.stream().map(ShiroResourceUrl::getRequestUrl).collect(Collectors.toList()))if (UrlPattenUtils.checkUrl(patten, requestUrl))return;

        throw new UnauthorizedException();

    }

    //校验url

    public static boolean checkUrl(String patten, String path){

        PatternMatcher matcher = new AntPathMatcher();

        return matcher.matches(patten, path);

    }

}。

测试过程

复测过程

复测结果

未修复

漏洞名称

Redis未授权访问漏洞

漏洞地址

漏洞等级

高危

漏洞描述

Redis默认情况下，会绑定在0.0.0.0:6379，如果没有进行采用相关的策略，比如添加防火墙规则避免其他非信任来源ip访问等，这样将会将Redis服务暴露到公网上，如果在没有设置密码认证（一般为空）的情况下，会导致任意用户在可以访问目标服务器的情况下未授权访问Redis以及读取Redis的数据。攻击者在未授权访问Redis的情况下，利用Redis自身的提供的config命令，可以进行写文件操作，攻击者可以成功将自己的ssh公钥写入目标服务器的/root/.ssh文件夹的authotrized_keys文件中，进而可以使用对应私钥直接使用ssh服务登录目标服务器。

总结来说，就是以下两点：

1.redis绑定在0.0.0.0:6379，且没有进行添加防火墙规则避免其他非信任来源ip访问等相关安全策略，直接暴露在公网；

2.没有设置密码认证（一般为空），可以免密码远程登录redis服务。

漏洞影响范围包括：

Redis 2.x，3.x，4.x，5.x。

漏洞成因

Redis默认情况下，会绑定在0.0.0.0:6379，如果没有进行采用相关的策略，比如添加防火墙规则避免其他非信任来源ip访问等，这样将会将Redis服务暴露到公网上，如果在没有设置密码认证（一般为空）的情况下，会导致任意用户在可以访问目标服务器的情况下未授权访问Redis以及读取Redis的数据。攻击者在未授权访问Redis的情况下，利用Redis自身的提供的config命令，可以进行写文件操作，攻击者可以成功将自己的ssh公钥写入目标服务器的/root/.ssh文件夹的authotrized_keys文件中，进而可以使用对应私钥直接使用ssh服务登录目标服务器。

总结来说，就是以下两点：

1.redis绑定在0.0.0.0:6379，且没有进行添加防火墙规则避免其他非信任来源ip访问等相关安全策略，直接暴露在公网；

2.没有设置密码认证（一般为空），可以免密码远程登录redis服务。

漏洞危害

1.攻击者无需认证访问到内部数据，可能导致敏感信息泄露，黑客也可以恶意执行flushall来清空所有数据；

2.攻击者可通过EVAL执行lua代码，或通过数据备份功能往磁盘写入后门文件；

3.如果Redis以root身份运行，黑客可以给root账户写入SSH公钥文件，直接通过SSH登录受害服务器。

修复方案

1.禁止使用root权限启动redis服务。

2.设置密码，以提供远程登录，对redis访问启动密码认证。

增加redis访问密码

在redis.conf配置文件中找到requirepass配置项，取消#注释符，在requirepass后面添加设置的密码。设置密码以后发现可以登录，但是无法执行命令了。

2.1 启动redis客户端，并连接服务器：redis-cli -h IP地址 -p 端口号

输出服务器中的所有key：keys *

报错：(error)ERR operation not permitted

使用授权命令进行授权，就不报错了：auth youpassword

2.2 在连接服务器的时候就可以指定登录密码，避免单独输入上面授权命令：redis-cli -h  IP地址 -p 端口号 -a 密码。

2.3 在配置文件redis.conf中配置验证密码以外，也可以在已经启动的redis服务器通过命令行设置密码，但这种方式是临时的，当服务器重启了后，密码必须重设。命令行设置密码方式：config set requirepass 你的密码。

2.4 不知道当前redis服务器是否有设置验证密码，或者忘记密码，可以通过命令行输入命令查看密码：config get requirepass。

2.5 如果redis服务端没有配置密码，会得到nil，而如果配置了密码，但是redis客户端连接redis服务端时，没有用密码登录验证，会提示：operation not permitted,这时候可以用命令：auth yourpassword 进行验证密码，再执行 config set requirepass，就会显示yourpassword。

3.限制登录IP，采用绑定IP的方式来进行控制。添加IP访问限制，并更改默认6379端口。

限制登录IP，采用绑定IP的方式来进行控制。添加IP访问限制，并更改默认6379端口：修改redis.conf文件。

在redis.conf文件找到如下配置

# bind 127.0.0.1

把# bind 127.0.0.1前面的注释#号去掉，然后把127.0.0.1改成允许访问你的redis服务器的ip地址，表示只允许该ip进行访问。这种情况下，我们在启动redis服务器的时候不能再用:redis-server，改为:redis-server path/redis.conf，即在启动的时候指定需要加载的配置文件,其中path是你上面修改的redis配置文件所在目录，这个方法有一点不太好，难免有多台机器访问一个redis服务。即在启动的时候指定需要加载的配置文件,其中path/是你上面修改的redis配置文件所在目录，这个方法有一点不太好，难免有多台机器访问一个redis服务。

4.修改默认端口：修改redis.conf文件

修改默认端口 port 6379(注意：尽量不要和其他服务端口号冲突，改成一些少用或不常见的端口号即可)。

测试过程

复测过程

复测结果

未修复

漏洞名称

Swagger-ui未授权访问漏洞

漏洞地址

漏洞等级

高危

漏洞描述

Swagger是一个规范和完整的框架，用于生成、描述、调用和可视化 RESTful 风格的 Web 服务，JAVA在金融机构开发语言的地位一直居高不下，而作为JAVA届服务端的大一统框架Spring，便将Swagger规范纳入自身的标准，建立了Spring-swagger项目，所以在实际测试环境中，基于spring框架的swagger-ui接口展示及调试文档页面最为常见。

可利用未授权访问漏洞，直接访问以下链接：

/api

/api-docs

/api-docs/swagger.json

/api.html

/api/api-docs

/api/apidocs

/api/doc

/api/swagger

/api/swagger-ui

/api/swagger-ui.html

/api/swagger-ui.html/

/api/swagger-ui.json

/api/swagger.json

/api/swagger/

/api/swagger/ui

/api/swagger/ui/

/api/swaggerui

/api/swaggerui/

/api/v1/

/api/v1/api-docs

/api/v1/apidocs

/api/v1/swagger

/api/v1/swagger-ui

/api/v1/swagger-ui.html

/api/v1/swagger-ui.json

/api/v1/swagger.json

/api/v1/swagger/

/api/v2

/api/v2/api-docs

/api/v2/apidocs

/api/v2/swagger

/api/v2/swagger-ui

/api/v2/swagger-ui.html

/api/v2/swagger-ui.json

/api/v2/swagger.json

/api/v2/swagger/

/api/v3

/apidocs

/apidocs/swagger.json

/doc.html

/docs/

/druid/index.html

/graphql

/libs/swaggerui

/libs/swaggerui/

/spring-security-oauth-resource/swagger-ui.html

/spring-security-rest/api/swagger-ui.html

/sw/swagger-ui.html

/swagger

/swagger-resources

/swagger-resources/configuration/security

/swagger-resources/configuration/security/

/swagger-resources/configuration/ui

/swagger-resources/configuration/ui/

/swagger-ui

/swagger-ui.html

/swagger-ui.html#/api-memory-controller

/swagger-ui.html/

/swagger-ui.json

/swagger-ui/swagger.json

/swagger.json

/swagger.yml

/swagger/

/swagger/index.html

/swagger/static/index.html

/swagger/swagger-ui.html

/swagger/ui/

/Swagger/ui/index

/swagger/ui/index

/swagger/v1/swagger.json

/swagger/v2/swagger.json

/template/swagger-ui.html

/user/swagger-ui.html

/user/swagger-ui.html/

/v1.x/swagger-ui.html

/v1/api-docs

/v1/swagger.json

/v2/api-docs

/v3/api-docs。

漏洞成因

Swagger未开启页面访问限制，Swagger未开启严格的Authorize认证。

漏洞危害

通过翻查文档，得到api接口，点击parameters，即可得到该api接口的详细参数。直接构造参数发包，通过回显可以得到大量的用户信息，包含了手机号，邮箱等。

修复方案

1.Swagger开启页面访问限制。

2.Swagger开启Authorize认证。

找到Startup文件，我们看到Swagger的配置如下：

services.AddSwaggerGen(options =>

   {

      options.SwaggerDoc("v1", new Info { Title = "YjJob API", Version = "v1" });

      options.DocInclusionPredicate((docName, description)=> true);

   });

修改配置：

services.AddSwaggerGen(options =>

   {

      options.SwaggerDoc("v1", new Info { Title = "YjJob API", Version = "v1" });

      options.DocInclusionPredicate((docName, description)=> true);

       options.AddSecurityDefinition("Bearer", new ApiKeyScheme

         {

            Description = "Authorization format : Bearer {token}",

             Name = "Authorization",

             In = "header",

             Type = "apiKey"

          });//api界面新增authorize按钮

       });

修改后我们可以看到生成的Swagger UI界面新增了一个“Authorize”按钮：

点击“Authorize”按钮弹出以下界面

在value文本框中输入"Bearer "+token(登录接口返回的access_token),然后点击“Authorize”按钮，之后再调用需要权限验证的接口就可以正常调用。

测试过程

复测过程

复测结果

未修复

漏洞名称

Druid未授权访问漏洞

漏洞地址

漏洞等级

高危

漏洞描述

Druid是阿里巴巴数据库事业部出品，为监控而生的数据库连接池。Druid提供的监控功能，监控SQL的执行时间、监控Web URI的请求、Session监控。当开发者配置不当时就可能造成未授权访问。

漏洞成因

如果网站无需登录，则可利用未授权访问漏洞，直接访问以下链接：

html:

/druid/index.html          #Druid Index

/druid/sql.html            #Druid sql监控页面

/druid/weburi.html         #Druid Web URI监控页面

/druid/websession.html      #Druid Web Session监控页面

json:

/druid/weburi.json         #Druid Web URI json

/druid/websession.json      #Druid Web Session json

Druid 登录接口：

/druid/login.html         #Druid登录认证页面

其他：

/system/druid/login.html

/webpage/system/druid/login.html

/druid/datasource.html

/druid/wall.html

/druid/webapp.html

/system/druid/websession.html

/webpage/system/druid/websession.html

/druid/spring.html

/druid/api.html。

漏洞危害

通过泄露的Session登录后台。

当/druid/websession.html页面存在数据时，我们可利用该页面的session伪造登录，点击最后访问时间，然后复制一条离现在时间最为接近的session进行伪造登录；之所以要点击最后访问时间排序session，是因为此处记录的Session并非全部都是用户在线时的session，当用户退出系统时，session虽然还存在，但已失效，无法再利用。

修复方案

Druid 开启权限校验。

Druid 的验证方式官网提供了一种根据ip来做访问限制的方式，即allow和deny, 详询 https://github.com/alibaba/druid/wiki/%E9%85%8D%E7%BD%AE_StatViewServlet%E9%85%8D%E7%BD%AE

还有一种方式，即用户名和密码

首先从web.xml中的servlet出发

   DruidStatView

   com.alibaba.druid.support.http.StatViewServlet

综合分析在web.xml中配置servlet的初始化参数loginUsername和loginPassword即可

在访问druid的监控页面，会自动转到login.html

Druid内置提供了一个StatViewServlet用于展示Druid的统计信息。

这个StatViewServlet的用途包括：

提供监控信息展示的html页面

提供监控信息的JSON API

配置web.xml

StatViewServlet是一个标准的javax.servlet.http.HttpServlet，需要配置在你web应用中的WEB-INF/web.xml中。

   DruidStatView

   com.alibaba.druid.support.http.StatViewServlet

   DruidStatView

   /druid/*

根据配置中的url-pattern来访问内置监控页面，如果是上面的配置，内置监控页面的首页是/druid/index.html

配置监控页面访问密码

需要配置Servlet的 loginUsername 和 loginPassword这两个初始参数。

示例如下:

   DruidStatView

   com.alibaba.druid.support.http.StatViewServlet

      resetEnable

      true

      loginUsername

      druid

      loginPassword 

      druid 

   DruidStatView 

   /druid/* 

。

测试过程

复测过程

复测结果

未修复

漏洞名称

Spring Boot Actuator v2未授权访问漏洞

漏洞地址

漏洞等级

高危

漏洞描述

Actuator是Spring Boot提供的服务监控和管理中间件，默认配置会出现接口未授权访问，部分接口会泄露网站流量信息和内存信息等，使用Jolokia库特性甚至可以远程执行任意代码，获取服务器权限。

漏洞成因

Spring Boot Framework包含许多称为执行器的功能，可帮助您在将Web应用程序投入生产时监视和管理Web应用程序。它们旨在用于审计，运行状况和指标收集，它们还可能在配置错误时打开服务器的隐藏门。

当Spring Boot应用程序运行时，它会自动将多个端点（例如'/health'，'/trace'，'/beans'，'/env'等）注册到路由进程中。对于Spring Boot 1 - 1.4，它们无需身份验证即可访问，从而导致严重的安全问题。从Spring 1.5版开始，默认情况下，除“/health”和“/info`”之外的所有端点都被视为敏感和安全，但应用程序开发人员通常会禁用此安全性。

以下Actuator端点可能具有安全隐患，从而导致可能的漏洞：

/auditevents - 显示应用暴露的审计事件 (比如认证进入、订单失败)

/autoconfig - 提供了一份自动配置报告，记录了哪些自动配置条件通过，哪些没通过

/beans - 显示应用程序中所有 Spring bean 的完整列表。

/conditions - 显示自动配置报告，报告中包含所有自动配置候选项以及应用或不应用这些候选项的原因。

/configprops - 显示所有 @ConfigurationProperties 的整理列表。

/dump - 执行线程转储。

/env - 公开 Spring ConfigurableEnvironment 中的属性。

/health - 显示应用程序的运行状况信息（通过未经验证的连接访问时显示简单的状态信息，或通过身份验证时显示完整的消息详细信息）。

/heapdump - 堆存储

/info - 显示任意应用程序信息。

/logfile - 输出日志文件的内容

/loggers - 显示和修改配置的loggers

/mappings - 显示所有 @RequestMapping 路径的整理列表。

/metrics - 显示当前应用程序的指标信息。

/restart - 重新启动应用程序

/shutdown - 允许应用程序正常关机（默认不启用），要求endpoints.shutdown.enabled设置为true

/trace - 显示跟踪信息（默认为上次的一些 HTTP 请求）。

对于Spring 1x，它们在根URL下注册，并且在2x中它们移动到“/actuator/”基本路径。

/actuator

/actuator/auditevents

/actuator/beans

/actuator/conditions

/actuator/configprops

/actuator/env

/actuator/health

/actuator/heapdump

/actuator/httptrace

/actuator/hystrix.stream

/actuator/info

/actuator/jolokia

/actuator/loggers

/actuator/mappings

/actuator/metrics

/actuator/scheduledtasks

/actuator/threaddump

/auditevents

/autoconfig

/beans

/cloudfoundryapplication

/configprops

/dump

/env

/health

/heapdump

/hystrix.stream

/info

/jolokia

/loggers

/mappings

/metrics

/monitor

/monitor/auditevents

/monitor/beans

/monitor/conditions

/monitor/configprops

/monitor/env

/monitor/health

/monitor/heapdump

/monitor/httptrace

/monitor/hystrix.stream

/monitor/info

/monitor/jolokia

/monitor/loggers

/monitor/mappings

/monitor/metrics

/monitor/scheduledtasks

/monitor/threaddump

/threaddump

/tracev。

漏洞危害

1.通过'/jolokia'执行远程代码。

2.通过'/env'获取配置信息和修改配置信息。

3.通过'/trace'获取用户认证字段信息。

4.通过'/health'泄露 git 项目地址。

5.通过'/heapdump'获取后台用户账号密码泄露。

修复方案

1.禁用所有接口，将配置改成：endpoints.enabled=false。

要禁用trace端点，则可设置如下：

endpoints.trace.enabled=false

如果只想打开一两个接口，那就先禁用全部接口，然后启用需要的接口：

endpoints.enabled=false

endpoints.metrics.trace=true

将内置端点trace进行授权配置为true，保证访问内置端点trace是经过授权的。

logging.level.org.springframework=INFO

logging.level.org.springframework.boot.devtools=WARN

logging.level.org.owasp=DEBUG

logging.level.org.owasp.webwolf=TRACE

endpoints.trace.sensitive=true

2.Spring Boot 也提供了安全限制功能。比如spring-boot-starter-security依赖并自定义配置。

引入spring-boot-starter-security依赖：

    org.springframework.boot

    spring-boot-starter-security

3.开启security功能，配置访问权限验证：

management.port=8099

management.security.enabled=true

security.user.name=xxxxx

security.user.password=xxxxxx。

测试过程

复测过程

复测结果

未修复

漏洞名称

金蝶OA Apusic应用服务器(中间件)server_file 任意文件读取漏洞

漏洞地址

漏洞等级

高危

漏洞描述

金蝶OA Apusic应用服务器(中间件)存在任意文件读取漏洞，攻击者通过漏洞可以获取目录下的文件信息。

漏洞成因

由于一些网站的业务需要,往往需要提供文件读取或下载的一个模块,但如果没有对读取或下载做一个白名单或者限制，可能导致恶意攻击者读取下载一些敏感信息(etc/passwd 等),对服务器做下一步的进攻与威胁。

漏洞危害

通过任意文件下载，可以下载服务器的任意文件，web业务的代码，服务器和系统的具体配置信息，也可以下载数据库的配置信息，以及对内网的信息探测等等。

修复方案

1.php.ini 配置 open_basedir（针对PHP应用程序）。

2.用户输入配置白名单，对文件下载类型进行检查，判断是否为允许下载类型。

3.过滤路径回溯符../，或者直接将..替换成空。对参数进行过滤，依次过滤“.”、“..”、“/”、“\”等字符。

4.对于下载文件的目录做好限制，只能下载指定目录下的文件，或者将要下载的资源文件路径存入数据库，附件下载时指定数据库中的id即可，id即对应的资源。

测试过程

/admin/protected/selector/server_file/files?folder=/

复测过程

复测结果

未修复

漏洞名称

SSRF漏洞

漏洞地址

漏洞等级

高危

漏洞描述

SSRF（Server Side Request Forgery，服务端请求伪造）是一种攻击者通过构造数据进而伪造服务器端发起请求的漏洞。因为请求是由内部发起的，所以一般情况下，SSRF漏洞攻击的目标往往是从外网无法访问的内部系统。

SSRF漏洞形成的原因多是服务端提供了从外部服务获取数据的功能，但没有对目标地址、协议等重要参数进行过滤和限制，从而导致攻击者可以自由构造参数，而发起预期外的请求。

漏洞成因

SSRF漏洞形成的原因多是服务端提供了从外部服务获取数据的功能，但没有对目标地址、协议等重要参数进行过滤和限制，从而导致攻击者可以自由构造参数，而发起预期外的请求。

漏洞危害

1.SSRF漏洞可以直接探测网站所在服务器端口的开放情况甚至内网资产情况，如确定该处存在SSRF漏洞，则可以通过确定请求成功与失败的返回信息进行判断服务开放情况。

2.使用Gopher协议攻击Redis、MySQL。

3.PHP-FPM攻击。

4.攻击内网中的脆弱Web应用。

5.自动组装Gopher。

修复方案

1.设置URL白名单或者限制内网IP地址（使用gethostbyname()判断是否为内网IP）。

IPv4地址的内网地址分为三段：

10.0.0.0 ~ 10.255.255.255、172.16.0.0 ~ 172.31.255.255、192.168.0.0 ~ 192.168.255.255。

示例代码：

   private boolean validHost ( String hostname ){

      try {

         InetAddress ip = InetAddress.getByName(hostname);

         if (ip.isSiteLocalAddress()){

            return false;

         }

      } catch (UnknownHostException e){

         return false;

      }

      return !filters.contains( hostname );

   }

2.禁用不需要的协议，仅仅允许http和https请求。可以防止类似于file://, gopher://, ftp:// 等引起的问题。

3.限制请求的端口为http常用的端口，比如 80、443、8080、8090。

4.过滤返回信息，验证远程服务器对请求的响应是比较容易的方法。如果web应用是去获取某一种类型的文件。那么在把返回结果展示给用户之前先验证返回的信息是否符合标准。

5.统一错误信息，避免用户可以根据错误信息来判断远端服务器的端口状态。

6.禁止跳转。

测试过程

复测过程

复测结果

未修复