许多应用程序被设计为通过部分隐藏输入表单来确定用户当前状态而展示不同的页面。但是,在许多情况下,有可能通过代理提交此类隐藏表单的值。在这些案例中,服务器端控制措施必须足够健壮来确保正确的业务逻辑数据。
此外,应用程序必须不依赖于不可编辑元素,下拉框列表或者业务逻辑处理过程的隐藏表单域,因为这些只是在浏览器的环境中不可编辑。用户可以使用代理工具来编辑这些参数并尝试操纵业务逻辑。如果应用程序对外暴露了业务规则数据如商品数量等作为不可编辑域,那么必须在服务器端存在同样的副本来共同作用在业务逻辑处理中。最后,作为应用程序/系统数据,日志系统必须足够安全来阻止读写更新操作。
业务逻辑完整性检查漏洞独特在相关的误用案例是应用程序相关的,如果用户可以改变某些功能,那么他们应该仅能在业务逻辑中的特定时刻进行写或者更新/编辑相关操作。
应用程序必须对编辑拥有足够的检查,不允许用户直接向服务器提交无效信息,不信任不可编辑域的信息或是未授权操作用户提交的信息。此外,系统关键组件如日志系统,应受到“保护”,不能被非授权读取、写入和移除。
想象一个ASP.NET应用只允许管理员用户来修改其他用户的密码。管理员用户能看到其他用户用户名和密码区域,而其他用户不能。但是,如果非管理员用户通过代理提交该该区域的用户名和密码,就有可能“欺骗”服务器来相信那些请求来自管理员用户,并为其他用户更改密码。
大多数web应用使用下拉列表帮助用户进行快速选择状态、生日等等。假设一个项目管理应用允许用户登录,并将他们拥有权限的项目作为下拉框呈现。万一攻击者能找到没有权限的其他项目,并通过代理提交相关信息会如何?应用程序会通过访问请求么?他们不应该被允许,即使已经绕过了授权阶段的业务逻辑检查。
假设摩托载具管理系统要求员工最初在市民申请标示或者驾驶许可证时验证每个市民资料和信息。在此时,业务处理过程创建了高级别数据完整性的数据,因为提交的数据被应用程序检查。现在假设应用程序移到了互联网之中,员工可以登录进行全业务服务,用户也可能登录进行自助服务来更新部分信息。此时,攻击者可以使用劫持代理来添加或更新他们没有权限进行控制的数据,并破坏数据完整性(比如给未婚市民提供配偶名字)。这种类型的插入/更新未确认的数据可能摧毁数据完整性,应该被阻止。
许多系统包括用于审计和问题处理的日志系统。但是这些日志信息有多少是好的/有效的。他们能被攻击者有意无意改变来破坏完整性么?
所有 输入验证 相关的测试用例。
ZAP是一个非常容易使用的web应用程序渗透测试整合工具。他被设计为符合不同安全经验的人员使用,特别是新接触渗透测试的开发人员和功能测试人员的理想工具。ZAP在提供一系列的用于手工漏洞检测的工具的同时也提供了自动化扫描器。
应用程序必须对编辑拥有足够的检查,不允许用户直接向服务器提交无效信息,不信任不可编辑域的信息或是未授权操作用户提交的信息。此外,任何可能被编辑修改的组件必须拥有对抗有意或无意的修改和升级措施。