参考:The Web Application Hackers Handbook Chapter 11
避免逻辑漏洞(Avoiding Logic Flaws)
就像没有唯一的签名可以用来识别Web应用程序中的逻辑缺陷一样，也没有可以保护您的银弹(仙丹)。 例如，没有等效于使用安全替代危险API的简单建议。 但是，可以将一系列良好做法应用于 显着降低在应用程序中出现逻辑错误的风险：
- 确保应用程序设计的每个方面都清楚详细地记录在案，以使外部人员可以理解设计者所做的每个假设。 所有这些假设都应明确记录在设计文档中。
- 要求所有源代码都经过明确注释，以便始终包含以下信息：
- 每个代码组件的目的和预期用途。
- 每个组件对超出其直接控制范围的任何事物所做的假设。
- 对使用该组件的所有客户端代码的引用。 明确的文档说明可能会阻止在线注册功能中的逻辑错误。 （请注意，此处的“客户端”不是指客户端/服务器关系的用户端，而是指所考虑的组件与其直接相关的其他代码。）
- 对使用该组件的所有客户端代码的引用。 明确的文档说明可能会阻止在线注册功能中的逻辑错误。 （请注意，此处的“客户端”不是指客户端/服务器关系的用户端，而是指所考虑的组件与其直接相关的其他代码。）
- 在关注安全性的代码审查期间，请横向思考两个关键领域：应用程序处理意外用户行为的方式，以及不同代码组件和不同应用程序功能之间任何依赖关系和互操作性的潜在副作用。
关于我们描述的逻辑缺陷的特定示例，可以学到许多单独的经验教训：
- 不断意识到用户可以控制每个请求的各个方面（请参见第1章）。 他们可以按任何顺序访问多级功能。 他们可能会提交应用程序不需要的参数。 他们可能会省略某些参数，而不仅仅是干扰参数的值。
- 根据用户的会话决定所有有关用户身份和状态的决定（请参阅第8章）。 请勿基于请求的任何其他功能，包括根本发生的事实，对用户的特权不做任何假设。
- 在实现基于从用户接收的输入或用户执行的操作来更新会话数据的功能时，请仔细考虑更新后的数据可能对应用程序中其他功能造成的影响。 请注意，由不同的程序员甚至不同的开发团队编写的完全不相关的功能可能会发生意外的副作用。
- 如果搜索功能易于索引某些用户无权访问的敏感数据，请确保该功能不提供任何手段让这些用户根据搜索结果来推断信息。 如果合适，请根据不同级别的用户权限维护多个搜索索引，或者使用发出请求的用户的权限对信息库进行动态搜索。
- 对实现允许任何用户从审核跟踪中删除项目的任何功能非常谨慎。 另外，请考虑在经过严格审核的应用程序和双重授权模型中，高特权用户创建另一个具有相同特权级别的用户的可能影响。
- 根据数字业务限制和阈值进行检查时，请在处理所有用户输入之前对其进行严格的规范化和数据验证。 如果不需要负数，则明确拒绝包含负数的请求。
- 在基于订单量实施折扣时，请确保在实际应用折扣之前完成定单。
- 在传递给潜在的易受攻击的应用程序组件之前转义用户提供的数据时，请始终确保对转义符本身进行转义，否则整个验证机制可能会被破坏。
- 始终使用适当的存储空间来维护与单个用户相关的任何数据，无论是在会话中还是在用户个人资料中。
Summary
攻击应用程序的逻辑涉及系统探测和横向思考的混合。 我们已经介绍了各种按键检查，您应该始终执行这些按键检查来测试应用程序的行为，以应对意外输入。 其中包括从请求中删除参数，使用强制浏览来按顺序访问功能以及将参数提交到应用程序中的不同位置。 通常，应用程序对这些操作的响应方式会指向一些您可能会违反的有缺陷的假设，从而造成恶意影响。
除了这些基本测试之外，探查逻辑缺陷时最重要的挑战是试图深入开发人员的头脑。 您需要了解他们想要达到的目标，他们可能做出的假设，他们可能采取的捷径以及他们可能犯的错误。 想象一下，您的工作期限很紧，主要是担心功能而不是安全性，试图在现有代码库中添加新功能，或者使用其他人编写的文档化的API。 在这种情况下，您会怎么做，怎么利用它？
Chapter 11 Attacking Application Logic(2)-Real-World Logic Flaws(4)
Chapter 12 Attacking Users: Cross-Site Scripting(1) - Varieties of XSS
