WEB应用程序渗透测试方法论

指导思想：方法论中一系列任务根据他们之间的逻辑依赖关系组织和排序。实际上，渗透测试过程往往需要发挥自己的想象，思考可采取的攻击方向，并根据所发现的有关目标应用程序的信息指导攻击方向。

某一个阶段收集到的信息有助于返回到 前一个阶段，以设计更具有针对性的攻击。

在应用程序的某个区域发现的一个关键漏洞可简化对另一个区域的攻击。

一些区域的测试结果有助于确定在其他区域可立即探查出的重复出现的漏洞模式。

一般规范：适用于所有必须测试的区域以及需要采用的各种技巧

假设需要在咨询工作中采用这种方法，渗透测试员应当首先确定测试范围，明确了解测试包含的主机名、URL与功能以及允许执行的测试类型是否存在任何限制。还应当向应用程序所有者告知对一个“黑盒”目标实施任何渗透测试包含的内在风险，并建议他们在开始测试前备份所有重要数据。

• 一些字符在HTTP请求（HTTP请求头）的不同部分具有特殊的含义。应对这些字符进行URL编码，以确保应用程序按照想要的方式解释这些字符。
• &用于分隔URL查询字符串与消息主体中的参数。要插入一个&字符，必须将其编码为%26.
• =用于分隔URL查询字符串与消息主体中每个参数的名称和值。要插入一个字面量=字符，必须将其编码为%3d.
• ?用于标记URL查询字符串的起始位置。要插入一个字面量？字符，必须将其编码为%3f。
• 空格用于在请求的第一行标记URL的结束位置，并可用于在cookie消息头中表示一个cookie值结束。要插入一个字面变量空格字符，必须将其编码为%20或+。
• +表示一个编码的空格，要插入一个字面量+字符，必须将其编码为%2b
• ;用于在cookie消息头中分隔单个cookie。要插入一个字面量;字符，必须将其编码为%3b
• #用于在URL中标记片段标识符。如果在浏览器的URL中输入这个字符，它会传给服务器的URL截短。要插入一个字面量#字符，必须将其编码为%23。
• %在URL编码方案中作为前缀。要插入一个字面量%字符，必须将其编码为%25。
• 空字节和换行符等，非打印字符必须使用他们的ASCII字符代码进行URL编码。空字节和换行符的编码分别为%00和%0a。

2. 表单中输入URL编码的数据通常会导致浏览器执行另一层编码。例如，在表单中提交%00可能会导致向服务器发送值%2500。为此，通常最好在拦截代理服务器中查看最终请求。

3. 许多查找常见Web应用程序的测试需要发送各种专门设计的输入字符串，并监控应用程序响应，从中搜索表示漏洞存在的反常现象。判断漏洞存在不应仅判断正向特征，还应包含反向特征比对多角度确认，有时候，无论是否提交某个特定漏洞的触发器，应用程序对一个特殊请求的响应都将包含这个漏洞的签名。只要提交专门设计的特殊输入导致了与某个漏洞相关的行为（如一个特殊的错误消息），应该重新核查，确定在相关参数中提交良性输入是否也会造成相同的行为。

4. 前一个请求数据的返回状态会对接下来的请求以及返回造成影响。有时，当调查一个尚未确定的漏洞并隔离某一个反常行为的根源时，必须避免任何收集到的状态信息造成的影响。通常，使用一个新的浏览器进程开始另一个会话，再使用良性请求导航至观测到发生反常的位置，然后重新提交专门设计的输入，即可。还可以对请求中包含的cookie和缓存信息进行调整，重复利用这种方法。此外，还可以使用burp reqeater等工具隔离一个请求。

5. 一些应用程序使用一种负载平衡的配置，其中连续的HTTP请求可能会被不同的后端服务器在Web层，展现层，数据层或其它层处理。不同服务器在配置上的细微差异可能会影响到处理结果。另外，一些成功的攻击将改变处理请求的某一台服务器的状态，例如在web根目录上创建一个新的文件。为隔离特殊操作造成的影响，可能需要连续提交几个相同的请求，测试每个请求的结果，直到请求被相关服务器处理。

1. 解析应用程序内容

1.1 搜索可见的内容

• 1. 配置浏览器。BURP、webscarab监控抓包。
• 2. 如果有用，配置浏览器，使用一个扩展监控和分析被浏览器处理的HTTP与HTML内容。
  • burp
• 3. 以常规方式浏览整个应用程序，访问发现的每一个连接和URL,提交每一个表单并执行全部多阶段功能。尝试在JS激活与禁用，Cookie激活与禁用情况下浏览。许多应用程序能够处理各种浏览器配置，渗透测试员可以获得应用程序内的不同内容和代码路径。
• 4. 如果应用程序使用身份验证，并且渗透测试员已经拥有或可以建立一个登陆账户，那么他应具有账户访问保护功能。
• 5. 当浏览、监控通过拦截代理服务器的请求与响应时，了解被提交的数据种类，了解客户端如何控制服务器端应用程序的行为。
• 6. 检查被动抓取生成的站点地图，确定任何尚未使用浏览器访问到的内容或功能。根据抓取结果，确定发现每一项内容的位置。使用浏览器访问以上内容，以便爬虫解析服务器的响应，确定其他任何内容。重复执行上述步骤，知道无法确定其他内容或功能。
• 7. 完成手动浏览和被动抓取后，可以用一组发现的URL作为种子，使用爬虫抓取应用程序。有时，这样可发现其他在手动浏览时忽略的内容。在进行自动抓取前，首先应确定任何危险的或可能会中断应用程序会话的URL，并配置爬虫，将他们排除在抓取范围之外。

1.2 浏览公共资源

• 1. 使用因特网搜索引擎和历史档案确定他们编入索引或保存与目标应用程序有关的内容。
• 2. 使用高级搜索选项提高搜索的效率。例如，在Google中，可以使用site:获取所有与目标站点有关的内容；使用link：获取连接到目标站点的其他站点。如果搜索过程中找到现有应用程序已经删除的内容，仍然可以从搜索引擎的缓存中查看这些内容。这些已被删除的内容中可能包含尚未删除的其他资源的连接。
• 3. 搜索在应用程序内容，【如联系信息，姓名，身份证号，邮件，地址】。除web搜索外还应进行新闻和分组搜索。在论坛中寻找与目标应用程序及其支持基础架构有关的所有技术信息。
• 4. 检查已发布的任何WSDL(web服务描述性语言)文件，以生成应用程序可能采用的功能名称和参数值列表。

1.3 发现隐藏的内容

• 1. 确定应用程序如何处理访问不存在的资源请求。手动提出请求，访问一致有效和无效的资源，比较应用程序对这些请求的响应，找到确定资源不存在的简单方法。
• 2. 获取常见文件与目录名以及常见的文件扩展名列表。根据存在的名猜测推测可能存在的页面。
• 3. 审查所有客户端代码，确定任何与服务器端内容（包括html注释和禁用的表单元素）有关的线索。
• 4. 使用自动化技巧，根据目录名，文件名以及文件扩展名列表大量请求，监控应用的响应，确定存在的可访问的内容。
• 5. 以枚举内容和模式作为用户指导的抓取以及自动化深入搜索的基础，重复进行内容查找。

1.4 查找默认的内容

• 1. 针对web服务器运行nikto，探查所有默认或抑制存在的内容。使用nikto的选项提高探查效率。例如，使用-root选项制定查找默认内容的目录，或者使用-404选项指定一个标识定制化“文件未发现”页面的字符串。
• 2. 手动核查所有可能有用的发现，减少探查结果中的错误警报。
• 3. 请求服务器的根目录，在host消息头中指定IP地址，确定应用程序是否使用任何不同的内容作出响应。如果是，则针对该IP地址及服务器名称运行Nikto扫描。
• 4. 向服务器的根目录提出请求，指定一系列User-Agent消息头。

1.5 枚举标识符指定的功能

• 1. 确定任何通过在请求参数中提交一个功能标识符，访问特殊应用程序功能的情况。传参的参数进行猜测确定。
• 2. 对用于访问单项功能的机制，应用内容查找技巧。例如，如果应用程序使用一个包含功能名称的参数，首先应该确定指定无效功能时应用程序的行为，设法找到一个确定被请求的功能缺失有效的简单方法。列出常用的功能名称或遍历所使用的标识符的语法范围。使枚举有效功能的操作自动化，使其尽可能迅速高效地完成。
• 3. 如果适用，根据功能路径而非URL编制一副应用程序内容地图，列出所有枚举出的功能和逻辑路径以及他们之间的依赖关系。

1.6 调试参数

• 1. 选择一个或几个使用隐藏调试参数（如debug=true)的应用程序页面功能。他们最有可能出现在登录、搜索、文件上传或下载等关键功能中。
• 2. 使用常用调试参数名（如debug、test、hide和source）与常用参数值（如true、yes、on和1）列表，排出这些名称与值的全部组合，向每一个目标功能提交每个名称参数值对。对于POST请求，在URL查询字符串和请求主体中提交参数。Burp Intruder可以实现自动化。
• 3. 在应用程序的响应中查找任何表示添加的参数对应用程序的行为造成影响的反常现象。

2. 分析应用程序

2.1 确定功能

• 1. 确定为使应用程序正常运行而建立的核心功能以及每项功能旨在执行的操作。
• 2. 确定应用程序采用的核心安全机制以及他们的工作机制。重点了解处理身份验证、会话管理与访问控制的关键机制以及支持他们的功能，如用户注册和账户恢复。
• 3. 确定所有较为外围的功能和行为，如重定向使用、站外链接、错误消息、管理与日志功能。
• 4. 确定任何与应用程序在其他地方使用的标准GUI外观、参数命名或导航机制不一致的功能。然后将其挑选出来以进行深入测试。

2.2 确定数据进入点

• 1. 确定在应用程序中引入用户输入的所有进入点，包括URL/查询子字符串参数、POST数据、cookie与其他由应用程序处理的HTTP消息头。
• 2. 分析应用程序使用的所有定制数据传输或编码机制，如非常规的检查字符串格式。了解被提交的数据是否包含参数名或参数值，或者是否使用了其他表示方法。
• 3. 确定所有在应用程序中引入用户可控制或其他第三方数据的带外通道，例如，处理和显示通过SMTP收到的消息的Web邮件应用程序。

2.3 确定所使用的技术

• 1. 确定客户端使用的各种不同技术，如表单、脚本、cookie、java applet、activeX空间与Flash对象。
• 2. 尽可能确定服务器端使用的技术，包括脚本语言，应用程序平台以及与数据库和电子邮件系统等后端组件的交互。
• 3. 检查在应用程序响应中返回的HTTP server消息头，查找指定HTTP消息头或HTML源代码注释中出现的其他任何软件标识符。注意，有时候，不同的应用程序区域由不同的后端组件处理，因此渗透测试员可能会受到不同的标识符。
• 4. 运行Httprint工具，为web服务器做“指纹标识”。
• 5. 检查内容解析过程中获得的结果，确定所有有助于了解服务器端所使用的技术的文件扩展名、目录或其它URL序列。检查所有会话令牌和其他cookie的名称。同时，使用Coogle搜索与这些内容有关的技术。
• 6. 确定任何看似有用的、属于第三方代码组建的脚本名称与查询字符串参数。在Google中使用inurl:限定词搜索这些内容，查找所有适用相同脚本与参数、并因此使用相同第三方组件的应用程序。对这些站点进行非入侵式的审查，这样可能会发现其他在攻击的应用程序中没有明确连接的内容和功能。

2.4 解析受攻击面

• 1. 设法确定服务器端应用程序的内部结构与功能以及用于实现客户端可见行为的后台机制。例如，获取客户订单的功能可能与数据库进行交互。
• 2. 确定各种与每一项功能有关的常见漏洞。例如，文件上传功能可能易于受到目录遍历攻击；用户通信可能受到XSS攻击；联络我们功能可能易于受到SMTP注入 攻击。
• 3. 制定一个攻击计划，优先考虑最有用的功能以及与他有关的最严重的潜在漏洞。使用这份计划作为指导，决定应对本章讨论的方法的其他区域投入多少时间和精力。

3. 测试客户端控件

3.1 通过客户端传送数据

• 1. 在应用程序中，确定隐藏表单字段、cookie和URL参数明显用于通过客户端传送数据的所有情况。
• 2. 根据以上数据出现的位置及其名称与值，尝试确定它在应用程序逻辑中发挥的作用。
• 3. 修改数据在应用程序相关功能中的值。确定应用程序是否处理字段中提交的任意值，以及是否可以通过这样做干扰应用程序的逻辑或破坏任何安全控件。
• 4. 如果应用程序通过客户端传送模糊数据，渗透测试员可以以各种方式攻击这种传输机制。如果数据被模糊处理，渗透测试员可以破译所使用的模糊算法，从而在模糊数据中提交任意数据。即使它进行了安全加密，仍然可以在其他情况下重新提交这个数据，干扰应用程序的逻辑。
• 5. 如果应用程序使用ASP.NET ViewState,对其进行测试，确定是否可以破坏它，或者其中是否包含任何敏感信息。注意，不同应用程序页面使用viewstate的方式可能有所不同。
  • a. 使用BurpSuit中的ViewState分析器确定EnableViewStateMac选项是否被激活该选项表示ViewState的内容不能被修改。
  • b.审查解码后的ViewState，确定它包含的所有敏感数据。
  • c. 修改一个被解码的参数值，重新对其编码，然后将它提交给ViewState。如果应用程序接受修改后的参数值，那么应当把ViewState当做在应用程序中引入任意数据的一个输入渠道，并对它包含的数据执行与其他请求参数相同的测试。

3.2 客户端输入控件

• 1. 在将用户输入提交给服务器之前，确定使用长度限制和JS检查等客户端控件对其进行确认的任何情况。当然，这些客户端控件可悲轻易避开，因为渗透测试员可以向服务器发送任意请求。
• 2. 通过提交通常被客户端控件阻止的输入，轮流测试每一个受影响的字段，确定服务器是否使用相同的输入确认。
• 3. 能够避开客户端确认并不表示存在任何漏洞。因此，应该仔细审查应用程序实施的确认机制，弄清应用程序是否依赖客户端控件保护自身，防止畸形输入，以及这些输入是否可触发任何可被利用的条件。
• 4. 检查每一个HTML表单，确定所有禁用的元素，如灰色提交按钮，例如：。 如果发现任何禁用的元素，就与其他表单参数一起提交这些元素，确定该元素是否会对应用程序的处理逻辑造成影响，渗透测试员可在攻击过程中利用这些影响。或者使用自动糊代理服务器规则，自动启用禁用的字段，如BurpProxy的Response Modification“HTML修改”规则Unhide hidden form fields。

3.3 测试浏览器扩展组件

• 3.3.1 了解客户端应用程序的操作

  • 1. 为正在测试的客户端技术设置一个本地拦截代理服务器，并监视客户端与服务器之间的所有流量。如果数据被序列化，可以使用反序列化工具，如Burp内置的AMF支持工具或用于Java的DSerBrup插件。
  • 2. 浏览在客户端中呈现的所有功能。使用拦截代理服务器中的表针工具重新提出关键请求或修改服务器响应，以确定任何可能的米肝功能或强大功能。

• 3.3.2 反编译客户端

  • 1. 确定应用程序使用的任何applet。通过拦截代理服务器查找一下请求的任何文件类型：.class/.jar对应JAVA；.swf对应Flash；.xap对应Silverlight。 还可以在应用程序页面的HTML源代码中查找applet标签。例如：<.applet>
       2. 分析HTML源代码对applet方法的全部调用情况，并确定applet返回的数据是否被提交到服务器。如果这个数据为模糊数据（即经过模糊处理或加密），那么想要对其进行修改，可能需要反编译applet，获得它的源代码。
       3. 在浏览器中输入URL，下载applet字节码，并将文件保存在本地计算机中。字节码文件的名称在applet标签的code属性中指定，该文件将位于codebase属性（如果此属性存在）指定的目录中；否则，它将保存在applet标签出现的页面所在的目录中。
       4. 使用适当的工具将字节码反编译成源代码。例如：c:>jad.exe input.class

       • 以下是一些适用于反编译不同浏览器扩展组件的工具
       • java—-jad
       • flash—swfscan,flasm/flare
       • silerlight—.net reflector
       • 如果applet被压缩成jar,xap或swf文件，可以使用winrar或winzip等解压缩。
       5. 分析相关源代码（从执行返回模糊数据的方法的源代码开始），了解应用程序执行了何种处理
       6. 确定applet中是否包含任何可用于对任意输入进行相关模糊处理的公共方法。
       7. 如果其中没有这类方法，修改applet的源代码，以达到领其执行的任何确认失效或允许模糊处理任意输入的目的。然后可以使用供应商提供的编译工具将源代码重新编译成最初的文件格式。

       3.3.3 附加调试器

       • 1. 对于大型客户端应用程序，要反编译、并修改并重新打包整个应用程序旺旺非常困难，这时会遇到各种错误。通常，对于这些应用程序，在处理时附加运行时调试器会更加容易。JavaSnoop可对Java应用程序执行上述操作。Silverlight Spy是一款免费工具，可对silverlight客户端进行运行时监视。
       • 2. 找到应用程序用于实现安全相关的业务逻辑的关键功能和值，并在调用目标功能时放置断点。根据需要修改参数或返回值，以破坏其安全防御。

       3.3.4 测试ActiveX控件

       • 1. 确定应用程序使用的所有ActiveX控件。寻找通过拦截代理服务器请求的所有.cab文件类型，或者在应用程序页面的HTML源代码中虚招对象标签。例如
       • 2. 通常，可以通过在进程上附加调试器并直接修改被处理的数据，或者改编程序的执行路径，破坏ActiveX控件实施的所有输入确认。
       • 3. 可以根据ActiveX控件导出各种方法的名称以及提交给他们的参数，猜测这些方法的作用。使用COMRaider工具可枚举出ActiveX控件导出的各种方法。测试是否可以操纵这些方法，从而影响控件的行为并避开它执行的所有确认机制。
       • 4. 如果控件的作用是收集或核实某些与客户端计算机有关的信息，就可以使用Filemon与Regmon工具监控控件收集到的信息。通常，可以在系统注册表和文件系统中穿件适当的数据项，修改控件使用的输入，从而影响其行为。
       • 5. 在任何ActiveX控件中探查可用于攻击应用程序其他用户的漏洞。渗透测试者可以修改用于调用控件的HTML代码，向它的方法提交任意数据，并监控处理结果；可以寻找看似危险的方法名，如LaunchExe,还可以使用COMRaider对ActiveX控件进行基本的模糊测试，确定缓冲区溢出之类的漏洞。

       3.4 测试验证机制

       • 3.4.1 了解验证机制

         • 1. 确定应用程序使用的验证技术（如表单、证书或多元机制）。
         • 2. 确定所有与验证有关的功能（如登录、注册、账户恢复等）。
         • 3. 如果应用程序并未采用自动自我注册机制，确定是否可以使用任何其他方法获得几个用户账户。

       • 3.4.2 测试密码强度

         • 1. 在应用程序中查找有关用户密码最小强度规则的说明。
         • 2. 尝试使用所有自我注册或密码修改功能，设定各种脆弱密码，确定应用程序实际应用的密码强度规则。尝试使用短密码、仅包含字母字符的密码、全部大写或者全部小写字符的密码、单词型密码以及将当前用户名作为密码。
         • 3. 测试不完整的证书确认。设定一个强大并且复杂的密码（例如，密码长度为12个字符，其中包含大小写字母、数字和印刷字符）。尝试用这个密码的各种变化形式登录，如删除最后一个字符，改变字符的大小写，或者删除任何特殊字符。如果其中一些常识取得成功，继续系统性的尝试，了解完整的证书确认过程。
         • 4. 了解最小密码强度规则以及密码确认的程度后，再设法确定密码猜测攻击所需要使用的密码值范围，以提高攻击成功的可能性。尝试找出所有的内置账户，他们可能并不满足标准密码复杂度要求。

       • 3.4.3 测试用户名枚举

         • 1. 确定各种验证功能通过在屏幕上显示的输入字段、隐藏表单字段或者cookie提交用户名的每一个位置。这些位置通常存在于登录、注册、密码修改、退出与账户恢复功能中。
         • 2. 向每个位置提交两个请求，齐总分别包含一个有效和一个无效的用户名。分析服务器对每一个请求的响应的各方面细节，包括HTTP状态码、任何重定向、屏幕上显示的信息、任何隐藏在HTML页面源代码中的差异以及服务器作出影响的时间。请注意，其中一些差异可能极其细微，有必要的话可以通过对比进行差异对比。
         • 3. 如果从提交有效和无效用户名返回的响应中发现任何差异，那么使用另外一组用户名重复进行测试，确定响应之间是否存在相同模式的差异，以此作为自动化用户名枚举的基础。
         • 4. 检查应用程序中任何其他科帮助获得一组有效用户名的信息泄露源，例如，日志功能、注册用户列表以及在源代码主时钟直接提及姓名或电子邮件地址的情况。
         • 5. 定位任何接收用户名的附属验证机制，并确定是否可以将其用于用户名枚举。特别注意允许指定用户名的注册页面。

       • 3.4.4 测试密码猜测的适应性

         • 1. 确定应用程序提交用户证书的每一个位置。通常，用户主要在主登录功能和密码修改功能中提交证书。如果用户可提交任意用户名，密码修改功能才会成为密码猜测攻击的有效目标。
         • 2. 在每一个位置，使用一个受控制的账户手动提出几个包含有效用户名但证书无效的请求。监控应用程序的响应，确定他们之间的所有差异。如果应用程序经过大约10次登录失败后还没有返回任何有关账户锁定的消息，在提交一个包含有效证书的请求。如果这个请求登录成功，应用程序可能并未采取任何账户锁定策略。
         • 3. 如果没有控制任何账户，那么尝试枚举或猜测一个有效的用户名，并使用他提交几个无效的请求，监控任何有关账户锁定的错误消息。当然，应该意识到，这种测试可能会导致其他用户的账户被冻结或禁用。

       • 3.4.5 测试账户恢复功能

         • 1. 确定如果用户忘记他们的证书，应用程序是否允许他们重新控制自己的账户。通常，在朱登录功能附近有一个”忘记密码”连接即表示应用程序采用了密码恢复功能。
         • 2. 使用一个受控制的账户完成整个密码恢复过程，了解账户恢复功能的运作机制。
         • 3. 如果该功能使用机密问题之类的质询，确定用户是否可以在注册时设定或选择他们自己的质询。如果可以，使用一组枚举处的或常见的用户名获取一组质询，并对其分析，找出任何很容易猜测出答案的质询。
         • 4. 如果该功能使用密码“暗示”,采取和上一个步骤相同的操作获得一组密码暗示，确定任何可轻易猜测出答案的暗示。
         • 5. 对账户恢复质询进行与主登录功能相同的测试，确定可对其实施自动猜测攻击的漏洞。
         • 6. 如果该功能要求向用户发送一封电子邮件才能完成整个恢复过程，寻找任何可帮助控制其他用户账户的弱点。确定是否有可能控制接收以上电子邮件的地址。如果邮件内容包含一个唯一的恢复URL，使用受控制的一个电子邮件地址获得若干邮件，尝试确定任何可帮助预测发布给其他用户的URL模式。

       • 3.4.6 测试“记住我”功能

         • 1. 如果主登录功能或它的支持逻辑包括“记住我”功能，激活这项功能并分析它的作用。如果该功能允许用户随后不输入任何证书即可登录，那么应该仔细分析这项功能，查找其中存在的所有漏洞。
         • 2. 仔细检查激活“记住我”，功能时设定的所有持久性cookie。寻找任何明确标识出用户身份或明显包含可预测的用户标识符的数据。
         • 3. 即使其中保存的数据经过严密编码或模糊处理，也要仔细分析这些数据，并比较“记住”几个非常类似的用户名和密码的结果，找到任何可对原始数据进行逆向工程的机会。
         • 4. 根据以上结果，适当修改cookie的内容，尝试伪装成其他应用程序用户。

       • 3.4.7 测试伪装功能

         • 1. 如果应用程序包含任何明确的功能，允许一名用户伪装成另一名用户，那么仔细审查这项功能，查找所有允许未经正确授权即可伪装成任意用户的漏洞。
         • 2. 寻找所有用户提交的、用于确定伪装目标的数据。尝试修改这个数据，伪装成其他用户，特别是可帮助提升权限的管理用户。
         • 3. 当针对其他用户账户试试自动密码猜测攻击时，寻找所有明显使用多个有效密码的账户，或者几个使用相同密码的账户。这表示应用程序提供后门密码，一边管理员使用它时以任何用户的身份访问应用程序。

       • 3.4.8 测试用户名唯一性

         • 1. 如果应用程序提供注册功能，允许指定想要的用户名，那么尝试使用不同的密码注册同一个用户名。
         • 2. 如果应用程序阻止第二个注册尝试，就可以利用此策略枚举出已注册的用户名。
         • 3. 如果应用程序注册以上两个账户，深入分析这种情况，确定用户名与密码发生冲突时应用程序的行为。尝试修改一个账户的密码，使其与另一个密码相同。同事，尝试使用完全相同的用户名与密码注册两个账户。
         • 4. 如果在用户名与密码发生冲突时，应用程序发出警报或产生错误，就可以利用自动化攻击，确定其他用户的密码。针对一个枚举出的或猜测到的用户名，尝试使用这个用户名与不同的密码创建账户。应用程序拒绝某个特殊的密码即表示它可能是目标账户的现有密码。
         • 5. 如果应用程序接收相互冲突的用户名与密码，并且不产生错误，那么使用相互冲突的证书登录，确定应用程序的行为，以及是否可以利用这种行为不经授权即可访问其他用户账户。

       • 3.4.9 测试证书的可预测性

         • 1. 如果用户名或密码由应用程序自动生成，设法获得几个紧密相连的用户名或密码，确定任何可探测的顺序或模式。
         • 2. 如果用户名以可预测的方式生成，那么向后推导，获得一组可能有效的用户名。这些用户名可作为自动密码猜测与其他攻击的基础。
         • 3. 如果密码以可预测的方式生成，那么推导这种模式，获取应用程序向其他用户发布的一组密码。渗透测试员可以将这些密码与获得的用户名进行组合，实施密码猜测攻击。

       • 3.4.10 检测不安全的证书传输

         • 1. 遍历所有需要传输证书、与验证有关的功能，包括主登录功能、账户注册功能、密码修改功能以及允许查看或更新用户个人信息的页面。使用拦截代理服务器监控客户端与服务器之间的所有流量。
         • 2. 确定在来回方向传输证书的每一种情况。可以在拦截代理服务器中设置拦截规则，标记包含特殊字符串的消息。
         • 3, 如果证书在URL查询字符串中传输，那么这些证书可能会通过浏览器历史记录、屏幕、服务器日志以及Referer消息头泄露。
         • 4. 如果证书被保存在cookie中，可能会通过XSS攻击或本地隐私攻击泄露。
         • 5. 如果证书被从服务器传送回客户端，攻击者就可以利用会话管理或访问控制漏洞，或者通过XSS攻击获取这些证书。
         • 6. 如果证书通过未加密连接传输，他们很可能被窃听者拦截。
         • 7. 如果适用HTTPS提交证书，但适用HTTP加载登录表单，那么应用程序就容易遭受中间人的攻击，攻击者也可能适用这种攻击手段获取证书。

       • 3.4.11 检测不安全的证书分配

         • 1. 如果应用程序通过某种带外通道创建账户，或者它提供的注册功能本身并不决定用户使用的全部厨师证书，那么应该确定应用程序采用了什么方法向新用户分配证书。常用的方法包括发送电子邮件，或者向邮政地址寄送信件。
         • 2. 如果应用程序生成以带外方式分配的账户激活URL，尝试注册几个紧密相连的新账户，并确定收到的URL中的顺序。如果能确定某种模式，努力预测应用程序发送给最近与后续用户的URL，并尝试使用这些URL占用他们的账户。
         • 3. 尝试多次重复使用同一个激活URL，看看应用程序是否允许这样做。如果遭到拒绝，尝试在重复使用URL之前锁定目标账户，看看URL是否仍然可用。确定使用这种方法是否可以给一个已经激活的账户设定一个新密码。

       • 3.4.12 测试不安全的存储

         • 1. 如果可以访问散列密码，应检查共享同一散列密码值的账户。尝试以采用最常用的散列值的密码登录。
         • 2. 使用相关散列算法的离线彩虹表查找明文值。

       • 3.4.13 测试逻辑缺陷

         • 3.4.13.1 测试故障开放条件

           • 1. 对于要求应用程序检查用户证书的每一项功能（包括登录与密码修改功能），使用控制的账户以正常方式访问这些功能。注意他们提交给应用程序的每一个请求参数。
           • 2. 连续多次重复以上过程，以各种无法预料的方式轮流修改每一个参数，破坏应用程序逻辑。对每一个参数进行以下修改。
             • 提交一个空字符串值
             • 完全删除名/值对
             • 提交非常长和非常短的值
             • 提交字符串代替数字或提交数字代替字符串
             • 以相同和不同的值，多次提交同一个命名参数
           • 3. 检查应用程序对上述请求的响应。针对异常进行分析，并将各种异常行为触发方式进行混合组合。

         • 3..4.13.2 测试多阶段处理机制

           • 1. 如果任何与验证有关的功能需要在一系列不同的请求中提交证书，确定每一个阶段的主要目的，同事注意每一个阶段提交的参数。
           • 2. 连续多次重复以上过程，修改提交请求的顺序，破坏应用程序的逻辑。相关测试包括：
             • 以不同的顺序完成所有阶段，到达想要的那个阶段
             • 轮流直接进入每一阶段，然后按正常顺序访问后续步骤
             • 几次访问上述功能，轮流省略每一阶段，然后在后一个阶段继续按正常的顺序访问
             • 根据观察到的结果以及每个功能阶段的主要目的，尝试通过其他方式修改这些阶段的顺序，并访问开发者没有预料到的阶段
           • 3. 确定是否有任何一项信息（如用户名）在几个阶段被提交，或者是因为用户提交了他几次，或者是因为他通过客户端在隐藏表单字段，cookie或预先设置的查询字符串参数中传送。这时尝试在不同阶段提交不同的值（包括有效和无效值），并观察其后果。设法确定提交的数据是否是多余的，或者在一个阶段确认，随后即被应用程序新人，或者在不同的阶段通过不同的检查进行确认。尝试利用应用程序的行为获得未授权访问，或者降低多阶段机制实施的控制的效率。
           • 4. 查找所有通过客户端传送的数据。如果应用程序使用隐藏参数在各个功能阶段中追踪进程状态，那么攻击者可以修改这些参数，从而破坏应用程序的逻辑。
           • 5. 如果进程的任何部分要求应用程序采用一个随机变化的质询，对它进行测试，查找以下两种常见的缺陷。
             • a. 如果一个指定质询的参数与用户的响应一起提交，确定是否可以修改这个值，选择自己的质询。
             • b. 多次使用相同的用户名处理上述不断变化的质询，确定每次是否出现一个不同的质询。如果每次的质询各不相同，那么就可以重复进入这个阶段直到应用程序显示希望的质询，以这种方式选择想要的质询。

       • 3.4.14 利用漏洞获取未授权访问

         • 1. 分析在各种验证功能中发现的所有漏洞，确定所有可在攻击应用程序过程中用于实现自己的目标的漏洞。通常，这包括尝试以另一名用户的身份进行验证;如有可能，以拥有管理权限的用户身份验证。
         • 2. 在实施自动攻击之前，留意已经确定的所有账户锁定防御。例如，当对登录功能实施用户名枚举攻击时，在请求中提交一个常用的而不能完全随机的密码，以免在每一个发现的用户名上浪费一次登陆失败尝试。同样，应以广度优先而非深度优先的方式实施密码猜测攻击。首先使用单词列表中最常用的脆弱密码，然后使用其他值，对每一个美剧出的用户名实施密码猜测攻击。
         • 3. 构建在密码猜测攻击中使用的单词列表时，应考虑密码强度规则以及密码确认机制的完整性，避免使用不可能的或多余的测试密码值。
         • 4. 使用技巧尽可能多的自动攻击，提高速度和效率。

       3.5 测试会话管理机制

       • 3.5.1 了解会话管理机制

         • 1. 分析应用成用于管理会话与状态的机制。确定应用程序是否使用会话令牌或其他方法处理每一名用户提交的各种请求。请注意，用户通过验证后。一些验证技术（HTTP验证）并不需要使用完整的会话机制重新确认用户的身份。同时，一些应用程序采用一种无会话状态机制，通常使用一个加密或模糊处理的表单，通过客户端传送所有状态信息。
         • 2. 如果应用程序使用会话令牌，确定它到底使用哪些数据重新确认用户的身份。HTTP、cookie、查询字符串参数以及隐藏表单字段均可用于传送令牌。可使用不同的数据共同重新确认用户的身份，不同的数据可能被不同的后端组件使用。有时，看似为会话令牌的数据实际并未被应用程序使用。例如，web服务器生成的默认cookie。
         • 3. 为确定应用程序到底使用哪些数据作为令牌，找到一个确信依赖会话的页面（如某一名用户的“用户资料”页面）或功能，并向它提出几个请求，系统性地删除怀疑被用作令牌的数据项。如果删除某个数据项后，应用程序不再返回依赖会话的页面，即可确定该数据项为会话令牌。Burp Repeater是执行这些测试的有用工具。
         • 4. 确定应用程序使用哪些数据重新确认用户的身份后确定它是否对每个令牌进行完整的确认，或者是忽略令牌的某些组成部分。修改令牌的值，一次修改一字节，并确定修改后的值是否仍然被应用程序接受。如果发现令牌的某些部分并未被用于保持会话的状态，就不必再深入分析他们。

       • 3.5.2 测试令牌的含义

         • 1. 在不同时间几个不同的用户登录，记录服务器发布的令牌。如果应用程序允许注册，就可以选择自己的用户名，用一系列存在细微差别的相似用户名登录，如A、AAA、AAAB、AAAC等。如果其他与某一名用户有关的数据（如电子邮件地址）在登录阶段 提交或保存在用户资料中，对其进行与前面类似的系统化修改，并截获收到的令牌。
         • 2. 分析收到的令牌，查找所有与用户名和其他用户可控制的数据有关的内容。
         • 3. 分析令牌，查找所有明显的编码或模糊处理方案。查找用户名长度与令牌长度之间的所有相互关系；这种关系表示应用程序明显使用了某种模糊处理或编码方案。如果用户名包含一组相同的字符。在令牌中寻找表示可能适用XOR模糊处理的对应字符序列；在令牌中寻找仅包含十六进制字符的序列，他表示应用程序可能对ASCII字符串进行了十六进制编码处理，或者被披露其他信息。寻找以等号（=）结尾的字符序列或仅包含其他有效Base64字符的序列，如a-z，A-Z、0-9、+和/。
         • 4. 如果可以从会话令牌样本中获得任何有意义的数据，确定这些信息是否足以帮助发动攻击，猜测出最近发布给其他应用程序用户的令牌。找到一个依赖会话的应用程序页面，使用自动生成和测试可能的令牌。

       • 3.5.3 测试令牌的可预测性

         • 1. 使用一个可使服务器返回一个新令牌的请求（如一个成功登陆请求），生成并截获大量紧密相连的会话令牌。
         • 2. 设法确定令牌样本中的所有模式。在所有情况下，都应使用BurpSequtncer对应用程序的令牌的随机特性进行详细的系统测试。根据自动扫描结果，仍需进行手工分析。
           • 理解应用程序重新确认身份的令牌和子序列。忽略并未用于确定用户身份的所有数据，即使样本中的这些数据发生了变化。
           • 如果不清楚令牌或者令牌的所有组成成分使用何种类型的额数据，尝试使用各种解码方法（如base64），看能否得到更有意义的数据。有时可能有必要连续使用几种编码方法。
           • 设法确定解码后的令牌或组成成分数据中存在的所有模式。计算连续值之间的差距。即使这些值看似杂乱无章，但是他们之间仍然可能存在固定的差距，允许渗透测试员显著缩小蛮力攻击的范围。
           • 等待几分钟后，截取类似的一组令牌样本，重复进行上述分析。设法确定令牌的内容是否具有时间依赖性。
         • 3. 如果已经确定了所有模式，使用一个不同的IP地址与用户名截获另一组令牌样本，确定是否可以探查到相同的模式，或者是否可以对第一组令牌进行推导，猜测出第二组令牌。
         • 4. 如果能够确定可利用的序列或时间依赖关系，考虑这些信息是否足以帮助发动攻击，猜测出最近发布给其他应用程序用户的令牌。使用自动生成和测试可能的令牌。除最简单的序列外，可能需要在攻击中使用某些定制脚本。
         • 5. 如果会话ID似乎是定制编写的，可以使用BurpIntruder中的“位翻转”有效载荷源继续轮流修改会话令牌中的每个位。同时，在响应中查找表明修改令牌是否会导致会话无效，或会话是否属于其他用户的字符串。

       • 3.5.4 检查不安全的令牌传输

         • 1. 以正常方式访问应用程序，从“起始”URL中的未通过验证的内容开始，到登录过程，再到应用程序的全部功能。留意发布新会话令牌的每一种情况，确定哪些部分使用了HTTP通信，哪些部分使用HTTPS通信。可以使用拦截代理查看。
         • 2. 如果应用程序使用HTTP cookie传送会话令牌，应确认其是否设置了安全标记，防止通过HTTP连接传送令牌。
         • 3. 在正常使用应用程序的情况下，确定会话令牌是否通过HTTP连接传送。如果是这样，他们就很容易被拦截。
         • 4. 如果应用程序在未通过验证的区域使用HTTP，然后在登陆或通过验证的区域转换到HTTPS，那么确认应用程序是否为HTTPS通信发布一个新的令牌，或者应用程序在转换到HTTPS后是否仍然使用HTTP阶段的令牌。如果是这样，它们很容易被拦截。
         • 5. 如果应用程序的HTTPS区域包含指向HTTP URL的链接，访问这些链接，确认在访问过程中是否有会话令牌被提交；如果是这样，令牌或者继续有效，或者立即被服务器终止。

       • 3.5.5 检查在日志中泄露的令牌

         • 1. 如果在应用程序解析过程中能确定任何日志、监控或诊断功能，应仔细检查这些功能，确定他们是否泄露任何会话令牌。确定在正常情况下那些人有权访问这些功能；如果只有管理员能够使用这些功能，那么确认低权限用户是否可以利用任何其他漏洞访问他们。
         • 2. 确定所有在URL中传送会话令牌的情况。可能应用程序通常以更加安全的方式传送令牌，而开发这在特定情况下使用URL来解决特殊难题。如果是这样，当用户访问站外链接时，这些令牌将在Referer消息头中传递。确定所有允许在其他用户可查看的页面中插入任意站外链接的功能。
         • 3. 如果能够收集到发布给其他用户的有效会话令牌，就对每个令牌进行测试，确定他是否属于管理用户（例如，尝试使用令牌访问，某个特权功能）。

       • 3.5.6 测试令牌-会话映射

         • 1. 用同一个用户账户从不同的浏览器进程或从不同的计算机两次登录应用程序。确定这两个会话是否都处于活动状态。是就表示应用程序支持并行会话，可让攻破其他用户证书的攻击者能够利用这些证书，而不会有被检测出来的风险。
         • 2. 使用同一个用户账户从不同的浏览器进程或从不同的计算机登录并退出应用程序几次。确定应用程序在每次登录时是发布一个会话令牌，还是发布相同的令牌。如果每次发布相同的令牌，那么应用程序根本没有正确使用令牌，而是使用唯一持久性字符串重新确认用户身份。在这种情况下，应用程序就没有办法防止并行登录或正确事实会话超时。
         • 3. 如果令牌明显包含某种结构和意义，设法将表示用户身份的成分与无法辨别的成分区分开来。尝试修改与用户相关的所有令牌成分，使其指向其他已知的应用程序用户，并确定修改后的令牌是否被应用程序接受，以及能够让攻击者伪装成该用户。第七章细微漏洞示例。

       • 3.5.7 测试会话终止

         • 1. 当测试会话超时时与退出漏洞时，主要测试服务器如何处理会话令牌，而不是客户端发生的任何事件。在客户端浏览器内对令牌之星的操作并不能终止会话。
         • 2. 检查服务器是否执行会话终止。
           • 登录应用程序获得一个有效令牌。
           • 不适用这个令牌，等待一段时间后，用这个令牌提交一个访问受保护页面（如：“我的资料”页面）的请求。
           • 如果该页面正常显示，那么令牌仍然处于活动状态。
           • 使用反复测试的方法确定会话终止超时时间为多久，或者一个令牌在前一次使用它提交请求几天后是否仍被使用。可配置BurpIntruder递增连续请求之间的时间间隔，自动完成这项任务。
         • 3. 检查退出功能是否存在。如果应用程序使用退出功能，测试它是否能够在服务器上有效确认用户的会话。退出后，尝试重新使用原有的令牌，使用它请求一个受保护的页面，确定其是否仍然有效。如果令牌仍然有效，那么及时用户已经“退出”，他们仍然易于受到会话劫持攻击。可以使用Burp Repeater从代理历史记录中不断发送一个特殊的请求，观察退出后应用程序是否做出不同的响应。

       • 3.5.8 测试会话固定

         • 1. 如果应用程序向未通过验证的用户发布令牌，获取令牌并登陆。如果应用程序在登录后并不发布一个新令牌，就表示它易于受到会话固定攻击。
         • 2. 即使应用程序并不向未通过验证的用户发布令牌，也可通过登录获得一个令牌，然后返回登录页面。如果应用程序“愿意”返回这个页面，即使已经通过验证，也可使用相同的令牌以另一名用户的身份提交另一次登录。如果应用程序在第二次登陆后并不发布一个新令牌，就表示易于受到会话固定攻击。
         • 3. 确定应用程序会话令牌的格式。用一个捏造的、格式有效的值修改令牌，然后尝试使用它登录。如果应用程序允许使用一个捏造的令牌建立通过验证的会话，就表示它易于受到会话固定攻击。
         • 4. 如果应用程序并不支持登录功能，但处理敏感数据（如个人信息和支付细节），并

       • 3.5.9 检查CSRF

         • 1. 如果应用程序完全依靠HTTP cookie传送会话令牌，它很可能容易受到跨站点请求伪造(CSRF)的攻击。
         • 2. 分析应用程序的关键功能，确定用于执行敏感操作的特定请求。如果这些请求中的参数完全可由攻击者事先决定（也就是说，其中并不包含任何会话令牌、无法预测的数据或其他机密），那么几乎可以肯定应用程序易于受到攻击。
         • 3. 创建一个HTML页面，它不需要进行任何用户交互，即可提出想要的请求。对GET请求，可以使用一个标签，并通过对src参数设置易受攻击的URL。对于POST请求，可以建立一个表单，其中包含实施攻击所需全部相关参数的隐藏字段，并将其目标设为易受攻击的URL。可以使用JavaScript在页面加载时自动提交该表单。登录应用程序后，使用同一个浏览器加载前面创建的HTML页面。确认应用程序是否执行想要的操作。
         • 4. 如果应用程序为阻止CSRF攻击，在请求中使用其他令牌，则应以与测试会话令牌相同的方法测试这些令牌的可靠性。还应测试应用程序是否易于受到UI伪装攻击，以突破反CSRF防御。第13章。

       • 3.5.10 检查cookie范围

         • 1. 如果应用程序使用HTTP cookie传送会话令牌（或任何其他敏感数据），那么检查相关的Set-cookie消息头，寻找用于控制cookie范围的所有“城”或“路径”属性。
         • 2. 如果一个应用程序明确放宽它的cookie范围限制，将其设定为一个父域或父目录，那么攻击者可以通过以上父域或父目录中的其他Web应用程序向该应用程序发动攻击。
         • 3. 如果一个应用程序以它自己的域名为它的cookie域范文（或并未指定“域“属性），那么它仍然可能受到在子域上运行的应用程序的威胁。这是设定cookie范文造成的后果，只有不在安全敏感的应用程序的子域上运行其他应用程序，才能避免这种后果。
         • 4. 确定对按路径（如/site/main和/site/demo）隔离的任何依赖情况，跨站点脚本攻击能够破坏这种隔离。
         • 5. 确定所有可能收到应用程序发布的cookie的域名和路径。确定是否可通过这些域名或路径访问其他web应用程序，以及是否可利用他们获得发布给目标应用程序用户的cookie。

       3.6 测试访问控件

       • 3.6.1 了解访问控制要求

         • 1. 根据应用程序的核心能力，了解访问控制在垂直隔离（拥有不同权限的用户可访问不同类型的功能）与水平隔离（拥有相同权限的用户可访问不同的数据）方面的主要要求，通常，应用程序会使用两种权限隔离，例如，普通用户能够访问自己的数据，而管理员则能够访问每个用户的数据。
         • 2. 检查应用程序解析过程得到的结果，确定最可能成为权限提升攻击目标的功能区域与数据资源类型。
         • 3. 为提高测试访问控制漏洞的效率，渗透测试员应该获得大量拥有不同垂直权限与水平权限的账户。如果应用程序允许注册，渗透测试员就可以直接获得大量拥有不同水平权限的账户。为获得拥有不同垂直权限的账户，需要得到应用程序所有者的帮助（或利用某个漏洞访问一个高权限账户）。如后文所述，能否获得各种不同的账户将会对能够进行的测试产生直接影响。

       • 3.6.2 使用多个账户测试

         • 1. 如果应用程序实施垂直权限隔离，那么首先使用一个高权限账户确定它能访问的所有功能，然后再使用一个低权限账户尝试访问上述每一项功能。
           • a. 使用Burp在一个用户的权限下浏览应用程序的所有内容
           • b. 复查Burp的站点地图内容，确保已确定要测试的所有功能。然后，注销应用程序并使用另一个用户账户登录；使用上下文菜单选择“比较站点地图”（compare site maps）功能，确定较低权限的用户可以访问哪些高权限请求。参考第8章。
         • 2. 如果应用程序实施水平权限隔离，那么使用两个拥有相同权限的不同账户进行同等测试，尝试使用一个账户访问属于一个账户的数据。通常，这需要替换请求的一个标识符（如一个文档ID），以指定属于其他用户的资源。
         • 3. 手动检查关键访问控制逻辑。
           • 对于每个用户权限，反复用户可用的资源。尝试通过使用未授权用户的会话令牌，从未授权用户账户重新提交请求来访问这些资源。
         • 4. 进行访问控制测试时，一定要分别测试多阶段功能的每一个步骤，确定每一个阶段是否正确实施了访问控制；或者应用程序是否认为访问后一个阶段的用户一定通过了前面阶段实施的安全检查。例如，如果一个包含表单的管理页面收到恰当保护，检查提交表单的过程中是否同样实施了合理的访问控制。

       • 3.6.3 使用有限的权限测试

         • 1. 如果不能优先访问不同权限的账户，或者优先访问几个能够访问不同数据的账户，那么测试不完善的访问控制机制可能相当困难。由于并不知道利用各种缺陷所需的URL名称、标识符和参数，因此许多常见的漏洞将更加难以确定。
         • 2. 在使用地权限账户解析应用程序的过程中，渗透测试员可能已经确定了访问管理接口等特权功能的URL。如果这些功能没有得到充分保护，渗透测试员可能已经了解了这一点。
         • 3. 反编译现有的所有已编译客户端，并提取对服务器端功能的任何引用情况。
         • 4. 大多数收到水平访问控制保护的数据可使用一个标识符(如一个账号或订单号）访问。为了使用一个账户测试访问控制是否有效，需要尝试、猜测或发现与其他用户的数据有关的标识符。如有可能，生成一系列紧密相连的标识符（例如，通过建立几个新订单），尝试确定所有可帮助预测发布给其他用户的标识符的模式。如果无法生成新的标识符，就只能分析以确定的标识符，并根据这些标识符猜测其他标识符。
         • 5. 如果能够预测发布给其他用户的标识符，使用14章描述的技巧实施自动攻击，获取属于其他用户的有用数据。可使用Burp Intruder的Extract Grep功能从应用程序的响应中截获相关信息。

       • 3.6.4 测试不安全的访问控制的方法

         • 1. 一些应用程序根据请求参数以一种内在不安全的方式实施访问控制。在所有关键请求中寻找edit=false或access=read之类的参数，根据他们的主要作用修改这些参数，尝试破坏应用程序的访问控制逻辑。
         • 2. 一些应用程序根据HTTP Referer消息头作出访问控制决策。例如，一个应用程序可能对/admin.jsp实施严格的访问控制，并接收在Referer中显示它所有请求。为测试这种行为，尝试执行一些获得授权的特权操作，并提交一个其中缺少referer消息头或referer消息头被修改的请求。如果这种改变导致应用程序组织请求，应用程序很可能以不安全的方式使用Referer消息头。尝试使用一个未通过验证的用户账户执行相同的操作，但提交原始的referer消息头，看这时是否能够成功执行操作，
         • 3. 如果站点允许HEAD方法，则应测试针对URL的不安全的容器托管访问控制。使用HEAD方法提出请求，确定应用程序是否允许该方法。

       3.7 测试基于输入的漏洞

       • 3.7.1 模糊测试所有请求参数

         • 1. 检查应用程序解析过程中获得的结果，如果所有提交
         • 2. 要对这些参数进行模糊测试，可以使用自己的脚本，或者现成的模糊测试工具。例如，如果使用Burp Intruder，可轮流在工具中加载每一个请求。一个简单的方法是在Burp中使用Intruder功能。
         • 3. 使用“有效载荷”选项卡，配置一组适当的攻击有效载荷，在应用程序中探查漏洞。可以手动输入有效载荷，从一个文件中加载他们，或者选择一个预先设定的有效载荷列表。模糊测试应用程序中的第一个请求参数往往需要发布数目庞大的请求，并在结果中查找翻唱现象。如果设定的攻击字符创太多，这样反而达不到效果，甚至生成无数的输入，以至于难以对其进行分析。因此，较为明智的做法是，测试一系列可在特定的专门设计的输入的翻唱响应中轻易 确定的常见漏洞，以及出现在应用程序的所有位置而非某些特殊功能中的漏洞。

           • sql注入

             • ‘
             • ‘–
             • ‘; waitfor delay ‘0:30:0’–
             • 1; waitfor delay ‘0:30:0’–

           • xss与消息头注入

             • xsstest
             • "><script>alert('xss')</script>

           • OS命令注入

             • || ping -i 30 127.0.0.1 ;x || ping -n 30 127.0.0.1 &
             • | ping -i 30 127.0.0.1 |
             • | ping -n 30 127.0.0.1 |
             • & ping -i 30 127.0.0.1 &
             • & ping -n 30 127.0.0.1 &
             • ; ping 127.0.0.1 ;
             • %0a ping -i 30 127.0.0.1 %0a
             • ping 127.0.0.1

           • 目录遍历

             • ../../../../../../../../../../../../etc/passwd
             • ../../../../../../../../../../../../../boot.ini
             • ......................\etc\passwd
             • ................................\boot.ini

           • 脚本注入

             • ;echo 111111
             • echo 111111
             • response.write 111111
             • :response.write 111111
         • 4. 前面所有的有效载荷均以字面量形式显示，?、；、&、+空格与=字符因为在HTTP请求中有特殊含义，需要进行URL编码。默认情况下，Burp Intruder会对这些字符进行必要的编码，因此，必须确保该选项没有被禁用。（如果想要在定制后将所有选项恢复到他们的默认值，可从Burp菜单中选择“恢复默认值”选项。）
         • 5. 在Burp Intruder的Grep功能中，配置一组合适的字符串，标记响应中的一些常见的错误消息。例如：
           • error,exception,illegal,invalid,fail,stack,access,directory,file,not found,varchar,odbc,sql,sql,select,111111
           • 注意，其中的字符串111111用于测试成功的脚本注入攻击
         • 6. 同时，选择“有效载荷Grep”选项，标记含有有效载荷自身的响应，该响应应表示可能存在XSS或消息头注入漏洞。
         • 7. 在通过第一个文件包含有效载荷指定的主机上建立一个web服务器或netcat监听器，监控服务器由于远程文件包含攻击而发出的连接尝试。
         • 8. 实施并完成攻击后，在结果中查找表示存在漏洞的反常响应。检查HTTP状态码、响应长度、响应时间、其中是否出现配置的表达式以及是否出现有效载荷本身。可以单击结果表的每一个列标题，对列中的值进行分类（按下Shift键的同事单击鼠标可对结果进行反向排序），这样做客迅速确定所有不同于其他结果的反常响应。
         • 9. 对每一类问题的详情描述，对模糊测试结果表明可能存在的每一个潜在的漏洞进行确认，同事考虑如何成功的利用这些漏洞。
         • 10. 一旦配置Burp Intruder对某一个请求进行模糊测试之后，就可以迅速地对应用程序中的其他请求进行相同的测试。
         • 11. 如果在解析应用程序的过程中更确定了带外输入通道，可通过他们向应用程序提交用户控制的输入。渗透测试员应当通过提交各种旨在触发常见的Web应用程序漏洞的专门设计的数据，对这些输入管道进行类似的模糊漏洞。根据输入通道的特点，可能需要建立一个定制脚本或其他工具。
         • 12. 除了手动对应用程序请求进行模糊测试之外，如果拥有一个自动化web应用程序漏洞扫描器，还应当运行该扫描器，对目标应用程序进行自动测试，并比较两方面的测试结果。

       • 3.7.2 测试sql注入

         • 1. 如果模糊测试中对sql攻击字符串导致任何反常响应，那么应该手动探查，观察应用程序如何处理相关参数，确定其中是否存在sql注入漏洞。
         • 2. 如果提交上书字符创返回错误信息，分析消息的意义。sql报错等。
         • 3. 如果请求中提交一个单引号导致错误或出现其他反常行为，可尝试提交两个单引号；如果这种输入使错误或异常行为小时，应用程序可能易受到SQL注入。
         • 4. 设法使用常用的SQL字符串连接符函数构建一个等同于良性输入的字符串。如果提交这个字符串得到与提交原始的良性输入相同的响应，那么应用程序可能易于受到攻击。例如，如果原始输入为表达式FOO，可以使用下面的输入测试：
           • ‘||’FOO
           • ‘*’FOO
           • ‘ ‘FOO
           • 同样，应对HTTP请求中具有特定意义的字符，如+和空格进行URL编码。
         • 5. 如果原始输入为数字字符，尝试使用一个其结果等于原始值的数学表达式。例如，如果原始值为2，尝试提交1+1或3-1。如果应用程序作出相同的响应，表示它易于受到攻击；如果数字表达是的值对应用程序的行为造成系统性的影响。那么应用程序就特别容易受到攻击。
         • 6. 如果前面的测试取得成功，可以通过使用针对sql的数学表达式构造一个特殊的值，进一步确定sql注入漏洞是否存在。如果可以通过这种方式系统性地控制应用程序的逻辑，那么几乎可以肯定应用程序易于受到SQL注入攻击。例如，
           • 下面两个表达式的结果都等于2：
           • 67-ASCII(‘A’)
           • 51-ASCII(1)
         • 7. 如果使用waitfor命令进行的模糊漏洞测试导致应用程序在进行响应时出现反常的时间延迟，那么所使用的数据库为MS-sql，且应用程序易于受到SQL注入攻击。手动重复测试，在waitfor参数中指定不同的值，确定响应时间是否随着这个值而发生系统性的变化。请注意，可以在几个SQL查询中插入攻击有效载荷；这时观察到的时间延迟为指定值的固定倍数。
         • 8. 如果应用程序易于受到SQL注入攻击，渗透测试员要考虑可以实施哪些攻击，以及如何利用他们实现自己的目的。参考第九章。

           • 修改WHERE子句中的条件，改变应用程序的逻辑（例如，注入or 1=1–避开登录）。

           • 使用UNION操作符注入任意一个SELECT查询，将它的结果与应用程序的原始查询的结果组合在一起。

           • 使用针对数据库的SQL语法“指纹标识”数据库类型。

           • 如果使用的数据库为MS-SQL，且应用程序在响应中返回ODBC错误，利用这些信息枚举数据库结构，获取任意数据。

           • 如果无法获得一个任意输入的查询结果，可以使用以下攻击技巧提取数据。

             • 获取数字格式的字符串数据，一次一字节。
             • 使用带外通道。
             • 如果能够根据任意一个条件引发不同的应用程序响应，可使用Absinthe提取任意数据，一次一比特。
             • 如果能够根据一个任意的条件出发时间延迟，利用他们获取数据，一次一比特。

           • 如果应用程序阻止实施特殊攻击所需的某些字符或表达式，尝试使用第9章描述的各种技巧避开输入过滤。

       • 3.7.3 测试XSS和其他响应注入

         • 3.7.3.1 确定反射型请求参数

           • 1. 单击“有效载荷Grep”列，分类模糊漏洞测试的结果，确定任何与xss检测参数匹配的字符串。判断反射点。
           • 2. 对于上述每一个字符串，检查应用程序的响应，查找用户提交的输入的位置。如果该字符串出现在响应主体中，应测试应用程序中是否存在XSS漏洞。如果它出现在HTTP消息头中，应测试应用程序中是否存在消息头注入漏洞。如果它被用在302响应的Location消息头中，或者用于以某种方法指定重定向，应测试应用衡虚中是否存在重定向漏洞。注意，同一个输入可能会被复制到响应中的几个位置，因此应用程序中可能存在几种类型的反射型漏洞。

         • 3.7.3.2 测试反射型XSS

           • 1. 对于在响应主题中出现的所有请求参数，检查它周围的HTML代码，确定是否可以提交专门涉及的输入，从而执行任意JS脚本。例如，通过注入

                ©2016- x7 | pv | uv
                Theme Tree by WuJun Powered by Hexo