目录
一、逻辑设计缺陷示例
示例4：多阶段多值可选
说明：
应用程序为用户提供保险报价，需要的用户可在线完成并提交一份保险申请
过程步骤：
1、申请人提交基本信息，并指定首选月保费或希望投保的金额，显示报价，同时计算申请人并未指定的其他值
2、申请人提交其他各种个人信息， 包括健康状况、职业与爱好
3、连接一名保险员，保险员使用该应用程序审核申请人提交的信息， 并决定是否接受申请， 或者修改最初的报价以反映任何额外的风险
（应用程序使用一个共享组件处理用户提交的每一个参数。这个组件
将每个POS付行求中的所打数据解析成名1位对， 井使用收到的数据更新其状态信息）
设计：
处理用户提交的数据的组件认为每个请求仅包含用户在相关HTML表单中提交的参数，如果开发者并未考虑，用户提交了应用程序并不希望他提交的参数（用户可在每个请求中提交任意参数与参数值）
攻击：
1、攻击者可利用共享组件避开所有服务器端的输入确认。在报价过程的每一个阶段， 应用程序对这些阶段提交的数据执行严格的确认，并拒绝任何未通过这种确认的数据。但共享组件使用用户提交的每一个参数更新应用程序的状态。如果攻击者提供应用程序在较早阶段需要的一个名/值对， 不按顺序提交数据， 那么应用程序将不对其进行任何确认， 直接接受并处理该数据。如果出现这种情况，恶意用户就可以据此实施针对保险员的存储型跨站脚本攻击， 访问属于其他应用程序的个人信息
2、攻击者能够以任意价格购买保险。在报价过程，申请人指定他们首选的月保费或希望投保的金额， 应用程序据此计算其他值。但如果用户在后续某个阶段为上面的一个或几个数据项提交新的值， 那么应用程序将根据这些值更新自己的状态。不按顺序提交这些参数， 攻击者就可以获得任意价格的保险报价及任意月保费
3、应用程序并不对某一类用户能够提交哪些参数实施访问控制。当保险员审核完申请时， 他们会更新各种数据， 包括做出承保决定。这些数据由处理普通用户提交的数据的同一个共享组件处理。如果攻击者知道或猜测出保险员在审查申请时使用的参数名称，就可以提交这些参数不用签署保单即可接受自己的申请
过程：
1、只要应用程序通过几个阶段执行一项关键操作，就应该提取在某个阶段提交的参数，然后尝试在另一个阶段提交这些参数。如果相关数据随应用程序的状态一起更新，应该探索这种行为的衍生效果， 确定是否可以利用它实施任何恶意操作
2、如果应用程序执行一项功能， 不同类型的用户可根据一组共同的数据更新或执行其他操作， 应该利用每种类型的用户执行该功能并观察他们提交的参数。如果不同的用户提交不同的参数， 就提取由一名用户提交的每个参数，并尝试以其他用户的身份提交这些参数。如果应用程序接受并处理这些参数，探索这种行为的衍生效果
示例5：相同功能组件
说明：
应用程序允许尚未使用在线应用程序的顾客进行注册，并要求新用户提供一些基本的个人信息， 在一定程度上确认他们的身份（包含姓名、地址和出生日期， 但井不包括任何机密信息，如现有密码或PIN号码）
顾客正确输入这些信息后， 应用程序再将注册请转交给后端系统处理。再向用户注册的地址邮寄一个包裹（内含有如何通过给公司呼叫中心拨打电话激活在线访问的指导， 以及用户在第一次登录应用程序时使用的一次性密码）
设计：
应用程序的设计者认为这种机制可为防止未授权访问提供强大的保护：
1、应用程序要求用户提前输入一部分个人信息，阻止恶意攻击者以其他用户的身份进行注册
2、注册过程包括以非常规邮寄的形式向顾客注册的地址传送一些机密信息。要想实施攻击，任何攻击者都必须盗取受害人的邮件
3、注册功能要求顾客给呼叫中心拨打电话，并根据个人信息与在PIN号码中选择的数字， 以
常规方式核实他们的身份（获得用户信息后（对象被实例化）， 与提交的信息一起保存在用户会话中，应用程序核对用户信息， 如果信息有效， 就给该用户分配一个唯一的顾客号码，并将其用在公司的所有系统中，将这个号码连同用户的其他一些信息， 一起添加到这个对象中，并将对象传送至处理注册请求的后端系统进行处理）
攻击：
应用程序的其他功能（包括核心功能）也使用合并到注册功能中的相同代码组件，核心功能
允许通过验证的用户访问账户、账目、转账和其他信息。一名注册用户成功通过应用程序的验证后（对象也被实例化， 并保存在他的会话中， 用于存储与其身份有关的关键信息）。应用程序的绝大多数功能在执行操作时引用这个对象中保存的信息，如应用程序根据保存在这个对象中的唯一顾客号码生成在用户主页面显示的账户信息应用程序的其他功能已经使用这个代码组件， 意味行开发者的设计存在缺陷，应用程序重复
使用它们是一个安全隐患，从“黑盒＂角度探在应用程序时，实际上很难发现并利用这个漏洞。应用程序的主要功能受到几层访问控制的保护， 用户需要拥有一个完全合法的会话才能通过这些控制1、使用自己的有效账户证书登录应用程序
2、使用登录后得到的通过验证的会话， 访问注册功能并提交另一名顾客的个人信息，应用程序就会用一个与目标顾客有关的对象， 重写攻击者会话中最初的CCustomer对象
3、返回应用程序主要功能并访问其他顾客的账户
过程：
1、在一个需要隔离水平权限或垂直权限的复杂应用程序中，设法确定个体用户能够在会话中“聚积“ 大量与其身份有关的状态信息的所有情况。
2、尝试浏览一个功能区域， 然后转换到另一个完全无关的区域， 确定任何聚积的状态信息是否会对应用程序的行为造成影响
示例6：负值等意外值
说明：
财务人员有资格在公司拥有的银行账户与公司关键客户和供应商的账户之间进行转账。为防
止金融欺诈， 应用程序将大多数用户的转账金额限制在一定范围之内。如果转账金额超出限制， 就需要得到高级经理的批准
设计：
如果转账金额超出预先设定的限制， 只有得到高级经理的许可交易才能进行
限制示例：
1、零售应用程序禁止用户订购超出其库存量的商品
2、银行应用程序禁止用户支付超出其当前账户余额的账单
3、保险应用程序根据年龄限制调整报价
攻击：
设计可能存在缺陷，如果忽略了用户用负金额进行转账的可能性。由于任何负值都小于转账金额限制， 因此不需要得到进一步的批准。但应用程序的银行模块接受负值转账，并以反向正值转账的形式对其进行处理，如果用户希望从A账户转账到B账户，他只需从B账户转账负数金额到A账户， 即可得到相同的效果， 并且不需要经过批准，应用程序实施的反欺诈防御措施也被轻易避开
过程：
1、了解受控制的相关输入接受哪些字符
2、尝试输入负值，观察应用程序是否接受这些值并按预想的方式对它们进行处理
3、改变应用程序的状态，使其对攻击有用，如可能需要在账户之间进行几次转账， 直到得到可提取的适当余额
1129
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
