Web应用程序黑客的方法论来自书本 The Web Application Hacker’s Handbook
5.1 理解机制(Understand the Mechanism)
5.1.1
分析用于管理会话和状态的机制.确定应用程序是否使用会话令牌或其他方法来处理从每个用户接收到的一系列请求.注意，有些身份验证技术(如HTTP身份验证)可能不需要完整的会话机制来重新识别身份验证后的用户.另外，一些应用程序使用无会话的状态机制，在这种机制中，所有状态信息都通过客户端传输，通常是加密的或模糊的形式.
5.1.2
如果应用程序使用会话令牌，则精确地确定哪些数据片段实际用于重新标识用户.可以用来传输令牌的项包括HTTP cookie、查询字符串参数和隐藏的表单字段.几个不同的数据片段可能被用来重新识别用户，不同的项目可能被不同的后端组件使用.通常，看起来像会话标记的项实际上可能不会被应用程序采用，例如web服务器生成的默认cookie.
5.1.3
要验证哪些项实际上是作为会话标记使用的，请查找与会话相关的页面或函数(例如特定于用户的My Details页面).然后向它发出几个请求，系统地排除您怀疑用作会话令牌的每个项.如果删除某个项会阻止返回与会话相关的页面，则可以确认该项是会话令牌.Burp Repeater是执行这些测试的有用工具.
5.1.4
在确定哪些数据项实际用于重新标识用户之后，对于每个令牌，请确认它是否被完整地验证，或者是否忽略了令牌的某些子组件.每次更改令牌的值1字节，并检查修改后的值是否仍然被接受.如果您发现令牌的某些部分实际上并没有用于维护会话状态，那么您可以在进一步的分析中排除这些部分.
5.2 测试令牌的含义(Test Tokens for Meaning)
5.2.1
在不同的时间作为几个不同的用户登录，并记录从服务器接收到的令牌.如果可以进行自注册，并且您可以选择自己的用户名，则使用一系列类似的用户名进行登录，这些用户名有一些小的变化，比如a、AA、AAA、AAAA、AAAB、AAAC、AABA等等.如果在登录时提交了其他特定于用户的数据或将其存储在用户配置文件中(例如电子邮件地址)，则执行类似的操作来系统地修改该数据并捕获生成的令牌.
5.2.2
分析您接收到的令牌，看它们是否与用户名和其他用户可控制的数据相关.
5.2.3
分析令牌是否有任何可检测的编码或混淆.查找用户名的长度和令牌的长度之间的相关性，这强烈地表明使用了某种混淆或编码.如果用户名包含相同字符的序列，则在令牌中查找对应的字符序列，这可能表示使用了XOR混淆.在标记中查找仅包含十六进制字符的序列，它可能表示ASCII字符串或其他信息的十六进制编码.查找以=和/或只包含其他有效Base64字符的序列:a到z、A到Z、0到9、+和/.
5.2.4
如果您可以在会话令牌样本中识别出任何有意义的数据，那么请考虑这样是否足以发起攻击，尝试猜测最近向其他应用程序用户发出的令牌.找到一个依赖于会话的应用程序页面，并使用第14章中描述的技术自动生成和测试可能的令牌.
5.3 测试令牌的可预测性(Test Tokens for Predictability)
5.3.1
使用能使服务器返回新令牌的请求(例如，一个成功的登录请求)，生成并连续捕获大量会话令牌.
5.3.2
尝试确定令牌样本中的任何模式.在所有情况下，您都应该使用Burp Sequencer(如第7章所述)来执行应用程序令牌随机性的详细统计测试.根据结果，执行以下手工分析可能也很有用:
- 应用您对应用程序实际使用哪些令牌和子序列的理解来重新识别用户.忽略任何不以这种方式使用的数据，即使它在不同的样本之间有所不同.
- 如果不清楚令牌或其任何单独组件中包含的数据类型，请尝试应用各种译码(例如，Base64)来查看是否出现了任何更有意义的数据.可能需要逐一尝试多个decode.
- 尝试识别每个解码令牌或组件中包含的值序列中的任何模式.计算连续已成功的值之间的差值.即使这些看起来是混乱的，也可能有一组固定的观察到的差异，这在很大程度上缩小了任何蛮力攻击的范围.
- 在等待几分钟后获取类似的令牌样本，并重复相同的分析.尝试检测令牌的内容是否与时间相关.
5.3.3
如果您发现任何模式，请使用其他IP地址和用户名捕获第二个令牌样本.这将帮助您确定是否检测到相同的模式，以及是否可以推断出在第一次练习中收到的令牌以猜测在第二次练习中收到的令牌.
5.3.4
如果可以识别任何可利用的序列或时间依赖性，请考虑这是否足以发起尝试猜测最近发给其他应用程序用户的令牌的攻击.使用第14章中描述的技术自动执行生成任务并测试可能的令牌.除了最简单的顺序外，您的攻击可能还需要涉及某种自定义脚本.
5.3.5
如果会话ID似乎是自定义编写的，请使用Burp Intruder中的位翻转器有效载荷源依次修改会话令牌中的每个位.响应中的字符串的Grep，该字符串指示修改令牌是否没有导致无效的会话以及该会话是否属于其他用户.
5.4 检查令牌的不安全传输(Check for Insecure Transmission of Tokens)
5.4.1
正常浏览应用程序，从起始URL上未经身份验证的内容开始，进行登录过程，然后遍历应用程序的所有功能.记下发出新会话令牌的每种情况，通信的哪些部分使用HTTP以及哪些部分使用HTTPS.您可以使用拦截代理的日志记录功能来记录此信息.
5.4.2
如果将HTTP cookie用作会话令牌的传输机制，请验证是否设置了安全标志，以防止它们通过HTTP连接进行传输.
5.4.3
确定在应用程序的正常使用中，会话令牌是否曾经通过HTTP连接传输.如果是这样，它们很容易被拦截.
5.4.4
如果应用程序对未经身份验证的区域使用HTTP并切换至HTTPS以登录和/或通过身份验证应用程序，验证是否为HTTPS发出了新令牌通讯的一部分，或者是否在当应用程序切换到HTTPS时，HTTP阶段保持活动状态.如果在HTTP阶段发出的令牌仍处于活动状态，则该令牌为容易被拦截.
5.4.5
如果应用程序的HTTPS区域包含任何指向HTTP URL的链接，遵循这些并验证会话令牌是否已提交.如果是，请确定它是继续有效还是被服务器立即终止.
5.5 检查日志中令牌的公开(Check for Disclosure of Tokens in Logs)
5.5.1
如果您的应用程序映射练习确定了任何日志记录，监视或诊断功能，请仔细检查这些功能以确定是否在其中公开了任何会话令牌.确认通常有权访问这些功能的人员.如果它们仅用于管理员，请确定是否存在任何其他漏洞，这些漏洞可以使特权较低的用户访问它们.
5.5.2
标识在URL中传输会话令牌的所有实例.这可能是令牌以更安全的方式传送一般，但开发商已经使用在特定情况下的URL要解决一个具体问题.如果是这样，当用户点击任何非现场链接时，这些信息可能会在Referer标头中传输.检查是否有任何功能可以使您将任意站点外链接注入其他用户查看的页面.
5.5.3
如果找到收集收集给其他用户的有效会话令牌的方法，请寻找一种方法来测试每个令牌以确定它是否属于管理用户(例如，尝试使用该令牌访问特权功能).
5.6 检查令牌到会话的映射(Check Mapping of Tokens to Sessions)
5.6.1
使用相同的用户帐户（从不同的浏览器进程或从不同的计算机）两次登录到应用程序.确定两个会话是否同时保持活动状态.如果确实如此，则该应用程序将支持并发会话，从而使攻击了另一用户凭据的攻击者可以使用这些会话而不会被发现.
5.6.2
使用同一用户帐户从不同的浏览器进程或不同的计算机登录和注销几次.确定是每次发出新的会话令牌，还是每次相同的帐户登录时都发出相同的令牌.如果发生后者，则该应用程序实际上并没有使用适当的会话令牌，而是使用唯一的持久字符串来重新标识每个用户.在这种情况下，无法防止并发登录或正确强制会话超时.
5.6.3
如果令牌似乎包含任何结构和含义，请尝试将可能识别用户的组件与看起来难以理解的组件分开.尝试修改令牌的任何与用户相关的组件，以便它们引用应用程序的其他已知用户.验证应用程序是否接受生成的令牌，以及是否使您能够伪装成该用户.有关此类细微漏洞的示例，请参见第7章.
5.7 测试会话终止(Test Session Termination)
5.7.1
在测试会话超时和注销缺陷时，请仅关注服务器对会话和令牌的处理，而不是客户端上发生的任何事件。 在会话终止方面，没有多少取决于客户端浏览器中的令牌发生什么。
5.7.2
检查服务器上是否实现了会话过期:
- 登录到应用程序以获取有效的会话令牌
- 等待一段时间而不使用此令牌，然后使用该令牌提交对受保护页面(例如 My Details)的请求
- 如果页面正常显示，则令牌仍处于活动状态
- 使用反复试验来确定任何会话到期超时有多长时间，或者在使用令牌的上一个请求之后，令牌是否仍可以使用。Burp Intruder可以配置为增加连续请求之间的时间间隔，以自动执行此任务。
5.7.3
检查是否存在注销功能。如果是这样，请测试它是否能使服务器上的用户会话无效. 注销后，尝试重用旧令牌，并通过使用令牌请求受保护的页面来确定其是否仍然有效。如果会话仍处于活动状态，则即使用户“注销”，用户也仍然容易受到某些会话劫持攻击。您可以使用Burp Repeater从代理历史记录中继续发送特定请求，以查看注销后应用程序是否做出不同响应.
5.8 检查会话固定(Check for Session Fixation)
5.8.1
如果应用程序向未经身份验证的用户发出会话令牌，请获取令牌并执行登录。如果应用程序在成功登录后未发出新令牌，则很容易受到会话固定的影响。
5.8.2
即使应用程序不向未经身份验证的用户发出会话令牌，也可以通过登录获取令牌，然后返回登录页面。如果即使您已经通过身份验证，该应用程序仍愿意返回此页面，请使用同一令牌以其他用户身份提交另一个登录。如果应用程序在第二次登录后未发出新令牌，则很容易受到会话固定的影响。
5.8.3
标识应用程序使用的会话令牌的格式。将令牌修改为有效形成的发明值，然后尝试登录。如果应用程序允许您使用发明的令牌创建经过身份验证的会话，则会话固定很容易受到攻击。
5.8.4
如果应用程序不支持登录，但是处理敏感的用户信息（例如个人和付款详细信息），并允许在提交后显示这些信息（例如在“验证我的订单”页面上)针对显示敏感数据的页面执行前面的三个测试.如果以后在使用应用程序的匿名过程中设置的令牌可以用于检索敏感的用户信息，则该应用程序容易受到会话固定的攻击。
5.9 检查CSRF(Check for CSRF)
5.9.1
如果应用程序仅依靠HTTP cookie作为其传输会话令牌的方法，则它可能容易受到跨站点请求伪造攻击的攻击。
5.9.2
查看应用程序的关键功能，并确定用于执行敏感操作的特定请求。如果攻击者可以为这些请求（它们不包含任何会话令牌，不可预测的数据或其他机密）中的任何一个预先完全确定参数，几乎可以肯定该应用程序容易受到攻击.
5.9.3
创建一个无需任何用户交互即可发出所需请求的HTML页面.对于GET请求，您可以放置<img>标签，并将src参数设置为易受攻击的URL。对于POST请求，您可以创建一个表单，该表单包含攻击所需的所有相关参数的隐藏字段，并且其目标设置为易受攻击的URL。您可以在页面加载后立即使用JavaScript自动提交表单。登录到应用程序后，使用相同的浏览器加载HTML页面。验证是否在应用程序中执行了所需的操作。
5.9.4
如果应用程序在请求中使用其他令牌以防止CSRF攻击，请以与会话令牌相同的方式测试这些令牌的鲁棒性。还要测试应用程序是否容易受到UI纠正攻击，以击败反CSRF防御（更多详细信息，请参见第13章）。
5.10 检查Cookie范围(Check Cookie Scope)
5.10.1
如果应用程序使用HTTP cookie传输会话令牌（或任何其他敏感数据），请查看相关的Set-Cookie标头，并检查用于控制cookie范围的任何域或路径属性。
5.10.2
如果该应用程序明确地将其Cookie的作用域放宽到父域或父目录，则它可能很容易受到通过父域或目录中托管的其他Web应用程序的攻击的攻击。
5.10.3
如果应用程序将其Cookie的域范围设置为自己的域名（或未指定域属性），则它仍可能通过子域上托管的任何应用程序受到攻击。这是Cookie范围界定工作原理的结果。除非没有在安全敏感应用程序的子域上托管任何其他应用程序，否则无法避免。
5.10.4
确定是否需要按路径进行隔离，例如 /site/main 和 /site/demo，在发生跨站点脚本攻击时可以将其破坏。
5.10.5
识别将接收应用程序发出的cookie的所有可能的域名和路径。确定是否可以通过这些域名或路径访问任何其他Web应用程序，您可以利用它们来捕获发布给目标应用程序用户的cookie。
