目录
一、测试逻辑缺陷
1.1、确定关键的受攻击面
1、逻辑缺陷的形式多种多样,并且可能存在于应用程序功能的每一方面,为确保探查逻辑缺陷的效率,首先应该将受攻击面缩小到一个适当的范围,以方便手动测试
2、检查应用程序解析过程中获得的结果, 确定以下情况
A、多阶段过程
B、重要的安全功能, 如登录
C、信任边界的转换(如登录时由匿名用户转变为自我注册用户)
D、检在和调整交易价格或数量
1.2、测试多阶段过程
1、如果一个多阶段过程需要按预定的顺序提交一系列请求,尝试按其他顺序提交这些请求,尝试完全省略某些阶段,几次访问同一个阶段,或推后访问前一个阶段
2、这些阶段可能通过一系列指向特殊URL的GET或POST请求进行访问,或需要向同一个URL提交不同的参数,被访问的阶段可通过在被请求的参数中提交功能名称或索引来指定,确保完全了解应用程序访问不同阶段所使用的机制
3、除了打乱操作步骤的顺序外,尝试提取在一个过程阶段提交的参数,并在另一个阶段提交这些参数,如果相关数据被应用程序更新,应当确定是否可以利用这种行为破坏应用程序的逻辑
4、如果在一个多阶段过程中,不同的用户对同一组数据进行操作,提取某一名用户提交的每一个参数,再由另一名用户提交这些参数,如果应用程序接受并处理这些参数,探索这种行为的衍生效果
5、根据执行功能的情形,了解开发者做出的假设以及主要受攻击面位于何处,设法找到违反这些假设以在应用程序中造成反常行为的方法
6、如果不按顺序访问多阶段功能,应用程序常常表现出一系列异常现象,如变量值为空字符或未被初始化,状态仅部分定义或相互矛盾,以及其他无法预料的行为,寻找有用的错误消息和调试结果,可以通过它们进一步了解该功能的内部机制,从而调整当前攻击,或发动另一次攻击
1.3、测试不完整的输入
1、应用程序的重要安全功能需要处理大量用户提交的输入,并根据这些输入做出决策,因此应测试这些功能对不完整输入的适应性
2、轮流测试每一个参数,从请求中删除参数的名称与值,监控应用程序的响应,查找所有行为异常或错误消息,它们可能提供与应用程序逻辑有关的信息
3、如果所操纵的请求属于一个多阶段过程,应测试整个过程,因为应用程序可能将前一个阶段的数据保存在会话中,然后在后一个阶段处理
1.4、测试信任边界
1、了解应用程序如何处理不同用户信任状态之间的转换,寻找功能,帮助一名拥有特定信任地位的用户累积一定量与其身份有关的状态,如匿名用户在自我注册过程中提供个人信息,或完成旨在确认其身份的账户恢复过程
2、寻找办法,通过在一个区域积累相关状态,在信任边界之间进行不恰当的转换,然后以正常不被允许的方式切换到另一个区域。如完成部分账户恢复过程后,尝试切换到与某一名用户有关的通过验证的页面,当进行这种转换时,测试应用程序是否分配了一个不相称的信任级别
3、确定是否可利用更高权限的功能直接或间接访问或者猜测某些信息
1.5、测试交易逻辑
1、如果应用程序设置交易限额,测试提交负值会造成什么影响,如果应用程序接受负值,就可以通过从反方向进行大额交易来规避这种限额
2、分析是否可以使用一连串的交易达成一种状态,然后利用它达到目的。如测试是否可以在账户之间进行几次低额转账,就可以产生一种应用程序的逻辑将会阻止的较大余额
3、如果应用程序根据用户控制的数据或操作确定的标准调整价格或其他敏感价值,首先应了解应用程序使用的算法以及需要调整的逻辑,确定这些调整是一次性行为,还是需要根据用户执行的其他操作进行修改
4、想办法操纵应用程序的行为,使应用程序进行的调整与开发者妏初设定的标准相互矛盾
二、测试共享主机漏洞
2.1、测试共享基础架构之间的隔离
1、如果应用程序在一个共享基础架构中运行,分析它为共享环境中的客户端提供的用于更新和管理其内容与功能的访问机制,考虑:
A、远程访问机制是否使用一个安全的协议与经过适当强化的基础架构
B、客户端是否能够访问他们正常情况下不能访问的文件、数据及其他资源
C、客户端是否能够在主机环境中获得一个交互式的shell,并执行任意命令
2、如果使用一个所有权应用程序,以方便客户端配置和定制共享环境,考虑是否能够以这个应用程序为攻击目标,攻破该环境本身以及其中运行的所有应用程序
3、如果能够在某个应用程序中执行命令、注入SQL脚本或访问任意文件,仔细研究,看是否能够以此扩大攻击范围,攻破其他应用程序
2.2、测试使用ASP主机的应用程序之间的隔离
1、如果使用ASP主机的应用程序由许多共享与定制组件构成,确定其中的任意共享组件,如日志机制、管理功能以及数据库代码组件,尝试利用这些组件攻破应用程序的共享部分,进而攻破其他应用程序
2、如果共享环境使用一个常用的数据库,使用NGSSquirrel之类的数据库扫描工具,全面审查数据库配置、补丁版本、表结构以及许可,数据库安全模型中存在的任何缺陷都可加以利用,将攻击范围由一个应用程序扩大到另一个应用程序
三、测试Web服务器漏洞
3.1、测试默认证书
1、检查应用程序解析过程中获得的结果,确定应用程序使用的、可能包含可访问的管理接口的Web服务器与其他技术。
2、对Web服务器进行端口扫描,确定在指向主目标应用程序的不同端口上运行的所有管理接口
3、对于确定的接口,查阅制造商文档资料与常用默认密码表,获得默认证书
4、如果默认证书无效,尝试猜测有效的证书
5、如果能够访问管理接口,审查可用的功能,确定是否可以利用这项功能进一步攻破主机与主应用程序
3.2、测试默认内容
1、分析Nikto扫描结果,确定服务器上存在的、但并不属于应用程序的默认内容
2、使用搜索引擎与其他资源确定已知应用程序所使用的技术的默认内容与功能。如有可能,在本地安装这些技术,并在其中在找可在渗志测试中利用的所有默认功能
3、检查默认内容,从中在找任何可用于攻击服务器或应用程序的功能或漏洞
3.3、测试危险的HTTP方法
1、使用OPTIONS方法列出服务器使用的HTTP方法。注意不同目录中激活的方法可能各不相同。可以使用Paros进行漏洞扫描,帮助完成这个检查
2、手动测试每一种方法,确认其是否可用
3、如果发现一些WebDAV方法被激活,使用一个激活WebDAV的客户端进行深入调查,如
Microsoft FrontPage等中的Open as Web Folder(以Web文件夹打开)选项
3.4、测试代理功能
1、使用GET与CONNECT请求,尝试使用Web服务器作为代理服务器,连接因特网上的其他服务器,并获取其中的内容
2、尝试使用连接主机基础架构中的不同IP地址与端口
3、尝试在请求中指定127.0.0.1为目标主机,连接Web服务器上的常用端口号
3.5、测试虚拟主机配置不当
1、使用以下方式向根目录提交GET请求
正确的Host消息头、恶意Host消息头、Host消息头中的服务器IP地址、无Host消息头
2、比较对这些请求的响应,常见的结果是,在Host消息头中使用服务器的IP地址获得目录列表,还可以获得各种默认内容
3、如果观测到应用程序表现出不同的行为,使用生成不同结果的主机名称重复应用程序解析过程。一定要使用-vhost选项进行一次Nikto扫描,确定在最初的应用程序解析过程中忽略的默认内容
3.6、测试Web服务器软件漏洞
1、使用Nessus与所拥有的所有其他类似的扫描器,确定所测试的Web服务器软件中存在的所有已知漏洞
2、同时浏览Security Focus 、Bugtraq和FulIDisclosure等资源,在攻击目标中查找最近发现的、尚未修复的漏洞信息
3、如果应用程序由第三方开发,确定它是否自带Web服务器(通常为一个开源服务器),如果是,在这个服务器中查找所有漏洞。在这种情况下,服务器的标准版本信息可能已被修改
4、如有可能,应该考虑在本地安装所测试的软件,并自已进行测试,查找尚未发现或广泛流传的新漏洞
3.7、测试Web应用程序防火墙
1、在参数值中使用明确的攻击有效载荷向应用程序(最好是响应中包含名称和成值的某个应用程序位置)提交任意参数名称,如果应用程序阻止该攻击,这可能是由于外部防御机制所致
2、如果可以提交在服务器响应中返回的变量,则提供一系列模糊测试字符串及这些字符串的编码形式可以确定应用程序的用户输入防御行为
3、对应用程序中的变量实施相同的攻击来确认这一行为
4、对于所有模糊测试字符串和请求,使用标准签名数据库中不可能存在的有效载荷字符串,根据定义,不可能提供这些字符串的示例。但在进行文件检索时,应避免将/etc/passwd或/windows/system32/coofig/sam作为有效载荷。此外应在XSS攻击中避免使用<script>并避免将alert()或xss用作XSS有效载荷
5、如果特定请求被阻止,可以尝试在其他位置或上下文中提交相同的参数。如在GET请求的URL中、在POST请求主体中,以及在POST请求的URL中提交相同的参数
6、此外应尝试在ASP.NET上将参数作为cookie提交,如果在查询字符串或消息主体中找不到参数foo,API Request.Params["foo"]会检索名为foo的cookie的值
7、引入用户输入的所有其他方法,选择其中任何不受保护的方法
8、确定以非标准格式(如序列化或编码)或可能以此类格式提交用户输入的位置。如果找不到此类位置,可以通过串联字符串和/或将字符串分布到多个参数中来构建攻击字符串(如果目标是ASP.NET可以使用HPP通过同一变量的各种变体来串联攻击字符串)
四、其他检查
4.1、测试基于DOM的攻击
1、对应用程序中包含的每一段JavaScript脚本进行简单的代码审查,确定可通过任何一个专门设计的URL、在相关页面的DOM中引入恶意数据而触发的XSS或重定向漏洞,审查内容包括HTML页面(无论静态或动态生成的页面)中的所有单独的JavaScrip,文件和脚本
2、确定使用API的所有情况,使用API可访问通过一个专门设计的URL控制的DOM数据
document.location
document.URL
document.URLUnencoded
document.referer
window.location
3、在代码中追踪相关数据,确定应用程序对它执行何种橾作,如果数据(或它的一个被操纵的表单)被提交给以下API中一个,那么应用程序可能易于受到XSS攻击
document.write()
document.writeln()
document.body.innerHtml()
eval()
window.execScript()
window.setInterval
window.setTimeout
4、如果数据被提交给下列API中的一个,那么应用程序可能易于受到重定向攻击
document.location
document.URL
document.open()
window.location.href
window.navigate()
window.open()
4.2、测试本地隐私漏洞
1、检查拦截代理服务器生成的日志,确定测试过程中应用程序送出的所有Set-Cookie指令,如果发现有任何Set-Cookie指令包含一个将来日期的expires属性用户的浏览器会将该cookie保持到这个日期,检查传送敏感数据的持久性cookie的所有内容
2、如果一个持久性cookie中包含敏感数据,那么本地攻击者就能够截获这些数据,即使这些数据被加密,截获它们的攻击者仍然可以将这个cookie重新提交给应用程序,访问该cookie访问的任何数据或功能
3、如果包含敏感数据的页面通过HTTP访问,在服务器响应中寻找缓存指令,如果其中没有下列指令(在HTTP消息头或HTML元标签中),那么相关页面可能被一个或几个浏览器存入缓存
Expires:0
Coche-control: no-cache
Pragam: no-cache
4、确定应用程序中通过URL参数传送敏感数据的所有情况,如果存在这样的情况,检查浏览器的历史记录,证实这些数据已经保存在那里
5、对于用户提交敏感数据(如信用卡信息)的所有表单,审查其中的HTML源代码,如果没有在表单标签或输入字段的标签中设置autocomplete=off属性,输入的数据将保存在激活自动完成的浏览器中
4.3、测试脆弱的SSL加密算法
1、如果应用程序使用SSL进行通信,使用THCSSLCheck工具列出它支持的加密算法和协议
2、如果SSL支持脆弱或过时的加密算法和协议,处在适当位置的攻击者就可以实施攻击,降级或破译应用程序用户的SSL通信,访问他们的敏感数据
3、一些Web服务器声称它支持某些脆弱加密算法和协议,但如果客户提出请求,它实际上拒绝使用这些算法和协议完成握手,在使用THCSSLCheck工具时,这种情况可能会造成错误警报。可以使用Opera浏览器,尝试通过指定的脆弱协议完成一次握手,确定是否可使用这些协议访问应用程序
4.4、检查同源策略配置
1、检查/crossdomain.xml文件,如果应用程序允许无限制访问(通过指定<allow-access-from domain="*" />) ,来自其他站点的Flash对象可以叠置应用程序用户的会话,以进行双向交互,这导致任何其他域可以检索所有数据,并执行任何用户操作
2、检查/clientaccesspolicy.xml文件,与Flash类似,如果<cross-domain-access>配置过于宽泛,其他站点将可以与接受测试的站点进行双向交互
3、通过添加指定其他域的Origin消息头并检查返回的任何Access-Control消息头、使用XMLHttpRequest测试应用程序如何处理跨域清求,允许任何域、或指定的其他域进行双向交互的安全隐患与Flash跨域策略造成的安全隐患相同
五、检查信息泄露
1、在探查目标应用程序的整个过程中,监控它的响应,在找可能包含与错误原因,所使用技术以及应用程序的内部结构与功能有关的错误消息
2、如果收到不常见的错误消息,使用标准的搜索引擎检查这些消息,可以使用各种高级搜索特性缩小搜索范围
3、检查搜索结果,寻找关于错误消息的所有讨论以及其他出现相同消息的所有站点。其他应用程序生成的同一条错误消息可能更详细,有助于更好地了解错误条件。使用搜索引擎缓存获取不再出现在当前应用程序中的错误消息
4、使用Google代码搜索查找生成特定错误消息的、公开发布的所有代码,搜索可能被硬编码到应用程序源代码中的错误消息代码段,还可以使用各种高级搜索特性指定代码语言及其他已知的细节
5、如果获得包含库与第三方代码组件名称的栈追踪错误消息,在搜索引擎中搜索这些名称