本章，作者通过12个具体的示例来说明逻辑缺陷问题，这里仅做汇总。
1、征求提示
场景：“记住我”功能，在浏览器中设置一个永久cookie，cookie被加密算法保护，这个算法同时有收集用户的用户名，IP等信息。但同时有另外一个功能是将用户的昵称存储在一个名为ScreenName的cookie中，这两个cookie使用了相同的加密算法。但是用户可以指定自己的昵称，并在屏幕上查看该名称。这在无意间使用户能访问用于保护永久身份验证令牌Remember Me的加密功能。
攻击方法：用户提交RememberMe cookie的加密值到ScreenName，应用程序正常解密了。用户就可以重新设置一个admin昵称的cookie显示并将加密值保存为RememberMe，这样造成问题。
渗透测试步骤：
a. 在应用程序中查找任何使用加密的位置。确定任何应用程序加解密用户提交的值，并尝试替代在应用程序中发现的任何其他加密值
b. 确定应用程序中可以通过提交加密值导致在响应中显示对应解密值的位置，以查找“提示”漏洞，可能导致敏感信息泄露
c. 确定可以通过提交明文值导致应用程序返回加密值的位置，以查找“提示加密”漏洞
2、欺骗密码修改功能
场景：普通用户修改密码需要用户名、现有密码、新密码和确认密码，而管理员修改其他用户的密码时不需要输入那个用户的现有密码。
假设：当服务器处理修改密码的请求时，通过是否包含现有密码参数来确定请求是来自管理员还是普通用户。
攻击：普通用户提交不含 现有密码的请求即可修改其他任何人的密码。
渗透测试步骤：
a. 在关键功能中探查逻辑缺陷时，尝试轮流删除在请求中提交的每一个参数，包括cookie、查询字符串字段与POST数据项
b. 既要删除参数名称，也要删除参数值，不要只提交一个空字符串的值
c. 一次仅攻击一个参数
d. 如果控制的请求属于多阶段过程，一定要完成整个过程。
3、直接结算
场景：购物程序按照 添加商品->确认订单->支付->输入交货信息来处理
假设与攻击：开发者认为用户总会按这个顺序走，实际上用户控制者流程，可以跳过多阶段中的某些阶段，如果没有做验证，用户可能跳过支付阶段。
渗透测试步骤（强制浏览）：
a. 尝试按其他顺序提交请求；尝试完全省略某些阶段、几次访问同一个阶段或推后访问前一个阶段。
b. 这些阶段的结果可通过一系列指向特殊URL的GET或POST请求进行访问，或者向一个URL提交不同的参数。
c. 根据执行功能的情形，了解可能的攻击面
d. 如果不按顺序访问多阶段功能，应用程序会有一些反常现象，可能会返回有用的错误消息与调试结果。
4、修改保险单
也是一个多阶段参数的问题。应用程序使用了一个共享组件处理用户提交的每一个参数。
渗透测试步骤：
a. 只要应用程序通过几个阶段执行一项关键操作，就应该提取在某个阶段提交的参数，然后尝试在另一个阶段提交这些参数。如果相关数据随应用程序的状态一起更新，应该探索这种行为的衍生效果。
b. 如果应用程序执行一项功能，不同类型的用户可根据一组共同的数据更新或执行其他操作，应该利用每种类型的用户执行该功能并观察他们提交的参数。如果不同的用户提交不同的参数，就提取由一名用户提交的每个参数并尝试以其他用户的身份提交这些参数。
5、入侵银行
测试步骤：
a. 在一个需要隔离水平权限或垂直权限的复杂应用程序中，设法确定个体用户能够在会话中”聚积“大量与其身份有关的状态信息的所有情况；
b. 尝试浏览一个功能区域，然后转换到另一个完全无关的区域，确定任何聚积的状态信息是否对应用程序的行为造成影响。
6、规避交易限制
步骤：
a. 尝试输入负值
b. 可能执行几步操作，改变应用程序的状态，使其对攻击有用，如可能需要在帐户之间进行几次转账，直到得到可提取的适当余额
7、获得大幅折扣
加入购物车获取折扣后，再从购物车移走。（这种问题现在应该没有了。。。）
8、避免转义
对其他字符做了转义，但是没有对 \ 进行转义。
尝试在受控制的数据中插入相关元字符后，接着在每个元字符前插入一个反斜线进行测试。
如输入foo\;ls 程序将;转义为\; 变成了foo\\;ls，但是实际执行时第一个\被转义而第二个\ 是字符，并未对;进行转义，测试XSS时可以用 \' 来破坏字符串。
9、避开输入确认
场景：SQL防注入使用了 任何单引号的配对和对超过128个字符进行截短处理
攻击：输入用户名aaaa[...]aaa' （127个a加一个单引号），应用程序会先匹配上一个单引号，再截短为128位，这样最后一个匹配上的单引号被截掉了，aaaa[...]aaa' 仍然被处理，附上or 1=1--的密码即可实现无密码登录。
admin'--也会被处理为admin''--，结果变为select * from users where username='admin''--' and password=''
不必清楚了解应用程序实施的长度限制，只需轮流提交下面的两个长字符串，并确定是否会发生错误：
''''''''''''''''''''''''''''''''''''''''''''' and so on
a''''''''''''''''''''''''''''''''''''''''''''' and so on
以上其中一个字符串将导致在查询中插入奇数数量的单引号，从而生成无效的语法。（为什么？）
如果数据确认按设定的顺序发生，并且有一个或多个确认步骤修改了数据，则确定是否可以将这些步骤用于破坏之前的确认步骤。例如，如果应用程序执行URL编码，过滤掉恶意数据（如<script>标签），则可以通过提交以下字符来避开确认机制。
%<script>3cscript%<script>3ealert(1)%<script3c/script%<script>3e
10、滥用搜索功能
场景：付费用户可以查阅一些文档，普通用户只能搜索到模糊的文档标题，但是无法查看。
攻击方法：提交大量查询，并通过推断利用搜索功能提取正常情况下需要付费才能查阅的信息。
11、利用调试消息
步骤：
a. 列出可能出现的反常事件和条件，调试信息等
b. 同时以两名用户的名义使用应用程序，使用一名或两名用户系统性地创造每一个条件，并确定另一名用户是否受到影响。
12、与登录机制竞赛
场景：应用程序将与新近通过验证的用户有关的标识符临时保存在一个静态（非会话）变量中，改写这个值不久后，应用程序再读取这个变量的值，如果在这个过程中， 有另外一个线程（处理另一个登录）写入到变量中，早先登录的用户就会分配到属于随后登录的用户的会话。
即竞争条件限制。这种情况通过黑盒很难发现，一般通过代码审计发现。黑盒测试需要用一些高端的服务器和攻击脚本，发送大量的请求才能触发。
