[发明专利]应用程序安全测试

说明书

背景技术

软件安全测试用于识别应用程序(如网页应用程序)中的漏洞。对基于网页的软件的传统黑盒安全测试通过使用通常称为扫描器的安全测试应用程序进行工作，扫描器以攻击者的身份出现。在黑盒方法中，扫描器通过进行HTTP请求并且评价HTTP响应或响应缺失以找出待测应用程序(AUT)接受输入的所有URL，对AUT进行评估。AUT接受输入的URL可以被称作AUT的攻击面。然后，根据该攻击面及可能的漏洞类别，扫描器生成攻击。扫描器施加这些攻击，以通过评价程序的HTTP响应来诊断漏洞的存在或不存在。

附图说明

下面的详细描述参照附图，其中：

图1是根据一个示例的、能够通过确定和修改不安全的执行来修改待测应用程序的执行的计算系统的框图；

图2是根据一个示例的、示出能够修改待测应用程序的执行的测试系统配置的框图；

图3是根据一个示例的、示出基于安全性修改待测应用程序的操作的示例的框图；

图4是根据一个示例的、用于基于待测应用程序的执行的安全性来修改待测应用程序的执行的方法的流程图；以及

图5是根据一个示例的、能够响应于安全测试动作而基于安全性修改待测应用程序的计算设备的框图。

具体实施方式

本文描述的实施例提供用于执行应用程序(如网页应用程序)的测试的技术。当公司想知道该公司生产中的或即将付诸生产的网页应用程序有多安全时，该公司通常使用安全测试方案，如渗透测试方案(例如，使用扫描器)、模糊测试、漏洞测试、软件安全测试、网站安全测试及其结合等等。该公司可能希望使用生产中的应用程序的副本作为待测应用程序(AUT)。使用生产中的应用程序或即将付诸生产的应用程序去作测试的原因是：该公司可能想要测试同样的代码。在质量保证阶段使用即将成为生产中的应用程序的AUT，确保在生产中使用的应用程序已被测试。在本说明书全文中提到了扫描器，然而应当注意，可以类似地使用其它测试方案。

在动态网页应用程序扫描期间，扫描器模拟利用该应用程序工作的用户的动作，来发现应用程序攻击面并对所发现的攻击向量执行大量攻击。由于扫描器不知道该扫描器正在测试的应用程序的逻辑，所以那些操作中的一些可能有害于AUT或其环境。

在一个示例中，在企业应用程序的扫描期间，一旦扫描器发现“联系我们”页面，该应用程序就可以向各个员工发送多封电子邮件。然而，在扫描器的角度看来，该测试仅是另一超文本传输协议(HTTP)POST攻击向量。

在另一示例中，拒绝服务(DoS)攻击的目的是为了使应用程序挂起或崩溃。渗透测试方案想要找出这些漏洞，并且通过发出能使应用程序崩溃的这些攻击来进行寻找。当成功时，该应用程序崩溃或挂起，这有损于进一步的测试。

扫描的危险和破坏性属性可能导致顾客将大量时间花费在待测应用程序的沙箱测试(sandboxing)。由于应用程序的内部复杂性和缺少对其功能性的完整了解，这可能是不成功的。在每次扫描后将应用程序复原至其原始状态的任务可能是耗时的，并且在此过程期间的任何错误都可能导致扫描之间的不一致，从而把漏洞报告的顾客弄糊涂。此外，如果安全测试破坏了AUT的状态，那么测试可能例如由于AUT崩溃、变得无响应、应用程序逻辑被攻击扭曲等而过早地失败。因此，安全测试可能不能发现AUT的重要漏洞，这是因为AUT可能在执行这样的测试以前就失败。

因此，本文介绍的方法的益处可能包括固定进行中的DoS问题但仍将问题报告给测试方案，并且动态地修改AUT的执行来防止AUT执行被认为不安全的动作。该方法可以保证该应用程序保持并运行，同时其仍指出攻击者可以如何利用该应用程序中的任何问题。其它有危害的或不安全的操作可以包括抹掉数据库记录、修改数据库记录、利用在应用程序爬行(crawling)和审核期间创建的多个记录污染数据库、利用服务器侧文件系统的意料外操作、服务器侧资源(例如，可用插槽)的耗尽等。

AUT可以运行于实时修改器环境中。因此，可以改变或修改AUT内的函数的结果。例如，通过在应用程序中插装应用程序编程接口(API)，可以在进行中修改AUT的行为。例如，如果调用不安全的程序，那么实时修改器可以模拟该程序的执行，而实际上不执行危险的操作。在特定示例中，实时修改器的环境可以访问由AUT使用的API。实时修改器方案的示例可以促进包括Java和.NET框架的实现。这些框架可以用于向开发者提供数据库、电子邮件和通信服务。