**漏洞描述：**搜索引擎可以通过robots文件可以获知哪些页面可以爬取，哪些页面不可以爬取。Robots协议是网站国际互联网行业的道德规范。其目的是保护网站数据和敏感信息，确保用户的个人信息和隐私不受侵犯。robots.txt文件编辑过于详细，会泄露网站的敏感目录或文件，如网站的背景路径，从而了解其使用的系统类型，从而有针对性地使用。

测试方法：

检测形式多样，工具爬虫扫描得到敏感文件的路径，从而找到robots文件；

手动挖掘，域名后直接输入/robots.txt进行查看。

**风险分析：**攻击者可以通过发现robots.txt收集网站的敏感目录或文件，以便有针对性地使用。

风险等级：

【低危】：robots.txt中存在allow和disallow敏感目录信息的具体内容泄露。

**修复方案：**可根据实际情况进行以下相应的修复：

User-agent: * 这里的*所有代表的搜索引擎类型，*是通配符

Disallow: / 这里的定义是禁止搜索网站的所有内容

Disallow: /admin/ 这里的定义是禁止爬寻admin目录下面的目录

Disallow: /ABC/ 这里的定义是禁止爬寻ABC目录下面的目录

Disallow: /cgi-bin/*.htm 禁止访问/cgi-bin/目录下的一切".htm"为后缀的URL(包括子目录)。

Disallow: /? 禁止访问网站中所有包含问号 (?) 的网址

Disallow: /.jpg$ 禁止抓取所有网页.jpg格式的图片

Disallow:/ab/adc.html 禁止爬取ab下面的文件夹adc.html文件。

Allow: /cgi-bin/ 这里的定义是允许爬寻cgi-bin目录下面的目录

Allow: /tmp 这里的定义是允许爬寻tmp的整个目录

Allow: .htm$ 仅允许访问以".htm"为后缀的URL。

Allow: .gif$ 允许抓取网页和gif格式图片

Sitemap: 网站地图 告诉爬虫这个页面是网站地图。

**注意事项：**暂无

**漏洞描述：**敏感数据包括但不限于:密码、密钥、证书、会话标志License、隐私数据（如短信内容）、授权凭证、个人数据（如姓名、地址、电话号码等）可能包含在程序文件、配置文件、日志文件、备份文件和数据库中。

测试方法：

检测形式多样，工具爬虫扫描得到敏感文件的路径，从而找到敏感数据，

手工挖掘，根据web查看容器或网页源代码，找到敏感信息。

**风险分析：**攻击者可以通过上述方式获取网站敏感文件，收集网站敏感信息，从而有针对性地使用。

风险等级：

【高危】：返回包含重要敏感信息的文件，如数据库文件、代码备份文件或svn、git版本控制文件等。

修复方案：

禁止在代码中存储敏感数据：禁止存储数据库连接字符串、密码、密钥等敏感数据，容易导致泄密。用于加密密钥的密钥可以在代码中硬编码。

禁止密钥或帐户密码以明确的形式存储在数据库或文件中：密钥或帐户密码必须加密存储。例外，如果Web在容器配置文件中，连接数据库的用户名和密码只能以明确的方式配置，因此无需强制遵循规则，将配置文件的属性改为只有主可读写。

禁止在 cookie 以明文形式存储敏感数据：cookie信息容易被盗，尽量不要cookie存储敏感数据；如果条件有限，必须使用cookie在存储敏感信息时，必须加密敏感信息并存储到cookie。

明文形式的敏感数据禁止存储在隐藏域。

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

禁止在日志中记录明文的敏感数据：禁止在日志中记录明文的敏感数据（如密码、会话标志）jsessionid等）， 防止敏感信息泄露。

禁止使用敏感数据Web页面缓存：敏感数据Web禁止缓存页面，以防止用户数据通过代理服务器泄露敏感信息或上网。

**注意事项：**暂无

**漏洞描述：**过时文件、备份页面、渗透测试文件、开发文件残留测试文件等。

测试方法：

常见的检测方法是通过网站web扫描漏洞，直接利用爬虫爬网站可能的路径和链接。如果有备份文件，可以通过web直接下载。

还可以通过构建自己的字典来爆破网站目录下的指定字典。常见的扫描工具有wwwscan、后台扫描工具等。

**风险分析：**攻击者可通过上述方式获取网站备份文件、过时文件、遗留文件等内容，收集网站敏感信息，从而有针对性的进行利用。

风险等级：

【高危】：泄露重要敏感信息或核心业务。

【中危】：泄露一般重要信息，只能进行一般功能操作。

【低危】：页面泄露非重要信息，不能操作相关功能。

修复方案：

严格检查网站管理员web备份文件是否存在于可访问路径下，常见备份文件的后缀是.jsp.bak、.bak、.sql、.txt、等等。如果有这些文件，可以直接将备份文件转移到其他目录或删除。

严格控制网站可访问目录下文件敏感性的存储，不要将敏感文件放在目录中。

**注意事项：**暂无

**漏洞描述：**当服务器产生403、404、500等错误页面时，返回详细的错误信息。错误信息可能包括服务器代码信息、数据库连接信息SQL语句或敏感文件的路径为攻击者收集信息提供了便利。

测试方法：

触发服务器产生404错误并返回404页面，通过目录扫描或手动输入不存在的文件或路径；

触发服务器403错误，返回403页面，通过目录扫描或手动输入无权检查的文件或路径；

手动输入单引号、尖括号等不存在参数或特殊结构的字符串，触发服务器产生500错误，返回500页或异常信息。

**风险分析：**攻击者可以通过上述方式触发Web应用程序报错，提取报错信息泄露的敏感信息，如Web版本信息中间件，数据库连接信息。

风险等级：

【高危】：打开调试模式，泄露代码、错误信息等大量应用的敏感信息；

【低危】：未打开调试模式，泄露部分中间版本、少量代码信息等。

修复方案：

编码时添加异常处理模块，统一定制错误页面返回界面，隐藏服务器版本信息；

外部输出程序运行中产生的异常错误信息细节。

**注意事项：**暂无

**漏洞描述：**主机中应用的绝对地址路径在应用中泄露。

测试方法：

打开网页源代码，查看图片等媒体的链接和超链接；

通过报错信息获取

**风险分析：**攻击者可以通过获取网站的物理路径为下一次攻击做准备。

风险等级：

【低危】：绝对路径的泄漏应用

修复方案：

媒体链接和超链接采用相对路径的表达；

不对外输出网站物理路径等敏感信息。

**注意事项：**暂无

**漏洞描述：**明文密码保存在本地客户端

测试方法：

查看网页源代码

查看本地客户端网站的缓存文件

**风险分析：**攻击者可以通过嗅探或直接查看源代码获取传输到前端的帐户和密码，并登录他人的帐户。

风险等级：

【高危】：所有账户的明确密码都保存在本地客户端

【低危】：本账户的明确密码仅存储在本地客户端

**修复方案：**禁止将密码存储在本地客户端，即使是加密的密码也不建议存储在本地，攻击者可以登录或修改其他账户的密码。

**注意事项：**暂无

**漏洞描述：**在渗透过程中发现应用中存在曾经的入侵痕迹，如存在的webshell文件。

**测试方法：**通常使用Web应用安全漏洞扫描工具或目录扫描工具发现入侵痕迹。

**风险分析：**残留的入侵痕迹可被其他攻击者用于二次攻击，对网站造成一定的影响。

风险等级：

【高危】：发现存在入侵痕迹，比如存在Webshell或者网页被篡改。

**修复方案：**可借助工具全盘清理入侵痕迹，如D盾可以扫描Windows系统中的webshell。

**注意事项：**暂无

**漏洞描述：**在服务器返回的HTTP头中泄露服务器信息

测试方法：

在浏览器的调试窗口中查看HTTP响应头

使用代理软件如burpsuite、fiddler，拦截HTTP响应头

**风险分析：**攻击者可通过获取服务器banner信息，针对某个版本存在的漏洞进行定向攻击。

风险等级：

【低危】：泄露服务器版本等信息

修复方案：隐藏或者修改banner信息。

**注意事项：**暂无

**漏洞描述：**目录浏览漏洞是由于网站存在配置缺陷，存在目录可浏览漏洞，这会导致网站很多隐私文件与目录泄露，比如数据库备份文件、配置文件等，攻击者利用该信息可以更容易得到网站权限，导致网站被黑。

**测试方法：**可以利用web漏洞扫描器扫描web应用进行检测，也可通过搜索，网站标题包含“index of”关键词的网站进行访问。

**风险分析：**攻击者通过访问网站某一目录时，该目录没有默认首页文件或没有正确设置默认首页文件，将会把整个目录结构列出来，将网站结构完全暴露给攻击者； 攻击者可能通过浏览目录结构，访问到某些隐秘文件（如PHPINFO文件、服务器探针文件、网站管理员后台访问地址、数据库连接文件等）。

风险等级：

【高危】：目录可以浏览，泄露包含密码、个人信息等敏感文件。

【低危】：目录可以浏览，未泄露包含密码、个人信息等敏感文件。

**修复方案：**目前存在该漏洞的常见中间件为apache和IIS,以下列出其相关的修复方式：

IIS中关闭目录浏览功能：在IIS的网站属性中，勾去“目录浏览”选项，重启IIS。

Apache中关闭目录浏览功能：打开Apache配置文件httpd.conf，查找“Options Indexes FollowSymLinks”，修改为“ Options -Indexes”(减号表示取消，保存退出，重启Apache。

Nginx中默认不会开启目录浏览功能，若您发现当前已开启该功能，可以编辑nginx.conf文件，删除如下两行：autoindex on;autoindex_exact_size on;重启Nginx。

**注意事项：**暂无

**漏洞描述：**存在默认安装中间件、插件、框架等会携带示例页面及说明文档。

测试方法：

可以利用web漏洞扫描器或目录扫描器扫描web应用进行检测

根据网站使用的第三方组件和框架手工输入对应的示例页面。

**风险分析：**攻击者可利用默认页面提供的功能和信息对服务器进行攻击。

风险等级：

【高危】：存在可访问默认页面，泄露高风险敏感信息（如：tomcat 的 examples 目录）。

【中危】：存在可访问默认页面，泄露于业务、操作和配置相关的敏感信息。

【低危】：存在可访问的默认页面，但未泄露敏感信息。

**修复方案：**建议在不影响业务的前提下删除默认页面。

**注意事项：**暂无

**漏洞描述：**应用存在未限制访问的后台，或者能直接登录管理后台。

测试方法：

可以利用web漏洞扫描器或目录扫描器扫描web应用进行检测

识别网站使用的cms框架，判断其默认的管理后台地址。

在网站中寻找管理后台超链接。

**风险分析：**攻击者可通过登录网站管理后台篡改页面，或利用上传功能上传webshell，导致服务器被控制。

风险等级：

【高危】：可访问默认管理后台，通过后台获取 shell。

【中危】：可访问默认管理后台，并成功登录，但无法获取 shell。

【低危】：可访问默认管理后台，但无法登录或执行危险操作。

**修复方案：**建议在不影响业务的前提下，将管理后台隐藏在非常规目录下或增加管理后台的访问限制。

**注意事项：**暂无

**漏洞描述：**Web 控制台是一种基于 Web 的用户界面， 其常常被用于网站后台或者web容器控制台中，其不仅仅局限于容器或者网站管理后台，还包括一些数据库默认地址等。在web安全中，网站系统在泄漏其web容器（中间件）或者数据库的控制台后，存在增加被入侵的风险。常见的web控制台包括以下多种：tomcat、aria2、weblogic、websphere、oracle、jboss、等。这些web的容器控制台常见访问形式：http://hostname:port/load/，例如：http://x.x.x.x:8080/manage/。

**测试方法：**常见的web控制台检测方法：整体思路为首先需识别网站容器的指纹，判断其所采用的中间件，然后去扫描其所开放的端口，根据开放端口信息和常见固定的路径，去判断其控制台地址。以下列举常见控制台的检测方法：

**漏洞描述：**攻击者在参数中输入超长字符串，导致数据溢出，致使应用或者数据库报错引发相关信息泄露，或者引起拒绝服务攻击等问题。

**测试方法：**在前端可控参数中输入超长字符串

**风险分析：**攻击者可通过输入参数溢出触发应用服务器异常或服务器拒绝服务，影响系统可用性。

风险等级：

【高危】：超长参数导致服务器报错引发崩溃拒绝服务。

**修复方案：**限制输入参数内容的长度。

**注意事项：**暂无

**漏洞描述：**目录遍历（任意文件下载）漏洞不同于网站目录浏览，此漏洞不仅仅可遍历系统下web中的文件，而且可以浏览或者下载到系统中的文件，攻击人员通过目录遍历攻击可以获取系统文件及服务器的配置文件等等。一般来说，他们利用服务器API、文件标准权限进行攻击。严格来说，目录遍历攻击并不是一种web漏洞，而是网站设计人员的设计“漏洞”。

测试方法：

通过web漏洞扫描工具对网站实施扫描可能发现目录遍历或者任意文件下载漏洞，发送一系列”…/”字符来遍历高层目录，并且尝试找到系统的配置文件或者系统中存在的敏感文件。

也可通过判断网站语言，并根据其url中部分提供的参数，进行构造相关的路径信息，如收集到网站中间件版本为apache，则想办法构造…/…/…/ WEB-INF/web.xml等，然后查看其是否可被下载出来。随后可构造下载系统文件。

**风险分析：**如果web设计者设计的web内容没有恰当的访问控制，允许http遍历，攻击者就可以访问受限的目录，并可以在web根目录以外执行命令。

风险等级：

【高危】：各场景通用

修复方案：

净化数据：对用户传过来的文件名参数进行硬编码或统一编码，对文件类型进行白名单控制，对包含恶意字符或者空字符的参数进行拒绝。

任意文件下载漏洞也有可能是web所采用的中间件的版本低而导致问题的产生，例如ibm的websphere的任意文件下载漏洞，需更新其中间件的版本可修复。

文件路径保存至数据库，让用户提交文件对应ID下载文件。

用户下载文件之前需要进行权限判断。

文件放在web无法直接访问的目录下。

不允许提供目录遍历服务。

公开文件可放置在web应用程序下载目录中通过链接进行下载。

**漏洞描述：**邮件中的重置密码等链接可预测，导致链接可以直接被猜解访问。

测试方法：

先按照正常流程重置密码，接收重置密码邮件，分析重置链接的构造。

通常情况下链接中会使用token参数使得链接具有唯一性，判断该参数是否可预测。如用户名的md5值，用户名+时间戳的md5值等。

**风险分析：**攻击者通过猜测重置密码链接可重置他人账户的密码。

风险等级：

【高危】：存在需要收件人点击确认的链接中，无安全随机数，或 token 简单可预测。

**修复方案：**重置密码链接中的token使用安全随机数

**注意事项：**暂无

**漏洞描述：**存在于系统登录页面，利用登陆时输入系统存在的用户名错误密码和不存在的用户名错误密码，返回不同的出错信息可枚举出系统中存在的账号信息。

测试方法：

找到网站或者web系统登录页面。

在web系统登录页面，通过手工方式，利用系统中存在的用户名和不存在的用户名，密码随意，尝试登录，查看其回显内容。例如：输入存在的用户名admin，回显如下：密码错误；输入不存在的用户名test，回显如下：用户不存在。如图所示：

**风险分析：**攻击者根据Web应用程序返回的上述提示信息即可枚举系统中存在的登录用户名，然后针对枚举出来的登录用户名，对其密码进行暴力破解。

风险等级：

【低危】：可通过返回关键字对系统可用账号进行枚举。

**修复方案：**建议对网站登录页面的判断回显信息修改为一致：用户名或密码错误。

**注意事项：**暂无

**漏洞描述：**不同的业务系统存在相同的用户名密码，或者不同用户名使用相同的初始密码。

**测试方法：**使用同一个用户名密码登录不同业务系统，看是否均可成功登录。

**风险分析：**攻击者在得到一个业务系统的用户名密码后可尝试登录其他业务系统，造成其他业务系统信息泄漏。或者使用初始密码遍历用户名，批量获取可登录系统的用户名密码。

风险等级：

【高危】：多台服务器的后台或其他服务口令相同。

【高危】：不同用户名使用相同初始密码，且第一次登陆未强制密码修改或强制修改机制可绕过继续使用初始密码。

【低危】：同样的账户名密码可以在多个系统上登录。

修复方案：

设置每个账号的初始密码均不同，且不可预测。

不同业务系统采用不同的账号密码体系。

**注意事项：**暂无

**漏洞描述：**认证过程中传输未加密（用户名密码等敏感数据明文传输）。

测试方法：

找到网站或者Web系统登录页面

通过对网站登录页面的请求进行抓包，工具可用burp、wireshark、filder、等等，分析其数据包中相关password（密码）参数的值是否为明文。如图利用wireshark抓包分析的密码：

**风险分析：**攻击者通过在局域网中嗅探网络流量，获取明文传输的认证凭证，如用户名密码、SESSIONID等敏感信息。

风险等级：

【中危】：传输数据包含明文密码、链接、明文身份证、明文地址等其他敏感信息。

【中危】：GET方式明文传输用户名密码。

【中危】：Token或者用户身份标识，以GET方式显示在URL中。

**修复方案：**建议按照网站的密级要求，需要对密码传输过程中进行加密得使用加密的方式传输，如使用HTTPS， 但加密的方式增加成本，或许会影响用户体验。如果不用 HTTPS，可以在网站前端用 Javascript 做密码加密，加密后再进行传输。

**注意事项：**暂无

**漏洞描述：**登录、验证等页面的隐藏域中存在密码信息。

**测试方法：**查看网页源代码，寻找隐藏域中是否存在密码等信息。

**风险分析：**攻击者通过在局域网中嗅探网络流量，获取明文传输的认证凭证，如用户名密码。

风险等级：

【高危】：隐藏域中存在密码等信息

**修复方案：**禁止在前端页面中保存密码等敏感信息。

**注意事项：**暂无

**漏洞描述：**认证登录环节存在弱口令

测试方法：

找到网站登录页面，尝试输入常见弱口令；

根据网站所使用的第三方组件，寻找特定的弱口令或默认口令进行登录。

**风险分析：**攻击者可利用互联网公开的常见弱口令尝试登录管理后台，对网站造成一定的影响。

风险等级：

【高危】：存在弱口令

**修复方案：**禁止使用弱口令，口令应满足一定的复杂度。

**注意事项：**暂无

存在暴力破解

**漏洞描述：**认证登录环节允许空口令

测试方法：

找到网站登录页面，尝试输入用用户名，密码为空进行登录。

**风险分析：**攻击者可利用该漏洞登录网站后台，操作敏感数据，甚至上传webshell，从而控制服务器。

风险等级：

【高危】：存在空口令

**修复方案：**判断输入密码是否为空，禁止空口令登录。

**注意事项：**暂无

**漏洞描述：**能够绕过应用认证，直接登录系统。

**测试方法：**绕过认证主要有几下几种途径：

• 网络嗅探。通过网络嗅探工具探测局域网中传输的明文用户名和密码。有些应用程序采用GET方式发送登录请求，可能导致GET的URL请求内容被缓存在代理服务器活着Web服务器端，导致用户名和密码泄漏。
• 默认或可猜测的用户账号。大多数开源软件或商业软件提供的基于网络配置和管理的接口，通常都会有一些默认的用户名和密码。例如，一般默认的用户名是：admin，administrator、root、system、guest等，而默认的秘密吗也根据硬件和软件的不同而不同，可尝试一下这些密码：password、admin、guest、12345等。
• 直接访问内部URL。使用Spider工具找到含有admin、manager、administrator、login等词语的路径，尝试使用普通的登录用户访问这些URL。从而获得管理员的权限。
• 修改参数绕过认证。应用程序可能会会使用一个参数或一个隐藏的域表示一个用户是否经过验证了，通过修改这些参数，从而被认为是已经认证过的用户。例如：http://www.xxx.xom/userinfo.jsp?authenticated=no，通过修改authenticated参数为yes，http://www.xxx.xom/userinfo.jsp?authenticated=yes，然后就可以通过认证，直接访问内部页面。
• 可猜测的SessionID。利用规律，猜测到一个有效的SessionID，然后通过修改请求中的SessionID为一个预测到的有效的SessionID，从而冒充会话的真正拥有着，绕过认证环节。
• 注入问题。利用万能密码登录系统，绕过认证环节。
• CSRF。利用CSRF漏洞在用户不知情的情况下，利用用户的会话进行敏感操作，从而绕过认证。

**风险分析：**如果应用程序在认证上没有做好，可以导致恶意用户或者攻击者绕过认证，访问内部资源，这类漏洞通过防火墙和入侵检测系统很难预防。

风险等级：

【高】：能够登录进入应用系统，且可以进行相关操作

【中】：能够登录访问进入应用系统，但无法进行相关操作

**修复方案：**可从以下几个方面预防认证绕过：

对于每一个访问的URL都首先检查是否已经登录（不需要认证的URL除外，例如，帮助页面、免费下载页面等），如果没有登录，则跳转到登录页面。对于已经登录的用户，在退出的时候或者在会话很长时间处于idle状态的时候，需要保证原来的会话被正确的销毁并且不会再被重利用。

规定密码强度要求，防止密码被猜测到。

对于用户是否已经认证，禁止依赖客户端传过来的参数标识，而应将是否登录的标识保存在服务器端的会话中，当接收到该会话的请求时，从会话保存的状态判断是否登录。

对于SessionID一定要使用安全的随机数生成算法，使得SessionID不可预测。

对于暴力破解攻击，建议在尝试3次左右失败之后，使用图形验证码。

**注意事项：**暂无

**漏洞描述：**OAuth是一个在不提供用户名和密码的情况下，授权第三方应用访问Web资源的安全协议。Oauth认证不完全，可越权登录他人账户。

**测试方法：**OAuth认证缺陷具体测试场景如下：

开始认证过程，从提供商那里得到回调，获取code，但暂不访问带有code的URL，如：http://www.xxx.com/connect/facebook/?code=AQCOtAVov1Cu316rpqPfs-8nDb-jJEiF7aex9n05e2dq3oiXlDwubVoC8VEGNq10rSkyyFb3wKbtZh6xpgG59FsAMMSjIAr613Ly1usZ47jPqADzbDyVuotFaRiQux3g6Ut84nmAf9j-KEvsX0bEPH_aCekLNJ1QAnjpls0SL9ZSK-yw1wPQWQsBhbfMPNJ_LqI

**漏洞描述：**通过伪造IP地址能够绕过应用IP地址限制，访问和执行系统相关功能。

**测试方法：**使用代理软件拦截请求包，修改HTTP头中的Host字段，伪造IP地址绕过限制。

**风险分析：**攻击者可利用该漏洞访问受限系统，造成应用系统数据泄漏。

风险等级：

【高危】：访问重要系统/执行重要功能

【中危】：访问非重要系统/执行非重要的功能

修复方案：

使用getServerName()代替getHeader(“Host”)；

在Apache和Nginx里可以通过设置一个虚拟机来记录所有的非法Host header，或者在Apache和Nginx里指定一个ServerName名单；同时，Apache开启UseCanonicalName选项。

**注意事项：**暂无

**漏洞描述：**系统允许多点认证

测试方法：

在浏览器A中使用测试账号登录系统；

同时在浏览器B中使用同一个账号登录系统；

若在多个浏览器中均可登录同一各账号，说明存在多点认证缺陷。

**风险分析：**攻击者在获取到其他用户的账号密码后，可利用该缺陷在用户已登录且未知的情况下进行登录，操作用户账户。

风险等级：

【高危】：多点登录架构可被绕过

【中危】：核心系统允许多点登录

**修复方案：**建议在不影响业务的前提下，关键业务系统应禁止多点认证。当同一账号在其他地方登录时已登录的账号应退出会话，并提示用户账户在其他地区登录，可能存在账号被盗风险。

**注意事项：**暂无

**漏洞描述：**在用户进入登录页面，但还未登录时，就已经产生了一个session，用户输入信息，登录以后，session的id不会改变，也就是说没有建立新session，原来的session也没有被销毁）。攻击者事先访问系统并建立一个会话，诱使受害者使用此会话登录系统，然后攻击者再使用该会话访问系统即可登录受害者的账户。会话固定攻击的原理及流程如下图所示：

攻击者Bob匿名访问www.buybook.com。

服务器与Bob建立了一个会话，比如sessionid为1234567。

Bob构造了一个URL：http://www.buybook.com/login.jsp?sessionid=1234567，发给了受害者Alice。

Alice直接打开此链接，输入自己的用户名和密码登录系统。

此时Bob再次访问http://www.buybook.com/viewprofile.jsp?sessionid=1234567，即可进入Alice的账户。

测试方法：

打开网站登录页面。

登陆前通过软件工具抓取到的cookie信息值与在登录后抓取到的cookie进行对比，如果其值一样，则可判断其会话的cookies或者sessions未进行更新。

**风险分析：**攻击者可能会窃取或操纵客户会话和cookie，用于模仿合法用户，从而以该用户身份查看或变更用户记录以及执行事务。

风险等级：

【中危】：会话可由攻击者建立后发给受害者使用该会话登录系统，然后攻击者利用该会话即可登录受害者账户。

**修复方案：**在用户提供的认证信息（例如用户名和密码）、相应的权限级别发生变化时，服务器端应重新生成SessionID，并强制失效之前的会话，JAVA示例代码如下：

request.getSession().invalidate();//清空session Cookie cookie = request.getCookies()[0];//获取cookie cookie.setMaxAge(0);//让cookie过期 ；

注意：这段代码需要在页面的最后部分加上才可以，否则将报错。

**注意事项：**暂无

**漏洞描述：**密码修改功能常采用分步骤方式来实现，攻击者在未知原始密码的情况下绕过某些检验步骤修改用户密码。

测试方法：

完成修改／重置密码的正常流程；

绕过检验原密码等步骤，直接访问输入新密码页面，输入新密码，修改／重置密码。

**风险分析：**有些密码修改／重置流程采用step=1、step=2类似的方式实现，如果应用校验不全面，攻击者可绕过前面的步骤，直接访问最后一步，输入新密码进行修改／重置。

风险等级：

【高危】：绕过原密码验证或绕过验证码

**修复方案：**一次性填写校验信息（原始密码、新密码等）后再提交修改／重置密码请求。

**注意事项：**暂无

**漏洞描述：**应用程序未校验订单数据的取值范围，交易存在负值反冲。

**测试方法：**提交订单时拦截请求，修改订单参数为负数，如商品单价、数量、总价等。

**风险分析：**通过篡改订单参数，使得订单金额为负值，在使用余额支付时余额反而增加。

风险等级：

【高危】：未对数据进行校验，导致业务数据被污染。

修复方案：

服务器端在生成交易订单时，商品的价格从数据库中取出，禁止使用客户端发送的商品价格。

服务器端对客户端提交的交易数据（如商品ID、商品数量、商品价格等）的取值范围进行校验，将商品ID和商品价格与数据库中的数据对比校验，商品数量为大于零的整型数。

服务器端在生成支付订单时，对支付订单中影响支付金额的所有因素（比如商品ID、商品数量、商品价格、订单编号等）进行签名，对客户端提交的支付订单进行校验。

**注意事项：**暂无

**漏洞描述：**应用程序未校验订单数据的取值范围，交易存在正负值对冲。

**测试方法：**提交订单（包含多种商品）时拦截请求，修改部分商品的单价或数量，保证订单总金额为正数。

**风险分析：**由于应用会校验订单总金额的取值范围，所以在保证该条件满足的前提下，修改个别商品的数量，达到正负值对冲。

风险等级：

【高危】：未对数据进行校验，导致业务数据被污染。

修复方案：

服务器端在生成交易订单时，商品的价格从数据库中取出，禁止使用客户端发送的商品价格。

服务器端对客户端提交的交易数据（如商品ID、商品数量、商品价格等）的取值范围进行校验，将商品ID和商品价格与数据库中的数据对比校验，商品数量为大于零的整型数。

服务器端在生成支付订单时，对支付订单中影响支付金额的所有因素（比如商品ID、商品数量、商品价格、订单编号等）进行签名，对客户端提交的支付订单进行校验。

**注意事项：**暂无

**漏洞描述：**业务逻辑流程分步骤进行且能越过中间校验步骤直接进行后续操作，导致中间校验等步骤失效。

测试方法：

首先完成正常的业务逻辑步骤，获取每一个步骤的请求；

绕过中间步骤，直接访问最后一个或几个验证请求，看是否可绕过。

**风险分析：**攻击者可利用该漏洞绕过业务流程检测，进行非法修改他人密码等危险操作。

风险等级：

【高危】：绕过前面的校验步骤，直接跳转至后面的校验步骤。

**修复方案：**建议在不影响业务的前提下，在Session中添加对每一步流程页面的校验标志位，在新步骤页面浏览过程中，仅能够顺序执行页面校验，不可进行跳步操作，例如：页面二完成后，应更新Flag=3，则仅能够打开页面三。

**注意事项：**暂无

**漏洞描述：**允许使用通配符构造语句查询数据库，导致拒绝服务攻击问题。

**测试方法：**模糊查询时输入第一个字符’%‘或’_'，sql会遍历全表，导致应用访问缓慢。

**风险分析：**SQL中通配符的使用如下：

%包含零个或多个字符的任意字符串。

_任何单个字符。

[]指定范围（例如 [a-f]）或集合（例如 [abcdef]）内的任何单个字符。

[^]不在指定范围（例如 [^a - f]）或集合（例如 [^abcdef]）内的任何单个字符。

在模糊查询LIKE中，对于输入数据中的通配符必须转义，否则会造成客户想查询包含这些特殊字符的数据时，这些特殊字符却被解析为通配符，数据库响应缓慢，导致拒绝服务攻击。

风险等级：

【中危】：通配符注入引发数据库响应缓慢

**修复方案：**有两种将通配符转义为普通字符的方法：

使用ESCAPE关键字定义转义符（通用）

在模式中，当转义符置于通配符之前时，该通配符就解释为普通字符。例如，要搜索在任意位置包含字符串 5% 的字符串，请使用：

WHERE ColumnA LIKE ‘%5/%%’ ESCAPE ‘/’

\2) 在方括号 ([ ]) 中只包含通配符本身，或要搜索破折号 (-) 而不是用它指定搜索范围，请将破折号指定为方括号内的第一个字符。例如：

所以，对输入参数的关键字过滤后，还需要做下面转换确保LIKE的正确执行

private static string ConvertSqlForLike(string sql) { sql = sql.Replace(“[”, “[[]”); // 这句话一定要在下面两个语句之前，否则作为转义符的方括号会被当作数据被再次处理 sql = sql.Replace(“", "[]”); sql = sql.Replace(“%”, “[%]”); returnsql; }

**注意事项：**暂无

**漏洞描述：**短信接收人可任意指定

**测试方法：**拦截发送短信的请求，将手机号改为测试人员的手机号，测试是否可接收短信验证码。

**风险分析：**攻击者可利用该漏洞将验证码发送到自己的手机号上，重置他人密码或转账。

风险等级：

【高危】：短信接收人可任意指定

**修复方案：**发送短信时手机号从当前会话中获取，避免从前端传入。

**注意事项：**暂无

**漏洞描述：**应用系统发送邮件的接收人可由客户端任意指定

**测试方法：**拦截发送邮件的请求，将接收人邮箱改为测试人员的邮箱地址，测试是否可接收邮件。

**风险分析：**攻击者可利用该漏洞将邮件发送到自己的邮箱中，重置他人密码。

风险等级：

【高危】：邮件接收人可任意指定

**修复方案：**发送邮件时邮箱从当前会话中获取，避免从前端传入。

**注意事项：**暂无

**漏洞描述：**应用的业务接口存在缺陷，可以通过业务接口直接进行恶意操作。

**测试方法：**把业务逻辑和功能模块呈现的内容结合，推测出隐藏的API接口。如用户信息的接口是http://www.xxx.com/api/user/userInfo，推测重置密码接口可能是http://www.xxx.com/api/user/passReset，文件上传接口是http://www.xxx.com/api/user/uploadFile等。如果这些接口没有限制访问，则可以直接调用并提交数据。

针对开源或商业软件的业务接口调用缺陷可参考《通用系统安全测试指导文档》

**风险分析：**攻击者可通过编写API枚举脚本，恶意调用敏感接口，从而进行提交数据等操作。

风险等级：

【高危】：通过业务接口能够操作核心业务内容，进行越权

【高危】：通过业务接口能够获得重要敏感数据

【中危】：通过业务接口能够获得中等程度敏感数据

**修复方案：**对于每一个访问的接口都首先检查当前用户是否已经登录并授权（不需要认证的接口除外，例如，免费下载接口等）。

**注意事项：**暂无

**漏洞描述：**和广为人知的诸如SQL注入、XPath注入等技术类似，邮件服务器注入技术也是通过一个对用户提供的数据没有严格检查的webmail应用程序将IMAP命令或者SMTP命令注入到邮件服务器。要向邮件服务器注入命令，前提条件是允许用户通过webmail应用程序访问其端口25（SMTP）和143（IMAP）。

**测试方法：**要利用SMTP注射，用户必须事先通过认证，所以用户必须有一个有效的webmail帐户。通过SMTP发送电子邮件消息的格式如下：

发送方的e-mail地址

接收方的e-mail地址

主题

消息主体

附件

CC/BCC注入 在发送者字段(sender)后注入CC和BCC参数 From:sender@domain.com%0ACc:recipient@domain.com%0ABcc:recipient1@domain.com 所以现在,消息将被发送到recipient和recipient1账户。

参数注射 From:sender@domain.com%0ATo:attacker@domain.com 现在消息将被发送到原来的收件人和攻击者帐户。注意，这里的攻击者的账户是我们通过注入额外传入的。

邮件主题注入 From:sender@domain.com%0ASubject:This’s%20Fake%20Subject 攻击者注入的假的主题subject将被添加到原来的主题中并且在某些情况下将取代原本的主题subject。这取决于邮件服务行为。即代码编写的容错性，当参数中出现两个subject的时候代码是选择丢弃还是后者覆盖。

改变消息的主体body 要注意SMTP的Mail格式，消息主题和头部Header之间有两个换行符(和HTTP是一样的)。 From:sender@domain.com%0A%0AMy%20New%20%0Fake%20Message. 假消息将被添加到原始消息中。

**风险分析：**电子邮件注入允许恶意攻击者注入任意邮件头字段,BCC、CC、主题等,它允许黑客通过注入手段从受害者的邮件服务器发送垃圾邮件。

风险等级：

【高危】：可成功劫持密码找回等信息

【高危】：可成功发送垃圾邮件

**修复方案：**建议从以下几个方面进行防御：

所有用户输入应该被认为是不可信的。使用正则表达式来过滤用用户提交的数据。例如，可以在输入字符串中搜索(r 或 n)。

使用外部组件和库，例如ZEND mail、PEAR mail和swift mailer。

ModSecurity可以阻止服务器级别的电子邮件注入。利用ModSecurity，可以检测通过POST或GET提交的CC, BCC或目的地址，并且拒绝任何包含这些字母请求。

**注意事项：**暂无

**漏洞描述：**页面中引用了不可控的脚本或超链接

**测试方法：**检查页面内容，是否引用了第三方未知脚本或超链接，如恶意的js脚本或病毒木马的下载链接等。

**风险分析：**攻击者可在网站中插入恶意链接或脚本，导致正常用户浏览时cookie被窃取或被种植病毒木马。

风险等级：

【高危】：存在不可控外链或脚本，且未经过审批

【中危】：存在不可控外链或脚本，但可提供审批记录

**修复方案：**建议在不影响业务的前提下，对网站引用的文件和源代码进行审查，一经发现有未审批的外链或脚本，应立即删除。

**注意事项：**暂无

**漏洞描述：**开启可利用的危险接口，如获取订单信息、用户身份信息等。

测试方法：

使用扫描器扫描特殊目录和链接

根据正常接口的命名特征猜测隐藏的危险接口，如获取个人信息接口是getUserInfo，猜测获取订单信息接口getOrderDetail。

**风险分析：**开启了危险接口，如订单信息打印、上传、web管理控制台等，可能被攻击者发现并利用，直接操作应用数据，造成数据泄漏等风险。

风险等级：

【高危】：正常情况接口是在认证之后被调用，如果可公网直接无认证使用

【中危】：存在特权、非正常用户不可知但可利用接口

修复方案：

敏感接口增加访问控制，避免未授权访问；

用户访问接口需校验权限，避免越权访问。

**注意事项：**暂无

**漏洞描述：**服务端未对传入的跳转url变量进行检查和控制，可能导致可恶意构造任意一个恶意地址，诱导用户跳转到恶意网站。由于是从可信的站点跳转出去的，用户会比较信任，所以跳转漏洞一般用于钓鱼攻击，通过转到恶意网站欺骗用户输入用户名和密码盗取用户信息，或欺骗用户进行金钱交易；也可能引发的XSS漏洞（主要是跳转常常使用302跳转，即设置HTTP响应头，Locatioin: url，如果url包含了CRLF，则可能隔断了http响应头，使得后面部分落到了http body，从而导致xss漏洞）。另外在struts2 中存在重定向的漏洞，是因为struts2由于缩写的导航和重定向前缀“action:”、 “redirect:”、 “redirectAction:” 等参数前缀的内容没有被正确过滤导致的开放式重定向漏洞。

测试方法：

首先找到网站相关url中存在跳转链接的参数（如登陆页面）。

在检测的同时，可以修改参数中的合法URL为非法URL，然后查看是否能正常跳转或者通过抓包工具获取其HTTP响应头中Host:的值是否包含了构造的URL。

如果是struts2重定向漏洞，则可通过web扫描工具扫描发现，或者手工验证，直接在URL后添加?redirect:+指定钓鱼链接，例如：10.1.82.53:9098/admin/login.action?redirect:http://diaoyu.com进行验证。

**风险分析：**攻击者利用URL跳转漏洞来欺骗安全意识低的用户，从而导致“中奖”之类的欺诈事件发生。同时利用URL跳转，也可以突破常见的基于“白名单方式”的一些安全限制，如传统IM里对于URL的传输会进行安全校验，但是对于知名网站的域名及URL将直接允许通过并且显示为可信的URL，一旦该可信的URL里包含URL跳转漏洞将导致安全限制被绕过。URL跳转最典型的例子就是登录跳转，示例代码如下：

public void doRedirect(HttpServletRequest req, HttpServletResponse res) { String jumpURL=request.getParameter(“jumptoURL”); response.setHeader(“Location”,jumpURL); }

若程序未过滤jumptoURL参数，攻击者将恶意链接：http://www.xxx.com/login.jsp?jumptoURL=http://www.evil.com发给其他用户，安全意识较低的用户会认为该链接展现的内容是www.xxx.com，从而产生欺诈行为。同时由于QQ、淘宝旺旺等在线IM都是基于URL的过滤，对部分站点会通过白名单的方式直接通过，因此恶意URL可以在IM里传播。例如IM认为www.xxx.com是可信的，但是通过在IM里点击上述链接将导致用户最终访问http://www.evil.com。

风险等级：

【高危】：URL 跳转参数可控，且未对参数做白名单限制导致任意地址跳转可被利用钓鱼。

**修复方案：**对传入的URL做有效性的认证，保证该URL来自于信任域。限制的方式可参考以下两种：

限制Referer（Referer是HTTP header中的字段，当浏览器向web服务器发送请求时，一般会带上Referer，告诉服务器是从哪个页面链接过来的），通过限制Referer保证将要跳转URL的有效性，避免攻击者生成自己的恶意跳转链接；

加入有效性验证Token，保证所有生成的链接都来自于可信域，通过在生成的链接里加入用户不可控的Token对生成的链接进行校验。

**注意事项：**暂无

**漏洞描述：**服务端请求伪造攻击（Server-side Request Forgery）: 很多web应用都提供了从其他的服务器上获取数据的功能。使用用户指定的URL，web应用可以获取图片，下载文件，读取文件内容等。这个功能如果被恶意使用，可以利用存在缺陷的web应用作为代理攻击远程和本地的服务器。这种形式的攻击称为服务端请求伪造攻击（Server-side Request Forgery）。一般情况下， SSRF攻击的目标是从外网无法访问的内部系统 。（ 正是因为它是由服务端发起的，所以它能够请求到与它相连而与外网隔离的内部系统 ）.SSRF 形成的原因大都是由于 服务端提供了从其他服务器应用获取数据的功能且没有对目标地址做过滤与限制 。比如从指定URL地址获取网页文本内容，加载指定地址的图片，下载等等。攻击者利用ssrf可以实现的攻击主要有5种:

可以对外网、服务器所在内网、本地进行端口扫描，获取一些服务的banner信息;

攻击运行在内网或本地的应用程序（比如溢出）;

对内网web应用进行指纹识别，通过访问默认文件实现;

攻击内外网的web应用，主要是使用get参数就可以实现的攻击（比如struts2，sqli等）;

利用file协议读取本地文件等。

**测试方法：**从WEB功能上寻找：我们从上面的概述可以看出，SSRF是由于服务端获取其他服务器的相关信息的功能中形成的，因此我们大可以列举几种在web 应用中常见的从服务端获取其他服务器信息的的功能。

通过分享功能：通过URL地址分享网页内容：

早期分享应用中，为了更好的提供用户体验，WEB应用在分享功能中，通常会获取目标URL地址网页内容中的标签或者标签中content的文本内容作为显示以提供更好的用户体验。例如人人网分享功能中：http://widget.renren.com/*****?resourceUrl=https://www.nsfocus.com

通过目标URL地址获取了title标签和相关文本内容。而如果在此功能中没有对目标地址的范围做过滤与限制则就存在着SSRF漏洞.

转码服务：通过URL地址把原地址的网页内容调优使其适合手机屏幕浏览：由于手机屏幕大小的关系，直接浏览网页内容的时候会造成许多不便，因此有些公司提供了转码功能，把网页内容通过相关手段转为适合手机屏幕浏览的样式。例如百度、腾讯、搜狗等公司都有提供在线转码服务。

在线翻译：通过URL地址翻译对应文本的内容。提供此功能的国内公司有百度、有道等。

图片加载与下载，通过URL地址加