本文详细分析了三个逻辑设计缺陷案例，包括搜索功能的滥用、调试信息泄露和竞态条件导致的安全问题。这些缺陷可能导致敏感信息泄露、权限误用和系统不稳定。为了防止逻辑缺陷，建议采取详细记录设计假设、代码注释、安全审核、输入验证和会话管理等最佳实践。此外，强调了对用户行为的异常处理和跨组件交互的影响评估的重要性。
目录
一、逻辑设计缺陷示例
示例10：搜索功能
说明：
应用程序允许用户访问大量的历史档案与当前信息，包括公司报表与账目、新闻稿、市场分析等。大部分信息只有付费用户才可查阅。
应用程序提供一个功能强大、分类详细的搜索功能， 所有用户都可使用这项功能。如果匿名用户执行一项查询，搜索功能将返回所有与在询相匹配的文档链接。但如果用户想要查看返回的受保护文档的实际内容， 就需要付费订阅。应用程序的所有者认为这种行为是一种有用
的营销策略
设计：
如果用户不付费订阅， 就无法使用搜索功能提取任何有用的信息，搜索结果返回的文档标题往往含义模糊
攻击：
因为搜索功能指出与某一查询匹配的文档数量，用户就可以提交大量查询，并通过推断利用搜索功能提取正常情况下需要付费才能在阅的信息。
虽然用户不能查看文档的具体内容， 但通过使用有针对性的请求，就能够相对清楚地了解文档的内容，能够以这种方式通过搜索功住过滤信息，对应用程序的安全非常重要，它会披漏大量与管理功能、密码和采用的技术有关的信息
使用这种方法可对内部文档管理软件实施有效攻击，如果有返回提示，说明坟索宇符串是否出现在页面的任何位置，还个字母地对密码实施蛮力攻击，从而对存储的配置文件内的密码蛮力攻击
示例11：调试信息功能
说明：
应用程序才开发出来新功能，其中包含大量与功能有关的缺陷。每隔一段时间， 应用程序的各种操作就会意外中断， 并向用户返回一条错误消息。
为方便错误调查，开发者在这些消息中提供详尽的信息（对服务台工作人员调查并恢复系统故障非常有用， 而且有助于消除剩下的功能缺陷）包括：用户的身份、当前会话的令牌、被访问的URL、在造成错误的请求中提交的所有参数
设计：
安全顾问经常警告称这种详尽的调试消息可能会被攻击者滥用，但开发者仍然认为它们不会造成任何安全漏洞。通过检查浏览器处理的请求与响应，用户就有可能获得调试消息中包含的所有信息。但这些消息中并未包含与实际故璋有关的任何细节（如栈跟踪），因此无法帮助攻击者向应用程序发动有效攻击
尽管开发者对调试消息的内容进行了合理保护， 但由于他们在创建调试消息时犯下的错误
设计仍然存在缺陷
攻击：
当错误发生时， 应用程序的一个组件将收集所有必要的信息，并将其保存起来。用户收到一
个HTTP重定向，它指向一个显示这些被保存信息的URL。如果在应用程序保存调试信息、用户访问错误消息时，并没有使用会话，调试信息被保存在一个静态容器内，并且错误消息URL总显示最后放入这个容器的信息。因此认为使用重定向的用户只查看到与错误有关的调试信息。实际情况下，如果两个错误几乎同时发生，普通用户偶尔查看到与另一名用户造成的错误有关的调试信息。除线程安全问题外，这并非一个简单的竞态条件。如果攻击者知道错误机制的工作原理，就可以重复访问消息URL, 并记录下所有不同的错误消息。只需短短几个小时， 他就可以获得大量应用程序用户的敏感数据（可用在密码猜测攻击中的用户名、可用于劫持会话的会话令牌、用户提交的输入， 其中包含密码和其他敏感数据）
过程：
1、为探查这种缺陷，首先列出应用程序中可能出现的反常事件和条件，以及以非常规方式向浏览器返回有用的用户信息的情况，如返回调试错误消息。
2、同时以两名用户使用应用程序， 使用一名或两名用户系统性地创造每一个条件，并确定另一名用户是否受到影响
示例12：竞态（反常现象）
说明：
应用程序执行采用一种安全、多阶段的登录机制，要求用户提交几个不同的证书才能获得访问权限
设计：
验证机制接受了大量设计审查与渗透测试，所以应用程序的所有者确信， 攻击者无法向验证机制发动有效攻击，从而获得未授权访问
攻击：
1、如果验证机制存在一个细小的缺陷。例如，顾客登录后， 他可以访问另外一名用户的账户， 查看该用户的所有金额信息，甚至使用其他用户的账户进行支付。最初应用程序的行为完全是随机性的在获得未授权访问之前，用户并没有执行任何非法操作；再次登录时， 反常现象也不会重复出现。
2、偶尔两个不同的用户在同一时间登录，就会出现错误。并不是每次出现这种情况都会发生错误（仅在少数情况下错误才会发生）。发生这种错误的根本原因在于， 应用程序将与最近通过验证的用户有关的标识符临时保存在一个静态（非会话）变量中。改写这个值不久后， 应用程序再读取这个变量的值。如果在这个过程中有另外一个线程（处理另一个登录）写入到变量中， 早先登录的用户就会分配到属于随后登录的用户的会话
3、这种漏洞源于与前面错误消息示例中相同的错误：应用程序使用静态存储保存应根据独立线程或会话保存的信息。但由于这类错误不会反复出现， 当前示例中的缺陷更难发现， 也更难对其加以利用。这种缺陷叫做“竞态条件” 因为其中的漏洞仅在某些特殊情况下才会出现，而且存在时间很短。出于漏洞仅在短时间内存在， 攻击者必须赶在应用程序关闭它之前，对其加以利用。如果攻击者是应用程序的木地用户， 他就有可能知道竞态条件出现的具体情景，并在有效的时间内利用漏洞。如果攻击者属于远程用户要想实施攻击就比较闲难。
4、如果远程攻击者了解到这种漏洞的木质， 那么他就可以通过使用一段脚本连续进行登录， 并查看被访问账户的详细资料， 从而设计出有效的攻击方法。但由于这种漏洞可被利用的时间极短， 攻击者可能需要提交数目庞大的请求
5、进行远程“黑盒测试“ 查找这类细微的线程安全问题非常麻烦，只有极其注重安全的应用程序才需要进行这种测试
过程：
1、针对选择的关键功能进行测试， 如登录机制、密码修改功能与转账过程
2、对每一项测试的功能， 确定某位用户在执行一项操作时需要提交一个或少数几个请求。同时找到确定操作结果的最简单方法，如核实用户登录后是否能够查看他们自己的账户信息
3、使用几台高规格的机器， 从不同的网络位置访问应用程序， 写出一段攻击脚本， 代表几名不同的用户反复执行相同的操作。确定每项操作是否达到预期的结果
4、为接收大量错误警报做好准备。根据为应用程序提供支持的基础架构的规模，可能需要对安装的软件进行负载测试（有时反常现象可能与安全无关）
二、避免逻辑缺陷
简介：
无法通过明确的特征确定Web应用程序中存在的逻组缺陷一样，同样也没有能够保护应用程序的万能防御措施。例如，虽然无法找到安全的方法替代危险的API，但一系列最佳实践可显著降低在应用程序中出现逻出缺陷造成的风险
方法：
1、确保将应用程序各方面的设计信息清楚、详细地记录在文档中， 以方便其他人了解设计者做出的每个假设。同时将所有这些假设明确记录在设计文档中
2、所有源代码提供清楚的注释，（包括每个代砃组件的用途和预计用法、每个组件对它无法直接控制的内容做出的假设、利用组件的所有客户端代码引用， 清楚记录它的效果有助于阻止在线注册功能中的逻辑缺陷）
3、在以安全为中心的应用程序设计审核中，考虑在设计过程中做出的每一个假设，并想象假设被违背的每种情况（尤其应注意任何应用程序用户可完全控制的假定条件）
4、在以安全为中心的代码审查中，从各个角度考虑以下两个因素： 应用程序如何处理用户的反常行为和输入；不同代码组件与应用程序功能之间的相互依赖和互操作可能造成的不利影响
5、用户可以控制请求每一个方面的内容，按任何顺序访问多阶段功能；他们可以提交应用程序并未要求的参数，他们可以完全省略某些参数， 而不仅仅是篡改参数值
6、根据会话确定用户的身份与权限
7、当根据用户提交的数据或者用户执行的操作更新会话数据时， 仔细考虑更新后的数据可能会给应用程序的其他功能造成什么影响（这些数据可能会给由其他程序员或其他开发团队编写的完全无关的功能造成意想不到的不利影响）
8、如果一项搜索功能可用于查询禁止某些用户访问的敏感数据， 确保那些用户无法利用该项功能、根据搜索结果推断出有用的信息。如果可以， 根据不同的用户权限保留几个搜索索引，或使用当前用户的权限进行动态信息搜索
9、如果一项功能允许用户从审计追踪中删除任何记录， 在使用该项功能时应特别小心。在大量使用审计的应用程序与双重授权模型中， 考虑一名高级权限用户创建另一个相同权限的用户可能选成的影响
10、如果应用程序根据数字交易限额执行检查， 在处理用户输入前，必须对所有数据实施严，格的规范化与数据确认（如没有考虑到使用负数的情况）
11、如果应用程序根据订购商品的数量决定折扣， 必须保证在实际应用折扣前确定订单
12、如果在将用户提交的数据提交给可能易于受到攻击的应用程序组件前，对其进行转义处理，一定要记得对转义字符本身进行转义， 否则整个确认机制可能会遭到破坏
13、始终使用适当的存储方法保存与某位用户有关的数据
733
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
