自动化敏捷测试方法_敏捷软件项目中的自动化安全测试

自动化敏捷测试方法

现代软件开发中的安全性 (Security in Modem Software Development)

Modern agile methods allow us to create and deploy software faster than ever before. Unfortunately, agile methods and secure software have historically not been the best of friends. Traditional security practices have usually been built for waterfall projects with upfront requirements and security gates, and so agile teams have a hard time adapting them to a world with frequent requirements changes and fast deploy cycles.

现代敏捷方法使我们能够比以往更快地创建和部署软件。 不幸的是，敏捷方法和安全软件历来不是最好的朋友。 通常针对具有前期要求和安全门的瀑布项目建立传统的安全实践，因此敏捷团队很难适应不断变化的需求和快速部署周期的环境。

One of the most fundamental changes brought about by agile methods is how testing is done. If you deliver software with every sprint, handling implementations over to a dedicated test team is not an option. Agile teams therefore usually depend on an automated test suit to ensure the quality of their software. However, developers often only write so-called “happy-path” or “positive” tests, ensuring a program behaves correctly when provided with valid input. After all, this is what the customer is after and therefore provides business value. The problem here, however, is that attackers do not stay on the happy path but instead try to step around it and into parts of the code in ways developers do not expect. Or as David A. Wheeler puts it in his article How to Prevent the next Heartbleed

敏捷方法带来的最根本的变化之一就是如何进行测试。 如果您随每个Sprint交付软件，则不能选择将实施工作交给专门的测试团队处理。 因此，敏捷团队通常依赖自动化测试套件来确保其软件质量。 但是，开发人员通常只编写所谓的“幸福路径”或“积极”测试，以确保程序在提供有效输入后能够正确运行。 毕竟，这就是客户所追求的，因此可以提供商业价值。 但是，这里的问题是，攻击者不会停留在幸福的道路上，而是尝试以开发人员无法预期的方式逐步进入并进入代码的各个部分。 或正如大卫·惠勒(David A. Wheeler)在他的文章“ 如何防止下一次心出血”中所说的那样

Mostly-positive testing is practically useless for secure software. Mostly-positive testing generally isn’t testing for the right thing! In the Heartbleed attack, like most attacks, the attacker sends data in a form not sent in normal use. TDD and interoperability testing are good things… but you typically need to augment them if your goal is secure software.

对于安全软件，大多数情况下，阳性测试几乎没有用。 通常，阳性测试不是针对正确的东西进行测试！ 在心脏出血漏洞攻击，最喜欢的攻击，攻击者在正常使用时不会发送形式发送数据。 TDD和互操作性测试是一件好事……但是，如果您的目标是安全软件，则通常需要对其进行扩充。

David A. Wheeler proposed so-called “negative testing”, e.g. checking how an application reacts to invalid inputs. Unfortunately, as it is hard to write tests for all kinds of invalid inputs and they do not provide direct business value, such tests are often ignored. In recent years several tools allowing automatic or semi-automatic security tests have been introduced promising to solve this problem.

David A. Wheeler提出了所谓的“负测试”，例如检查应用程序对无效输入的React。 不幸的是，由于很难为各种无效输入编写测试，并且它们不能提供直接的业务价值，因此通常会忽略此类测试。 近年来，已经引入了几种允许自动或半自动安全测试的工具，有望解决该问题。

In my current project, we want to introduce such a tool into our existing CI/CD pipeline. In this story, I will have a look at one of them, the OWASP Zed Attack Proxy and how it can be used to improve the security of agile development pipelines.

在我当前的项目中，我们希望将这样的工具引入我们现有的CI / CD管道中。 在这个故事中，我将介绍其中之一，OWASP Zed攻击代理，以及如何使用它来提高敏捷开发管道的安全性。

OWASP ZAP (OWASP ZAP)

OWASP ZAP (short for Zed Attack Proxy) is an open-source security scanner. It can be used to perform penetration tests for various kinds of web applications and is intended to be used by developers as well as professional security testers. According to toolswatch.org, it is currently the most used penetration testing tool. A test performed by ZAP usually consists of an exploration, attack, and report phase.

OWASP ZAP(短对于z编甲 ttack P乐声)是一个开放源码的安全扫描器。 它可以用于对各种Web应用程序执行渗透测试，并且供开发人员以及专业的安全测试人员使用。 根据toolswatch.org ，它是目前使用最广泛的渗透测试工具。 ZAP执行的测试通常包括探索，攻击和报告阶段。

探索阶段 (The Explore Phase)

In the explore phase ZAP attempts to learn about the system being tested, e.g. determine what software is in use, what endpoints exist, check for known vulnerabilities, and other indications of weakness. ZAP provides different strategies to explore an application:

在探索阶段，ZAP尝试了解正在测试的系统，例如，确定正在使用的软件，存在的端点，检查已知漏洞以及其他弱点迹象。 ZAP提供了探索应用程序的不同策略：

1. ZAP can passively scan the traffic to a web application using an interception proxy. You can browse an application manually through this proxy and ZAP analyses every request and response.
   ZAP可以使用拦截代理来被动地扫描到Web应用程序的流量。 您可以通过此代理手动浏览应用程序，ZAP会分析每个请求和响应。
2. ZAP provides a web-spider that can analyze web pages by following links and references on a given page to explore an application automatically.
   ZAP提供了一个Web蜘蛛，它可以通过跟踪给定页面上的链接和引用来分析网页，从而自动浏览应用程序。
3. ZAP can also take an OpenAPI-Specification as input and check all the provided endpoints.
   ZAP还可以将OpenAPI规范作为输入并检查所有提供的端点。

Approach 2 and 3 can be integrated easily into a CI/CD-pipeline as they do not require manual browsing and I will focus on the in this story.

方法2和3可以轻松集成到CI / CD管道中，因为它们不需要手动浏览，我将在本故事中重点介绍。

进攻阶段 (The Attack Phase)

In the attack phase ZAP tries to exploit the known or suspected vulnerabilities detected in the explore phase to prove they exist. ZAP provides rules to do this for most common attack vectors and it can be extended using plugins. Thereby, two different cases of attacks can be distinguished

在攻击阶段，ZAP尝试利用在探索阶段检测到的已知或怀疑漏洞，以证明它们存在。 ZAP提供了针对大多数常见攻击媒介执行此操作的规则，可以使用插件对其进行扩展。 因此，可以区分两种不同的攻击情况

• A passive scan only performed nonharmful requests and can therefore also be used to scan public applications. However, even those requests can alter data in your application e.g. by performing valid DELETE requests.

  被动扫描仅执行无害请求，因此也可以用于扫描公共应用程序。 但是，即使是那些请求也可以更改您的应用程序中的数据，例如通过执行有效的DELETE请求。

• An active scan contains also potentially harmful requests like trying to trigger SQL-Injections. They must only be used with permission from the application owner.

  活动扫描还包含潜在有害的请求，例如尝试触发SQL注入。 仅在获得应用程序所有者的许可后才能使用它们。

报告阶段 (The Report Phase)

In the report phase, ZAP generates a report containing all the weaknesses detected. ZAP can produce different kinds of reports in different output formatting.

在报告阶段，ZAP生成包含所有检测到的弱点的报告。 ZAP可以以不同的输出格式生成不同种类的报告。

使用ZAP执行安全测试 (Perform security tests using ZAP)

To test ZAP I created a simple test application featuring a single page frontend build with Angular, a REST backend build using Spring Boot and OpenID-Connect for Authentication. You can find the source code as well as a readme at GitHub.

为了测试ZAP，我创建了一个简单的测试应用程序，它具有Angular的单页前端构建，使用Spring Boot和OpenID-Connect for Authentication的REST后端构建。 您可以在GitHub上找到源代码和自述文件。

基线扫描 (The Baseline Scan)

The easiest way to add ZAP to your pipeline is by using the so-called baseline scan. This is a preconfigured test provided in the ZAP Docker image. It spiders a web application, performs a passive scan, and generates various reports (see ZAP Documentation).

将ZAP添加到管道的最简单方法是使用所谓的基线扫描。 这是ZAP Docker映像中提供的预配置测试。 它搜寻Web应用程序，执行被动扫描，并生成各种报告(请参阅ZAP文档 )。

A baseline scan of a target running at http://localhost:8080 can be run using

可以使用http：// localhost：8080运行目标的基线扫描

An example of a generated report can be found at Github. It contains

可以在Github上找到生成报告的示例。 它包含了

• An alert of risk level medium that various sites in the application uses unsafe content security headers.

  风险级别中等的警报，指示应用程序中的各个站点使用不安全的内容安全标头。

• multiple alerts of risk level informal about potentially unwanted timestamps and comments in the angular scripts

  关于角度脚本中潜在有害时间戳和注释的多个风险级别非正式警报

While the first point is a real issue, the informal alerts were false positives. The angular scripts are autogenerated and do not contain comments nor sensitive timestamps.

尽管第一点是一个实际问题，但非正式警报是误报。 角度脚本是自动生成的，不包含注释或敏感时间戳。

However, all alerts were reported in angular scripts, none in the Rest-API. This begs the question if the Rest-API was even not found by the spider or if it's just that well made. Unfortunately, the standard ZAP reports cannot answer this question as they do not include a list of all URLs scanned.

但是，所有警报均以角度脚本报告，而Rest-API中没有报告。 这就引出了一个问题，即蜘蛛甚至没有找到Rest-API还是做得那么好。 遗憾的是，标准ZAP报告无法回答此问题，因为它们不包含所有扫描URL的列表。

输出扫描的端点 (Output Scanned Endpoints)

ZAP can be extended using so-called scan-hooks. These are little python programs changing the behavior of the pre-defined scans (see also ZAPs Documentation). Such a scan-hook can be used to generate an additional report with all URLs ZAP detected during the explore phase.

ZAP可以使用所谓的scan-hooks进行扩展。 这些是很少的python程序，可以更改预定义扫描的行为(另请参见ZAPs文档 )。 这种扫描挂钩可用于生成附加报告，其中包含在探索阶段检测到的所有URL ZAP。

The scan hook can then be included in the previous scan

然后可以将扫描钩包含在上一个扫描中

The report shows that only the static angular files were rescanned. The reason for this is the setup of the application. The Java-Script code will immediately redirect the user to the login screen and therefore the ajax spider is not able to find any of the used Rest-Endpoints. Unfortunately, this is not to easy to change without altering the application.

该报告显示仅重新扫描了静态角度文件。 这样做的原因是应用程序的设置。 Java代码将立即将用户重定向到登录屏幕，因此ajax蜘蛛无法找到任何已使用的Rest-Endpoint。 不幸的是，在不更改应用程序的情况下要更改它并不容易。

使用OpenAPI规范 (Using OpenAPI-Specifications)

The test application contains a Swagger-Endpoint providing an OpenAPI-Specification of all its REST endpoints. Instead of spidering, ZAP can also use this specification to analyze the application. Therefore, the ZAP Docker image provides the API-scan (see ZAP Documentation).

测试应用程序包含一个Swagger-Endpoint，它提供了所有REST端点的OpenAPI-Specification。 ZAP也可以使用此规范来分析应用程序，而不是使用蜘蛛程序。 因此，ZAP Docker映像提供了API扫描(请参阅ZAP文档 )。

An example of a generated report can be found at Github. It contains

可以在Github上找到生成报告的示例。 它包含了

• An alert of risk level low about a missing same-site attribute on the session cookie

  关于会话cookie上缺少相同站点属性的风险级别为低的警报

• An alert of risk level informal about a loosely scoped cookie (meaning the domain was not set specific enough)

  关于松散范围的Cookie的风险级别非正式警报(意味着该域设置得不够具体)

• An alert of risk level informal about error codes sent to the client.

  关于发送给客户的错误代码的风险级别非正式警报。

While the first two points are real issues the error codes are sent to the client deliberately. However, this points out another issue. The ZAP-Scan finds and accesses the Rest-Endpoints, but obviously the accesses are not authenticated as they are missing the authentication header. Therefore, only the “Not Authenticated” error messages were checked.

虽然前两点是实际问题，但错误代码是有意发送到客户端的。 但是，这指出了另一个问题。 ZAP扫描找到并访问了其余端点，但是显然访问没有经过身份验证，因为它们缺少身份验证头。 因此，仅检查“未经身份验证”错误消息。

If you check the list of scanned URLs, you can see that all the Rest-Endpoint were scanned. However, the URLs for those Endpoints contain parameters (like an ID) and those cannot be guessed by ZAP. Instead, ZAP will just send the name of the parameter as a value, leading to invalid requests in my case. See the generated URL-Report for an example.

如果查看扫描的URL列表，则可以看到所有其余端点均已扫描。 但是，这些端点的URL包含参数(例如ID)，并且ZAP无法猜到这些URL。 相反，ZAP只会将参数名称作为值发送，在我的情况下会导致无效请求。 有关示例，请参见生成的URL报告 。

添加身份验证 (Adding Authentication)

To add an authentication token, another scan hook can be used.

要添加身份验证令牌，可以使用另一个扫描挂钩。

The scan hook can then be included in the previous scan

然后可以将扫描钩包含在上一个扫描中

An example of a generated report can be found at Github. Additional to the previous results an alert of risk level informal about a potential timestamp in response was reported, however as for the potential timestamps in the angular scripts, this is a false positive.

可以在Github上找到生成报告的示例。 除先前的结果外，还报告了非正式的风险级别警报，以响应潜在的时间戳，但是对于角度脚本中的潜在时间戳，这是一个误报。

执行全扫描 (Perform a Full-Scan)

So far the tests performed only passive scanning. On an API-scan the active scanning can easily be enabled by omitting the -S flag

到目前为止，测试仅执行被动扫描。 在API扫描中，可以通过省略-S标志来轻松启用活动扫描

An example of a generated report can be found at Github. Additionally, to the results of the passive scan, the ZAP scan found an alert of risk level informal about unexpected content-type “text/HTML” in the 404 error page in case of an invalid URL. This is again due to the setup of the test application, as this error page is used for browsers where it makes send to show an HTML page.

可以在G ithub上找到生成报告的示例。 此外，对于被动扫描的结果，ZAP扫描在URL错误的情况下在404错误页面中发现了有关意外内容类型“文本/ HTML”的非正式风险级别警报。 同样，这是由于测试应用程序的设置所致，因为此错误页面用于其发送以显示HTML页面的浏览器。

结论 (Conclusions)

ZAP can easily be integrated into an existing CI/CD pipeline, either by running simple docker commands or by using a plugin to your CI/CD server and it provides fast feedback about potential security leaks to your developers. It can be used for any kind of web application and does not depends on additional infrastructure requirements. There really is no reason not to use it.

通过运行简单的docker命令或使用CI / CD服务器的插件，ZAP可以轻松地集成到现有的CI / CD管道中，并且可以向开发人员提供有关潜在安全漏洞的快速反馈。 它可以用于任何类型的Web应用程序，并且不依赖于其他基础结构要求。 确实没有理由不使用它。

Even in this simplest setup, ZAP can provide valuable feedback, e.g. in my case the weak content security policy. However, to get the optimum out of it, you need to teak ZAP to your specific setup. Especially, you will need to address the following points:

即使在这种最简单的设置中，ZAP也可以提供有价值的反馈，例如，在我的情况下，内容安全策略薄弱。 但是，要获得最佳效果，您需要将ZAP柚木化为您的特定设置。 特别是，您将需要解决以下几点：

1. How does ZAP access your application? If e.g. a login, complex user interaction, or solving a Captcha is required to access certain parts of your application, ZAP must be able to perform or bypass these checks.
   ZAP如何访问您的应用程序？ 如果需要登录，复杂的用户交互或解决验证码来访问应用程序的某些部分，则ZAP必须能够执行或绕过这些检查。
2. How is your application analyzed? While the spider seems to do a good job on a traditional webpage, it obviously gets trickier on a javascript based single page application (SPA). If complex user interaction is needed to access parts of your application (e.g. filling out a form) the spider stands no change. The API-scan on the other hand cannot guess path variables with valid values and will therefore often perform invalid requests.
   您的应用程序如何分析？ 尽管蜘蛛似乎在传统网页上做得很好，但显然在基于JavaScript的单页应用程序(SPA)上变得更加棘手。 如果需要复杂的用户交互来访问应用程序的各个部分(例如，填写表格)，则Spider不会发生任何变化。 另一方面，API扫描无法猜测具有有效值的路径变量，因此通常会执行无效请求。
3. How do you check if ZAP is running properly? Normally ZAP only reports the endpoints where potential security risk has been identified. However, it is also important to check which endpoints it has actually found. After all, if ZAP does not find the sensitive endpoints to your application it’s easy not to find any security risks.
   如何检查ZAP是否正常运行？ 通常，ZAP仅报告已识别出潜在安全风险的端点。 但是，检查其实际找到的端点也很重要。 毕竟，如果ZAP找不到应用程序的敏感端点，那么很容易就不会发现任何安全风险。
4. How do you deal with the finding? ZAP will often return false positives or accepted risks, so your developer will need a simple way to remove those from the report, otherwise the new and important security risks are hard to find within the noise. However, distinguish potential risks and false positives is hard, so your developers will need training and support to do so.
   您如何处理此发现？ ZAP通常会返回误报或接受的风险，因此您的开发人员将需要一种简单的方法从报告中删除那些错误消息，否则，在噪声中很难找到新的重要安全风险。 但是，很难区分潜在风险和误报，因此您的开发人员将需要培训和支持。

Besides the spider and the open API-specification also using automated end-2-end tests performed through the ZAP-Proxy can be used to analyze an application. This could drastically improve the performance regarding the first 3 points, as (assuming those tests covers all important parts of your application) as they provide ZAP with a full picture of your application, automatically perform or bypass logins. I will investigate this possibility in a follow-up story.

除了蜘蛛程序和开放式API规范外，还可以使用通过ZAP代理执行的自动化2端到2端测试来分析应用程序。 这可以大大提高前三点的性能，因为(假设这些测试涵盖了应用程序的所有重要部分)因为它们为ZAP提供了应用程序的全貌，自动执行或绕过登录。 我将在后续故事中研究这种可能性。

链接 (Links)

翻译自: https://codeburst.io/automated-security-testing-in-agile-software-projects-53222a5f5cf9

自动化敏捷测试方法