2023年7月11日发(作者：)

1.1. 针对网站目录路径泄露整改建议

统一错误代码：确保你不小心通过提供不一致或“冲突”的错误消息给攻击者。

信息错误消息：确保错误信息不透露太多的信息。完全或部分路径，变量和文件名，行和表中的列名，和特定的数据库的错误不应该透露给最终用户。

适当的错误处理：利用通用的错误页面和错误处理逻辑，告知潜在的问题的最终用户。不提供系统信息或可能被攻击者利用精心策划的攻击时，其它数据。

1.2. 针对文件上传漏洞整改建议

文件上传功能允许 Web 用户将文件从自己的计算机发送到 Web 服务器。如果用于接收文件的 Web 应用程序未仔细检查此文件是否包含恶意内容，那么攻击者也许能够通过上传文件在服务器上执行任意命令。建议采取严格的文件上传策略，通过清理和筛选避免上传恶意材料。

限制文件上传的类型，检查的文件扩展名，只允许特定的文件上传。用白名单的方式而不是一个黑名单。检查双扩展，如.。检查的文件没有文件 名一样。htaccess（对配置文件，检查网络配置。）。改变对上传文件夹的权限，文件在此文件夹中不可执行。如果可能的话，重命名上传文件。

可能会在 Web 服务器上运行远程命令。这通常意味着完全破坏服务器及其内容

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

在文件上载过程中，限制用户能力和许可权：

[1] 确保上载脚本只能控制上载的文件名和位置。

[2] 不上载脚本文件，如 asp、aspx、php、jsp 等。只允许上载静态内容。

[3] 只允许上载预期的文件类型。例如，如果您预期纯文本文件，便只允许 .txt 扩展名。

[4] 验证上载的文件内容。如果您预期纯文本文件，请确保它不含二进制字符或动态脚本部分。

1.3. 针对文件WEB站点结构泄露漏洞整改建议

可能会检索有关站点文件系统结构的信息，这可能会帮助攻击者映射此 Web 站点。

1、 文件不应用来保护或隐藏信息

2、 您应该将敏感的文件和目录移到另一个隔离的子目录，以便将这个目录排除在 Web Robot 搜索之外。如下列示例所示，将文件移到“folder”之类的非特定目录名称是比较好的解决方案： New directory

structure: /folder/ /folder/sensitive_folder/

New : User-agent: * Disallow: /folder/

3、 如果您无法更改目录结构，且必须将特定目录排除于 Web Robot 之外，在 文件中，请只用局部名称。虽然这不是最好的解决方案，但至少它能加大完整目录名称的猜测难度。例如，如果要排除“sensitive_folder”和 “”，请使用下列名称（假设

Web 根目录中没有起始于相同字符的文件或目录）： :

User-agent: * Disallow: /se Disallow: /pa

1.4. 针对源代码泄露漏洞整改建议

攻击者可以收集敏感信息（数据库连接字符串，应用程序逻辑）的源代码分析。该信息可以被用来进行进一步的攻击。

1、 建议升级最新tomcat中间件。

2、 建议在tomcat的conf/文件里加入大写.JSP映射。即

JSP

*.JSP

1.5. 针对SVN库发现漏洞整改建议

这些文件可以公开敏感信息，有助于一个恶意用户准备更进一步的攻击。

从生产系统中删除这些文件或限制访问.svn目录。拒绝访问所有你需要在适当的范围内添加以下几行svn文件夹（或者全局配置, 或者 vhost/directory,

或者是 .htaccess)。

Order allow,deny

Deny from all

1.6. 针对网络端口未限制漏洞的整改建议

1、 建议明确每个端口对应的服务进程，根据系统和应用的要求，关闭系统中不必要的服务进程

2、 建议明确服务器的对外和对内的服务用途，关闭系统中不必要的服务端口（如139、445等）。

3、 如果需要对外开放其他端口，建议采用IP地址限制（例如：3389端口）。

4、 建议防火墙关闭不需要的端口，只开放对外提供服务的端口（例如：80端口）。

远程攻击者可以根据端口号来判断服务器有哪些应用，并根据相应的应用采取对应攻击，为黑客提供了更多攻击途径与手段。

1.1 针对SQL注入漏洞的整改建议

每个提交信息的客户端页面，通过服务器端脚本（JSP、ASP、ASPX、PHP等脚本）生成的客户端页面，提交的表单（FORM）或发出的连接请求中包含的所有变量，必须对变量的值进行检查。过滤其中包含的特殊字符，或对字符进行转义处理。特殊字符包括：

SQL语句关键词：如 and 、or 、select、declare、update、xp_cmdshell；

SQL语句特殊符号：’、”、;等；

此外，Web应用系统接入数据库服务器使用的用户不应为系统管理员，用户角色应遵循最小权限原则；具体建议如下：

1、 严格定义应用程序可接受的数据类型（例如，字符串、字母数字字符等）。

2、 使用肯定的定义而非否定的定义。验证输入中是否存在不正确的字符。采用这样一种基本原理：使用肯定的定义而非否定的定义。有关详细信息，请参阅下面的代码示例。

3、 不要向最终用户显示提供的信息（如表名）可用于策划攻击的错误消息。

4、 定义受允许的字符集。例如，如果某个字段要接受数字，请使该字段仅接受数字。

5、 定义应用程序接受的最大和最小数据长度。

6、 指定输入可接受的数字范围。

1.7. 针对跨站脚本漏洞整改建议

每个提交信息的客户端页面，通过服务器端脚本（JSP、ASP、ASPX、PHP等脚本）生成的客户端页面，提交的表单（FORM）或发出的连接请求中包含的所有变量，必须对变量的值进行检查。过滤其中包含的特殊字符，或对字符进行转义处理。特殊字符包括：

HTML标签的<符号、“符号、’符号、%符号等，以及这些符号的Unicode值；

客户端脚本（Javascript、VBScript）关键字：javascript、script等；

此外，对于信息搜索功能，不应在搜索结果页面中回显搜索内容。同时应设置出错页面，防止Web服务器发生内部错误时，错误信息返回给客户端。 1.8. 针对Fckeditor编辑器漏洞整改建议

1、 删除FCKeditor测试页面。

2、 升级最新版FCKeditor编辑器

1.9. 针对任意文件下载漏洞整改建议

1、 禁止用文件名的方式访问网站目录的文件。

2、 访问的文件名必须限制在规定的目录内，禁止越权使用别的目录

1.10. URL跳转漏洞

漏洞类型： URL跳转漏洞

详细说明：Web应用程序接收到用户提交的URL参数后，没有对参数做“可信任URL”的验证，就向用户浏览器返回跳转到该URL的指令。黑客可以通过URL跳转漏洞进行钓鱼窃取账号

修复方案：

保证用户所点击的URL，是从web应用程序中生成的URL，所以要做TOKEN验证。

1.11. 检测到应用程序测试脚本

可能会下载临时脚本文件，这会泄露应用程序逻辑及其他诸如用户名和密码之类的敏感信息

不可将测试/暂时脚本遗留在服务器上，未来要避免出现这个情况。

确保服务器上没有非正常操作所必备的其他脚本。

1.12. Apache – TraceEnable

可能会窃取或操纵客户会话和 cookie，它们可能用于模仿合法用户，从而使黑客能够以该用户身份查看或变更用户记录以及执行事务

譯者：Nica < nicaliu at gmail dot com >

【Nica 註：這是 檔裡的設定指令!~】 Description: Determines the behaviour on TRACE requests

Syntax: TraceEnable [on|off|extended]

Default: TraceEnable on

Context: server config

Status: Core

Module: core

Compatibility: Available in Apache 1.3.34, 2.0.55 and later

Traditionally experts will suggest to disable this using some rewrite

rules like:

RewriteEngine On

RewriteCond %{REQUEST_METHOD} ^TRACE

RewriteRule .* - [F]

(this needs to be added somewhere in your main apache config file outside

of any vhost or directory config).

Still this has the disadvantage that you need to have

mod_rewrite enabled

on the server just to mention one. But for apache versions newer than

1.3.34 for the legacy branch, and 2.0.55 (or newer) for apache2 this can

be done very easily because there is a new apache variable that controls

if TRACE method is enabled or not:

TraceEnable off

解决方案: 禁用这些方式。

1、在各虚拟主机的配置文件里添加如下语句:

在里解除

LoadModule rewrite_module modules/mod_的注释

再增加

RewriteEngine on

RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK)

RewriteRule .* - [F]

2、Available in Apache 1.3.34, 2.0.55 and later

TraceEnable off

1.13. tomcat下禁止不安全的http方法

如何禁止DELETE、PUT、OPTIONS、TRACE、HEAD等协议访问应用程序

WebDAV （Web-based Distributed Authoring and Versioning）是基于 HTTP

1.1 的一个通信协议。它为 HTTP 1.1 添加了一些扩展（就是在 GET、POST、HEAD

等几个 HTTP 标准方法以外添加了一些新的方法），使得应用程序可以直接将文件写到 Web Server 上，并且在写文件时候可以对文件加锁，写完后对文件解锁，还可以支持对文件所做的版本控制。这个协议的出现极大地增加了 Web 作为一种创作媒体对于我们的价值。基于 WebDAV 可以实现一个功能强大的内容管理系统或者配置管理系统。

现在主流的WEB服务器一般都支持WebDAV，使用WebDAV的方便性，呵呵，就不用多说了吧，用过开发应用的朋友就应该 知道，新建/修改WEB项目，其实就是通过WebDAV+FrontPage扩展做到的，下面我就较详细的介绍一下，WebDAV在tomcat中的配 置。

如何禁止DELETE、PUT、OPTIONS、TRACE、HEAD等协议访问应用程序应用程序呢？

解决方法

第一步：修改应用程序的文件的协议

Xml代码

1.

2.

3.

4.

5.

xmlns:xsi="/2001/XMLSchema-instance"

xsi:schemaLocation="/xml/ns/j2ee/web-app_2_"

version="2.4">

第二步：在应用程序的中添加如下的代码即可

Xml代码

1.

2.

3.

4.

5.

6.

7.

8.

9.

/*

PUT

DELETE

HEAD

OPTIONS

TRACE

10.

11.

12.

13.

14. BASIC

15.

重新部署程序，重启tomcat即可完成

如果用户要验证既可以将POST和GET也添加在其中，重新部署并启动tomcat即可看到效果

以上的代码添加到某一个应用中，也可以添加到tomcat的中，区别是添加到某一个应用只对某一个应用有效如果添加到tomcat的中，则对tomcat下所有的应用有效。

(转)启用了不安全的HTTP方法

2013-04-26 15:28:56| 分类： spring mvc |字号 订阅

原文地址：/blog/static//

安全风险：

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

可能原因：

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

修订建议：

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

方法简介：

除标准的GET和POST方法外，HTTP请求还使用其他各种方法。许多这类方法主要用于完成不常见与特殊的任务。如果低权限用户可以访问这些方法，他们就能够以此向应用程序实施有效攻击。以下是一些值得注意的方法：

PUT

COPY

MOVE

向指定的目录上载文件

将指定的资源复制到Destination消息头指定的位置

将指定的资源移动到Destination消息头指定的位置

DELETE

删除指定的资源

SEARCH

在一个目录路径中搜索资源

PROPFIND

获取与指定资源有关的信息，如作者、大小与内容类型

TRACE

在响应中返回服务器收到的原始请求

其中几个方法属于HTTP协议的WebDAV（Web-based Distributed Authoring and Versioning）扩展。

渗透测试步骤：

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

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

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

使用curl测试：

curl -v -X OPTIONS /test/

查看响应的 Allow: GET, HEAD, POST, PUT, DELETE, OPTIONS

curl -v -T /test/

看是否能上载来判断攻击是否生效。

找一个存在的页面，如

curl -X DELETE /test/

如果删除成功，则攻击有效。

解决方案：

如tomcat，配置

fortune

/*

PUT

DELETE

HEAD

OPTIONS

TRACE

BASIC

重启tomcat即可完成。

以上的代码添加到某一个应用中，也可以添加到tomcat的中，区别是添加到某一个应用只对某一个应用有效，如果添加到tomcat的中，则对tomcat下所有的应用有效。

1.14. 针对启用了Microsoft Debugging整改建议

对所有易受攻击的目录禁用调试。要禁用调试，请如下所述编辑 文件：

<>

可能会收集有关 Web 应用程序的敏感信息，如用户名、密码、机器名和/或敏感文件位置

1.15. 针对Apache（tomcat）默认示例页面漏洞整改建议

将 Web 服务器配置成拒绝列出目录。

根据 Web 服务器或 Web 应用程序上现有的问题来下载特定安全补丁。部分已知的目录列表问题列在这个咨询的“引用”字段中。

可能会查看和下载特定 Web 应用程序虚拟目录的内容，其中可能包含受限文件

1.16. 针对直接访问管理页面漏洞的整改建议

可能会升级用户特权并通过 Web 应用程序获取管理许可权

不具备适当的授权，便禁止访问管理脚本，因为攻击者可能会因而获取特许权利。

漏洞描述

在测试的过程中发现应用系统的管理后台地址存在泄漏的风险，应用系统的管理后台地址过于简单攻击者可以轻易的猜解到进行更一步的攻击。

应用系统管理后台地址太简单，导致攻击者可以轻易猜测到应用系统的管理漏洞危害 后台地址，进而通过fuzzer等技术破解后台密码或通过其他技术攻击应用系统。

安全建议

为应用程序管理后台配置一个复杂的地址，防止非法访问者得到管理后台访问权。 1.17. 针对Apache、PHP版本低漏洞的整改建议

1、

将您的 Apache Web 服务器升级到最新的可能版本。您可以下载补丁，链接位置如下： /dist/httpd/

2、

将您的PHP服务器升级到最新的可能版本。您可以下载补丁，链接位置如下：/

恶意攻击者可以利用各种版本漏洞进行攻击，会导致服务器拒绝服务影响服务器的正常运行。

1.18. 针对PHPinfo信息泄露漏洞的整改建议

禁止在代码中使用phpinfo()函数。

1.19. 针对URL重定向漏洞的整改建议

保证用户所点击的URL，是从web应用程序中生成的URL，所以要做正确过滤用户输入。

1.20. 针对Flash 参数 AllowScriptAccess 已设置为

always漏洞整改建议

请将 AllowScriptAccess 参数设为“sameDomain”，告诉 Flash 播放器，只有从父 SWF 的相同域中装入的 SWF 文件有对托管 Web 页面的脚本访问权。

1.21. 主机允许从任何域进行 flash 访问

可能会窃取或操纵客户会话和 cookie，它们可能用于模仿合法用户，从而使黑客能够以该用户身份查看或变更用户记录以及执行事务

请安装 文件中 allow-access-from 实体的 domain 属性来包括特定域名，而不是任何域。

1.22. 针对网站后台管理口令弱漏洞整改建议

加强口令强度，建议密码为8位以上以字母、数字、符号的组合。

建议用户对网站后台采取IP授权管理，只有被认证的IP可以远程访问网站后台。

1.23. 目录列表

危害

攻击者在您的应用程序服务器上发现“目录列表”所带来的风险取决于所发现的目录类型以及其中包含的文件类型。可访问目录列表的主要威胁是，数据文件、源代码或开发中的应用程序等隐藏文件将对于潜在攻击者可见。除访问包含敏感信息的文件以外，其他风险包含攻击者利用在该目录中发现的信息执行其他类型的攻击。

可能会查看和下载特定 Web 应用程序虚拟目录的内容，其中可能包含受限文件

整改建议

对于开发部门：

除非您主动参与实施 Web 应用程序服务器，否则对于因攻击者找到目录列表而可能发生的问题，尚没有太多可用的解决方案。此问题将主要由 Web 应用程序服务器管理员解决。但是，可以采取一些措施来帮助保护 Web 应用程序。

•

•

限制只有那些确实需要的人员才可以访问重要文件和目录。

确保包含敏感信息的文件不可公开访问，或者遗留在文件中的注释不会泄漏机密目录的位置。

对于安全运营部门：

保证 Web 应用程序安全性最重要的一个方面是，限制只有那些确实需要访问的人员才可以访问重要文件和目录。确保不要将 Web 应用程序的专有体系结构暴露给任何希望查看该结构的人员，因为即使表面上看似无害的目录也可能向潜在攻击者提供重要信息。

以下建议可帮助您避免无意中允许对可用于进行攻击的信息和存储在可公开访问目录中的专有数据进行访问。

•

•

•

•

在您使用的任何应用程序服务器软件包中关闭自动目录列表功能。

限制只有那些确实需要的人员才可以访问重要文件和目录。

确保不要将包含敏感信息的文件保留为可公开访问的状态。

对于隐藏目录，请勿遵循标准的命名规则。例如，不要创建名为“cgi”的包含 cgi 脚本的隐藏目录。太明显的目录名称...很容易被攻击者猜到。

请记住，越是让攻击者难以访问有关 Web 应用程序的信息，他就越是有可能轻易地找到更易攻击的目标。

1.24. How to disable directory listings

•

•

•

The easiest way to disable directory listing is to create an index file. The name of the

index file depends on the web server configuration. On Apache is called ,

. On IIS is named , , .

On IIS directory listings are disabled by default.

For Apache you need to edit the Apache configuration file (usually named ) or

create an .htaccess file. In the configuration file you will have the definition of the

directory. Something like

•

Options Indexes FollowSymLinks

•

...

•

To disable directory listing for that directory you need to remove the 'Indexes' option.

配置apache的配置文件，看到目录文件进行如下时。

Options Indexes FollowSymLinks

...

去掉Indexes参数即可

1.25. 针对内部IP地址泄露漏洞整改建议

对攻击者而言，泄露内部 IP 非常有价值，因为它显示了内部网络的 IP 地址方案。知道内部网络的 IP 地址方案，可以辅助攻击者策划出对内部网络进一步的攻击。

禁止使用IP链接，防止内部网络信息泄露，可以把IP链接改成域名连接方式即可。

1.26. 针对敏感信息泄露漏洞的整改建议

危害：

由于服务器配置或开发设计不当，导致的敏感信息泄漏问题。例如根据页面的错误提示，我们可以知道该数据库信息、中间件名称，版本，甚至是目录列表等，然后制定有针对性的攻击。

整改建议：

1、 检查输入请求，以了解所有预期的参数和值是否存在。 当参数缺失时，发出适当的错误消息，或使用缺省值。

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

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

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

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

6、 将所有的错误信息设定统一的返回页面。 1.27. 针对 Padding Oracle漏洞整改建议

1、根据相应的软件只要打上微软官方的相应补丁。

2、如果您使用的是1.0，1.1，2.0或3.5，那么你应该遵循以下的步骤，开启使所有错误映射到某一个错误页面上。

<>

3、如果您使用的是3.5 SP1或4.0，那么你应该遵循以下步骤，开启使所有错误映射到某一个错误页面上。

<>

defaultRedirect="~/" />

攻击者利用此漏洞可以查看目标服务器的加密的数据，如视图状态，或从服务器中的文件中读取数据，如中。这将允许攻击者篡改数据的内容。通过发回改变内容给受影响的服务器，攻击者可以观察到由服务器返回的错误代码。

1.28. 针对.net错误信息漏洞整改建议

将应用程序配置为不向远程用户显示错误

在应用程序的 文件中，对 customErrors 元素执行以下更改：

将 mode 属性设置为 RemoteOnly（区分大小写）。这就将应用程序配置为仅向本地用户（即开发人员）显示详细的错误。

•

（可选）包括指向应用程序错误页面的 defaultRedirect 属性。

•

（可选）包括将特定错误重定向到特定页面 元素。例如，可以将标准 404 错误（未找到页面）重定向到自己的应用程序页。

• 下面的示例显示了 文件中典型的 customErrors 块。

statusCode="403" redirect=""/>

*摘录结束*

在这种情况下，应将 500 错误重定向到自定义页面：

statusCode="403" redirect=""/>

statusCode="500" redirect=""/>

任何时候都不应该在生产 Web 应用程序上提供详细的错误报告。错误消息为攻击者提供关于应用程序的有用信息，这些消息通常是协助攻击者执行攻击的第一步。

1.29. 针对服务器路径泄露漏洞整改建议

以下建议将有助于确保潜在攻击者不会从显示的任何错误消息中得到有价值的信息。

统一的错误代码：确保您不会使用不一致或“冲突的”错误消息而在无意中将信息提供给攻击者。例如，请不要通过错误消息（如“拒绝访问”）泄漏非预期信息，这样也会让攻击者知道他搜索的文件确实存在。对于存在、不存在以及拒绝读取权限的文件和文件夹，应使用一致的术语。

•

信息性错误消息：确保错误消息不会泄漏过多信息。完整或部分路径、变量和文件名、表中的行和列名称以及特定的数据库错误切不可泄漏给最终用户。请记住，攻击者将收集尽可能多的信息，然后将一些表面上无害的信息整合到一起即可策划攻击方法。

•

适当的错误处理：使用常规错误页面和错误处理逻辑向最终用户通知潜在问题。不要提供可供攻击者在策划攻击时使用的系统信息或其他数据。

•

可能会检索 Web 服务器安装的绝对路径，这可能会帮助攻击者开展进一步攻击和获取有关 Web 应用程序文件系统结构的信息

1.30. 针对内部IP地址泄露漏洞整改建议

禁止使用IP链接，防止内部网络信息泄露，可以把IP链接改成域名连接方式即可。

发现了与内部/保留 IPv4 或 IPv6 地址范围相匹配的字符串。这可能会泄漏有关内部网络的 IP 寻址方案的信息，对攻击者很有价值。

1.31. Frontpage Server Extensions 服务配置泄漏

()

危害

在某个运行 Microsoft FrontPage Server Extensions 的系统上的 _vti_pvt

目录中找到了 文件。该文件包含可由 Web 用户更新的文件的反向链接，如“保存结果”表单处理程序结果文件。攻击者可能会请求易受攻击的文件，从而导致服务泄漏敏感系统信息。攻击者可以利用此信息对受影响的主机进一步发动攻击。建议不需要该文件时将其从系统上删除，或严格设置默认权限。

fix

如果不再需要该文件，将其从系统上删除。将丢失所有的 FrontPage 功能，所有 FrontPage Server Extension 功能（包括发布功能）都无法工作。

如果需要该文件，请确保访问控制列表 (ACL) 不会向匿名用户授予

文件的访问权限。严格设置默认权限，防止未经授权访问此文件。阻止未经授权访问该文件可防止向潜在攻击者泄漏敏感系统信息。

1.32. IIS Missing Host Header Internal IP Address

Disclosure

在某些配置下，当 HTTP/1.0 请求不包含主机标头时，IIS 可能会泄漏其内部 IP

地址。

信息泄漏漏洞会向攻击者泄漏有关系统或 Web 应用程序的敏感信息。尝试在未经授权的情况下进行访问时，攻击者可以使用这些信息了解有关系统的更多信息。

1.33.

SQL注入漏洞

每个提交信息的客户端页面，通过服务器端脚本（JSP、ASP、ASPX、PHP等脚本）生成的客户端页面，提交的表单（FORM）或发出的连接请求中包含的所有变量，必须对变量的值进行检查。过滤其中包含的特殊字符，或对字符进行转义处理。特殊字符包括：

SQL语句关键词：如 and 、or 、select、declare、update、xp_cmdshell；

SQL语句特殊符号：’、”、;等；

此外，Web应用系统接入数据库服务器使用的用户不应为系统管理员，用户角色应遵循最小权限原则；具体建议如下：

1. 严格定义应用程序可接受的数据类型（例如，字符串、字母数字字符等）。

2. 使用肯定的定义而非否定的定义。验证输入中是否存在不正确的字符。采用这样一种基本原理：使用肯定的定义而非否定的定义。有关详细信息，请参阅下面的代码示例。

3. 不要向最终用户显示提供的信息（如表名）可用于策划攻击的错误消息。

4. 定义受允许的字符集。例如，如果某个字段要接受数字，请使该字段仅接受数字。

5. 定义应用程序接受的最大和最小数据长度。

指定输入可接受的数字范围。

影响

SQL 注入是一种攻击方法，其中攻击者可以利用易受攻击的代码和应用程序将接受的数据类型，可在影响数据库查询的任意应用程序参数中利用该攻击方法。正常 SQL 注入攻击很大程度上取决于攻击者使用从错误消息获取的信息对原始

SQL 查询进行的反向工程部分。但是，即使未显示错误消息，您的应用程序仍然易受 SQL 盲注的影响。如果成功，SQL 注入可使攻击者有权访问后端数据库内容、能够远程执行系统命令，在某些情况下甚至可以控制托管数据库的服务器。

1.34.

跨站脚本漏洞

每个提交信息的客户端页面，通过服务器端脚本（JSP、ASP、ASPX、PHP等脚本）生成的客户端页面，提交的表单（FORM）或发出的连接请求中包含的所有变量，必须对变量的值进行检查。过滤其中包含的特殊字符，或对字符进行转义处理。特殊字符包括：

HTML标签的<符号、“符号、’符号、%符号等，以及这些符号的Unicode值；

客户端脚本（Javascript、VBScript）关键字：javascript、script等；

此外，对于信息搜索功能，不应在搜索结果页面中回显搜索内容。同时应设置出错页面，防止Web服务器发生内部错误时，错误信息返回给客户端。具体建议如下：

1. 定义允许的行为。确保 Web 应用程序根据预期结果的严格定义来验证所有输入参数（Cookie、标头、查询字符串、表单、隐藏字段等）。

2. 检查POST 和 GET 请求的响应，以确保返回的对象是预期的内容且有效。

3. 通过对用户提供的数据进行编码，从用户输入中移除冲突的字符、括号和单双引号。这将防止将插入的脚本以可执行的格式发送给最终用户。

4. 只要可能，就应将客户端提供的所有数据限制为字母数字数据。使用此过滤机制时，如果用户输入“”，将缩减为“scriptalertdocumentcookiescript”。如果必须使用非字母数字字符，请先将其编码为 HTML 实体，然后再将其用在 HTTP 响应中，这样就无法将它们用于修改 HTML 文档的结构。

5. 使用双因素客户身份验证机制，而非单因素身份验证。

6. 在修改或使用脚本之前，验证脚本的来源。

7. 不要完全信任其他人提供的脚本并用在您自己的代码中（不论是从 Web

上下载的还是熟人提供给您的）。

影响： 跨站脚本漏洞可以再分成两类：Stored attack 和 Reflected attack。这两种攻击的主要区别在于有效负荷到达服务器的方式。Stored attack 仅以某种形式存储在目标服务器上（例如在数据库中），或通过提交至公告板或访问者日志来进行存储。如果请求了所存储的信息，受害者将在自己的浏览器中检索和执行攻击代码。而 Reflected attack 则来自其他地方。当通过动态生成的网页中的服务器端，直接将 Web 客户端的用户输入包含在内时，就会出现 Reflected

attack。通过某些社会工程手段，例如通过恶意链接或“伪装”表单，攻击者可以哄骗受害者提交信息，然后对信息进行修改以包含攻击代码，并将其发送至合法服务器。注入的代码随后将反射回用户的浏览器，由于此代码来自受信任的服务器，用户的浏览器将会执行此代码。两种攻击的影响都是相同的。

1.35.

发现目录启用了自动目录列表功能

描述：

目标目录启用了自动目录列表功能。

1.当用户访问的网址是某个目录地址的时候，服务器自动显示该目录所包含的文件列表内容。

2. 当用户请求的URL地址是某个目录地址的时候，如果该目录开启了自动列表功能并且WEB服务器默认的页面文件(如/////等)也不存在，那么该目录所包含的文件就会被自动的以列表的形式显示出来，这样可能就会导致敏感文件被泄露。

危害：

1.任何人都可以浏览该目录下的所有文件列表。

2. 如果该目录不存在默认的主页面文件，并且该目录包含了敏感的文件内容（如应用程序源码文件或其它的重要文件内容），那么将导致敏感文件内容外泄，从而对企业造成直接的经济损失或为恶意攻击者提供进一步攻击的有效信息。

解决方案： 1、如果必须开启该目录的目录列表功能，则应对该目录下的文件进行详细检查，确保不包含敏感文件。

2、如非必要，请重新配置WEB服务器，禁止该目录的自动目录列表功能。

附：1. Apache禁止列目录：

方法一，修改 配置文件，查找 Options Indexes FollowSymLinks，修改为

Options -Indexes；

方法二，在www 目录下的修改.htaccess 配置文件，加入 Options -Indexes。 （推荐）

2. Tomcat 禁止列目录：

在Tomcat的conf/文件里把listings值改为false，即，

……

listings

false

……

PS：修改完后，一定记得重启web服务，才能生效噢！

1.36.

CVS服务器敏感信息泄露漏洞

描述：

目标存在CVS服务器敏感信息泄露漏洞

由于CVS pserver配置不当，导致泄露CVS的连接账号和密码

危害：

黑客可以通过泄露的CVS的连接账号和密码，对网站进行下一步攻击。

解决案： 屏蔽此类信息的输出。

1.37. 针对Tomcat控制台暴露漏洞整改建议

可以删除｛$tomcat_home}/conf/Catalina/localhost目录下的和文件。

1.38. 缺HOST头IP地址泄露整改建议

当黑客得到了主机IP地址之后就可能用各种方法进入这个IP地址，甚至可以得到整个局域网的地址，从而产生很大的危害。

adsutil set w3svc/UseHostName True

net stop iisadmin /y

net start w3svc

Option 1: Set the UseHostName property

To set the UseHostName property, follow these steps:

 Click Start, click Run, type cmd, and then click OK to open a command prompt.

 Change to the folder where the tool is located. By default, this folder is the

following:

%SYSTEMROOT%InetpubAdminScripts

This really means type the following in the command prompt

Type CD /D C:InetpubAdminScipts

 Type the following command, where x is your site identifier:

cscript set w3svc/x/UseHostName true

To get the Site Identifier open the IIS Adminsitrative tool