Web安全测试的步骤

《Web安全测试的步骤》由会员分享，可在线阅读，更多相关《Web安全测试的步骤（7页珍藏版）》请在装配图网上搜索。

1、安全测试方面应该参照 spi 的 web 安全 top 10 来进行。目前做软件测试人员可能对安全性测试了解不够，测试结果不是很好。如果 经验不足，测试过程中可以采用一些较专业的 web 安全测试工具，如 WebInspect Acunetix.Web.Vulerability.Scanner 等，不过自动化 web 安全测试的最大缺陷就是误 报太多，需要认为审核测试结果，对报 告进行逐项手工检测核对。对于 web 安全的测试用例，可以参照 top 10 来写，如果写一个详细的测试用 例，还是比较麻烦的，建议采用安全界常用的web渗透报告结合toplO来写就可以 了。现在有专门做系统和网站安全

2、检测的公司，那里做安全检测的人的技术都很好 大多都是红客。再补充点，网站即使站点不接受信用卡支付，安全问题也是非常重要的。Web 站点收集的用户资料只能在公司内部使用。如果用户信息被黑客泄露，客户在进行 交易时，就不会有安全感。目录设置Web 安全的第一步就是正确设置目录。每个目录下应该有 index.html 或 main.html 页面，这样就不会显示该目录下的所有内容。我服务的一个公司没有执 行这条规则。我选中一幅图片，单击鼠标右键，找到该图片所在的路 径 图片的列表。这可能没什么关系。我进入下一级目录 jackpot.在该目录下有很多资料，其中引起我注意的是已过期页面。该公司每个月 都

3、要更改产品价格，并且保存过期页面。我翻看了一下这些记录，就可以 估计他 们的边际利润以及他们为了争取一个合同还有多大的降价空间。如果某个客户在谈 判之前查看了这些信息，他们在谈判桌上肯定处于上风。SSL很多站点使用SSL进行安全传送。你知道你进入一个SSL站点是因为浏览器 出现了警告消息，而且在地址栏中的HTTP变成HTTPS.如果开发部门使用了 SSL, 测试人员需要确定是否有相应的替代页面（适用于3.0以下版本的浏览器，这些浏 览器不支持SSL.当用户进入或离开安全站点的时候，请确认有相应的提示信息。 是否有连接时间限制？超过限制时间后出现什么情 况？登录有些站点需要用户进行登录，以验证他

4、们的身份。这样对用户是方便的，他们 不需要每次都输入个人资料。你需要验证系统阻止非法的用户名/口令登 录，而能 够通过有效登录。用户登录是否有次数限制？ 是否限制从某些 IP 地址登录？ 如果 允许登录失败的次数为 3，你在第三次登录的时候输入正确的用户名和口令，能通 过验证吗？ 口令选择有规则限制吗？日志文件在后台，要注意验证服务器日志工作正常。日志是否记所有的事务处理？是 否记录失败的注册企图？ 是否记录被盗信用卡的使用？ 是否在每次事务完成的时 候都进行保存？ 记录 IP 地址吗？ 记录用户名吗？脚本语言脚本语言是常见的安全隐患。每种语言的细节有所不同。有些脚本允 许访问根目录。其他只允

5、许访问邮件服务器，但是经验丰富的黑客可以将服务器用 户名和口令发送给他们自己。找出站点使用。洞篇）在本文中，我们将详细为读者介绍针对HTTP截断和HTTP走私攻击的安全测试技 术。我们将通过实例演示如何利用HTTP协议的某些特性，或者利用Web应用程 序的弱点或者不同代理对 HTTP 消息的解释也不相同的特点来发动这两种攻击。一、HTTP截断/走私漏洞概述本文遏制，我们将分析针对特定的HTTP报头的两种不同的攻击技术：HTTP 截断和HTTP走私攻击。对于HTTP截断攻击而言，它是利用了缺乏输入消毒措 施的漏洞，该漏洞允许入侵者向应用程序响应的头部插入CR和LF字符，从而将 响应分割为两个不同

6、的 HTTP 消息。该攻击的目标既不同于缓存投 毒，也区别于 跨站脚本攻击。对于第二种攻击方法，攻击者利用了这样的一个事实，即一些专门 精心制作的 HTTP 消息可能会随着接收它们的代理的不同，而作不 同的解析和解 释。 HTTP 走私技术要求对处理 HTTP 消息的各种代理相当熟悉，否则无法发动这 种攻击。下面我们介绍这些漏洞的黑盒测试和灰盒测试技术。二、HTTP 截断攻击黑盒测试一些 web 应用程序会使用部分用户输入来生成它们的响应头部的某些值，这 方面最简单的例子就是重定向了，因为目标URL依赖于用户提交的某些值。举例 来说，假如用户被要求在标准 web 接口和高级 web 接口之间做

7、出选择，然后，选 择的结果将作为一个参数传递，并且这个参数将用于触发重定向到相应 的页面的 应答头中。更确切地说，如果该参数interface的值是advanced，那么应用程序将响 应下列内容：HTTP/1.1 302 Moved TemporarilyDate: Sun. 03 Dec 20Q9 16:22:19 GMTLocatio匚： htzp:/ sp?inte rf ace=advanced 图1收到这个消息后，浏览器会把用户引向Location头部规定的页面。然而，如 果应用程序没有对用户输入进行过滤的话，攻击者就可以在参数interface中插入序 列0d%0a，而该序列代表的

8、则是用于分割各行的CRLF（回车换行）序列。这样一 来，攻击者将能够触发一个响应，重要的是任何解析器（例如介于用户和Web应用 之间的web缓存）都会把这个响应会被解释为两个不同的响应。所以，攻击者就可 以通过给这个web缓存“投毒”以使它为后续的请求中提供虚假的内容。例如，在 我们前面的例子中，假设攻击者将下列内容作为参数interface进行传递：图2从存在漏洞的软件（也就是没有对用户输入进行严格消毒的应用程序）中得到的 响应将 是 下面的内容：HTTP 1.1 3 C2 Move d leipc rarilyDate: Eun； 03 Dec 2C05 16:22:19 GMTlocaz

9、icn: http: / victin. coiq/main. jsp?inzerfac=advanzecCont5nt-Length: 0HTTPl. 1 2C0 OF：Content-rPe: texz/Co nt?nt-Ler.gta: 3 5Sorry, *2USystem%2 0DownV/html51CT技术成就梦想图3Web缓存将看到两个不同的响应，因此如果攻击者发送第一个请求之后立即 发送对/index.html页面的请求的话，web缓存会认为这个请求与第二个响应相匹配, 并缓存它的内容，这样一来后面经由web缓存的所有指向 请求都会收到系统故障消息，即“system down

10、”。通过这种方式，一个攻击者将能 有效涂改站点在使用web缓存的用户心中的形象，如果该web缓存是该Web应用 程序的一个反向代理的话，那么这个Web应用程序在整个因特网中的用户都会受 到影响。另外，攻击者还可以向这些用户传输发动跨站脚本攻击攻击的 JavaScript 代码片断，例如窃取 cookies 等。需要注意的是，虽然该安全漏洞位于应用程序中， 但是攻击针对的对象却是使用该应用程序的用户。因此，为了查找这个安全漏洞，渗透测试人员需要识别所有能够影响响应的一 个或多个头部的用户输入，并检查用户是否能够在其中注入一个CR+LF序列。与 这个攻击关系最密切的两个头部是：Location S

11、et-Cookie需要注意的是，现实中要想成功利用这个安全漏洞可能是件非常复杂的事情， 因为有多种因素必须考虑到：1. 攻击者要想让伪造的响应被缓存的话，必须正确设置其中的各个头部，例如 Last-Modified头部的值必须设为将来的一个时间。此外，攻击者还必须破坏目标 页面先前的缓存版本，方法是提交一个请求头部中带有“ Pragma: no-cache”的前导 请求来防止页面被缓存。2. 即使应用程序没有过滤CR+LF序列，但是仍可能过滤了发动该攻击所需的 其他字符，例如字符和等。这时候，攻击者可以尝试使用其他编码，例如 UTF- 7编码等。3.某些攻击目标(例如ASP)会对Locatio

12、n头部(例如 )中的路径部分进行URL编码处理，这样就使得CRLF 序列不起作用了。然而，它们却不能对查询部分(例如?interface=advanced)进行这 样的编码处理，这意味着放置一个前导问号就能够绕过这种过滤技术。三、HTTP截断攻击灰盒测试对于Web应用程序即攻击目标的深入了解，在发动HTTP截断攻击时是极其 有帮助的。例如，不同的攻击目标可能使用不同的方法来判定第一个HTTP消息在 何时终止，第二个HTTP消息从什么时候开始。当然，有时候可以使用消息边界来 进行判定，如上面的例子就是这样。但是，其他的攻击目标可能使用不同的数据 包来携带不同的消息。此外，有些目标会为每个消息分配

13、指定组块的数量，这种情 况下，第二个消息必须从特定的块开始，这就要求攻击者在两个消 息之间填充必 要的块。不过，当时有URL发送有弱点的参数的时候，这么做可能会引起一些麻 烦，因为过长的URL很可能被截断或者过滤掉。灰盒测试可以帮助攻击者找到解 决办法：一些应用程序服务器允许使用POST而非GET来发送请求。四、HTTP走私攻击灰盒测试之前讲过，HTTP走私攻击所利用的漏洞是，某些精心构造的HTTP消息会随 不同的代理(浏览器、web缓存、应用程序防火墙)而做不同的解释。这种攻击方 法是由 Chaim Linhart、Amit Klein、Ronen Heled 和 Steve Orrin 于

14、 2005 年发现的。 这种攻击有多种用途，我们这里仅介绍最雷人的一种：绕过应用程序防火墙。下面，我们详细介绍利用HTTP走私攻击绕过应用程序防火墙的详细方法。有 许多应用防火墙都能根据一些已知的嵌入请求的恶意模式来检测和阻止怀 有恶意 的web请求。举例来说，针对IIS服务器的Unicode目录遍历攻击能够通过提交一 个类似下面所示的一个请求发动攻击：图4当然，通过检查URL是否存在类似“.”和“cmd.exe”的字符串可以很容易地检 测和过滤掉这种攻击。然而，IIS 5.0对于POST请求主体的长度是有要求的，最多 为 48K 字节当 Content-Type 头部不同于 applicat

15、ion/x-www- form-urlencoded 时， 超出该限制的部分会被全部截断。攻击者可以利用这一点来创建一个很大的请求 如下所示：POET target asp HTTP/1.1Request #1二匚：:Connection; Keep-Alivecm 43152 bjrtes : garbageJPOST (target asp HTTP/l.D Request =2Connection; Keep-Alive出栄：二-匕:二:：二三P：；T 二皐界：汩XI2? 1.1- -.cug?: =3EL3?. ;：cl4: ,匚二:上汀吐壮三：:二1 z：7：.c-：li:；- ?e

16、qie=t #4Cc-nnctiQn; Kep-AliveC7.1F：-图5这里，Request #1由49223字节内容组成，所以Request #1还包含了 Request #2 的几行内容。因此，防火墙（或者其他任何代理）会看到 Request #1，但是却无法 看到 Request #2（它的数据正好是#1 请求的一部分），能够看到 Request #3 却会遗漏 Request #4（因为该POST正好是伪造的头部xxxx部分）。现在，IIS 5.0将会发生什 么情况?它将在 49152 字节无用信息之后停止对 Request #1 的解析，因为这已经达 到了 48K=49152字节

17、的限制，并将Request #2解析为一个新的、单独的请求。 Request #2声称它的内容为33字节，包括xxxx :之前的所有内容，这使得IIS会漏 掉Request #3,因为Request #3被解释为Request #2的一部分，但是IIS会认出 Request #4，因为它的POST是从Request #2的第33个字节之后开始的。当然，这 看起来有些复杂，但是却很好的解释了为什么该攻击性URL不会被防火墙发现， 却能被IIS正确解析和执行的原因所在。在上面的情形中，虽然我们利用的是web服务器中的安全漏洞，但是在其他 情形中，我们可以通过利用各种支持HTTP的设备在解析不兼容1

18、005 RFC的消息 时所采取的方式各不相同来发动攻击。举例来说，HTTP协议只允许一个Content- Length 头部，但是却没有规定如何处理具有两个Content-Length头部的消息。一些 实现将使用第一个，而另一些实现则使用第二个，这种情况下就很容易遭到 HTTP 走私的攻击。另一个例子是GET消息中Content-Length头部的使用。五、小结在本文中，我们详细为读者介绍了针对HTTP截断和HTTP走私攻击的安全测 试技术。我们通过实例演示了如何利用HTTP协议的某些特性，或者利用Web应 用程序的弱点或者不同代理对HTTP消息的解释也不相同的特点来发动这两种攻击。 希望本文对读者的安全测试工作有所帮助。【51CTO.COM 独家特稿，转载请注明出处及作者!】