Red Hat Product Security has been developing RapiDAST, a tool that can be used for security testing of products and services. It is also helpful for developers or quality engineers (QEs) to test the security of products during the software development life cycle (SDLC).
As the name suggests, RapiDAST is focused on performing rapid (automated) dynamic application security testing (DAST). While there are many security practices we can consider comprehensively for improving security posture of development environments — threat modeling, software composition analysis (SCA), static application security testing (SAST), fuzzing, penetration testing, etc. — this article focuses on DAST.
What is dynamic application security testing?
DAST stands for dynamic application (or analysis) security testing, and is a blackbox testing methodology used to uncover potential security flaws by performing automated security scanning against a running target.
This is opposed to SAST, which scans source code to identify security issues. Since DAST actually tests the running target, it produces fewer false-positives than SAST. DAST can also identify runtime and environment-related issues such as misconfiguration, which is almost impossible to detect in source code.
While DAST can broadly refer to any security testing that can be used against any runtime targets, and while it does not necessarily have to target web technologies, most DAST tools are focused on web scanning. This is because of the prevalence of web applications and services that include APIs over the last few decades. Mobile backend services can also be a target of DAST, as they are generally implemented as web services.
DAST generally comes into play in the testing phase when it comes to SDLC. Since DAST requires a running target, DAST is used after the application’s code has been built and deployed to a test environment or to a staging or integration environment. Collaboration between developers and QEs is useful for DAST, and is cost-effective.
Application programming interface (API) security
Many modern web services are being developed as microservices. A microservices architecture is one in which multiple services are implemented separately and communicate with each other. Generally, such microservice architectures heavily rely on APIs for this communication. As more services are implemented with APIs, securing APIs is becoming increasingly important as well.
Three phases of automated DAST scanning
1. Identify endpoints
In order to improve the security of something, the first step is to identify what actually needs to be secured. API scanning starts with identifying endpoints, called attack surfaces, where attackers input malicious data — such as URLs and parameters — in an attempt to compromise the web application. It should be noted that any data in the web requests can be freely modified by attackers.
To automatically identify web endpoints, most DAST tools employ crawling or a spider feature. API endpoints can be difficult to identify with crawling, however API scanning can be done effectively by taking advantage of OpenAPI. See the OpenAPI-based scanning section below for more details.
2. Send requests
Once the endpoints have been identified, DAST tools start sending lots of requests that simulate real attacks. To reach the protected contents, the tools can use established sessions that are normally implemented with cookies or tokens, or even guide users to login to the target.
APIs generally rely on tokens for authentication, whereas most traditional web applications typically use cookies. In some cases, both authentication techniques are used for the same website. It is not uncommon to see the frontend application use a cookie and the backend API use a token at the same time.
3. Analyze results
The previous phase results in a lot of responses and results. Analyzing them, with configured scanning rules, can detect security vulnerabilities such as SQL injection and cross-site scripting (XSS), in addition to many other weaknesses such as misconfiguration issues.
What is RapiDAST?
RapiDAST (Rapid DAST) is an open source project to develop a DAST tool that Red Hat Product Security has been working on, hosted on GitHub. RapiDAST is evolving, but at this stage it is focusing on scanning APIs as effectively and conveniently as possible through automation. The project is currently making use of OWASP ZAP — a popular open source web security testing tool — as its core engine.
OpenAPI-based scanning
As mentioned above, OpenAPI can be used to identify API endpoints. The OpenAPI Specification — formerly known as Swagger specification — is quite popular in terms of describing RESTful API interfaces. The specification is in a standardized format that is not only human readable, but also can be easily used by machines or tooling for automation.
OpenAPI enumerates all the API endpoints, methods and parameters including useful information such as whether a parameter is sent in a URL path, in a query string, or in request body, and whether a parameter type is string or integer. Such a collection of information can be written into a file called OpenAPI definition.
Example of OpenAPI definition
If there is an OpenAPI definition available (which many API development projects have), RapiDAST will take advantage of it to automatically get to know all of the API’s endpoints and parameters. RapiDAST can then proceed with scanning and generating scanning reports.
Continuous security scanning with RapiDAST
“Secure development” is a hot topic these days, especially with the U.S. President’s Executive Order for Cybersecurity issued in 2021, and Red Hat Product Security has been working hard to provide a SDLC framework that drives greater software security. As part of this, DAST is being used in many Red Hat products’ SDLCs.
Using RapiDAST enables the developers and QEs to identify security issues at an earlier phase of the SDLC, and it is currently being used successfully within Red Hat. For example, RapiDAST is used to continuously scan many Red Hat managed services running on console.redhat.com or api.openshift.com.
Services running on console.redhat.com
Using RapiDAST, with a simple script run based on a YAML configuration file, users can get scanning results.
Here is an example of a RapiDAST scan.
$ scan-example-with-podman.sh testscan Deleting previously generated scripts Loading the script to ZAP Templating script Rule_Gen_05eec230-5ba0-4bf5-b1d0-43268b8542d2 Loading script Rule_Gen_05eec230-5ba0-4bf5-b1d0-43268b8542d2 in ZAP from /tmp/Rule_Gen_05eec230-5ba0-4bf5-b1d0-43268b8542d25k5s0yj7.js Enabling script Rule_Gen_05eec230-5ba0-4bf5-b1d0-43268b8542d2 in ZAP Script Rule_Gen_05eec230-5ba0-4bf5-b1d0-43268b8542d2 successfully loaded and enabled Creating session in: /zap/results/testrun/sessions/20211210-041924/session1 Excluded URLs: ^(?:(?!http://192.168.109.202:9000).*).$ Include URL in context: http://192.168.109.202:9000/api/.* Exclude URL from context: Importing API: /zap/config/oas/openapi.json >> Target Url: http://192.168.109.202:9000 Start Active scan. Scan ID equals 0 Scan Policies: ['API-minimal-example'] Active Scan progress: 0% Active Scan completed Waiting for Passive Scan to complete Passive Scan completed XML report saved in: /zap/results/testrun/demo1-report-20211210-041924.xml
The logs give you an overview of how it works:
Load custom scanning rules (RapiDAST can be extensible)
Import OpenAPI
Perform scanning against a target with a scanning policy
Save a scanning report
RapiDAST can generate reports in XML, HTML and JSON, thanks to OWASP ZAP’s report feature.
RapiDAST operator running on Kubernetes or Red Hat OpenShift
RapiDAST has recently evolved to be running as an operator on Kubernetes or Red Hat OpenShift. This can add more scalability and stability for your “shift left” projects. Also, Red Hat Product Security is actively participating in the Operate First community, with the goal of delivering greater security to open source projects that are running on the community clusters.
rapidast-operator running on Operate First cluster
Security and cross-team collaboration
Taking care of security is no longer a blocker that delays development. Nowadays, many experts emphasize the importance of “shift left” or DevSecOps, and success relies on cross-team collaboration. Both security engineers and development teams (including developers and QEs) have to work together to apply RapiDAST into SDLC.
Here’s an example of what cross-team collaboration workflow might look like:
Developers develop a project with OpenAPI
QE teams help with scanning on running target environments
CI/CD teams may provide infrastructure for continuous scanning
Security engineers analyze and manage in case of security issue
This sort of collective, collaborative effort to shift security left makes it significantly more likely that security issues will be identified much earlier in the software development life cycle, saving both time and effort on all sides.
Conclusion
In this article, we introduced the RapiDAST tool and ideas for cross-team collaboration that can help you with applying DAST into your software development life cycle. While we focused on API security so far, RapiDAST is going to have more useful features soon. We are already on the journey!
Learn more
저자 소개
Jeremy Choi is a Principal Product Security Engineer in Red Hat Product Security. Since joining Red Hat in 2011, Choi has been an active contributor to both Red Hat products and open source projects.
채널별 검색
오토메이션
기술, 팀, 인프라를 위한 IT 자동화 최신 동향
인공지능
고객이 어디서나 AI 워크로드를 실행할 수 있도록 지원하는 플랫폼 업데이트
오픈 하이브리드 클라우드
하이브리드 클라우드로 더욱 유연한 미래를 구축하는 방법을 알아보세요
보안
환경과 기술 전반에 걸쳐 리스크를 감소하는 방법에 대한 최신 정보
엣지 컴퓨팅
엣지에서의 운영을 단순화하는 플랫폼 업데이트
인프라
세계적으로 인정받은 기업용 Linux 플랫폼에 대한 최신 정보
애플리케이션
복잡한 애플리케이션에 대한 솔루션 더 보기
오리지널 쇼
엔터프라이즈 기술 분야의 제작자와 리더가 전하는 흥미로운 스토리
제품
- Red Hat Enterprise Linux
- Red Hat OpenShift Enterprise
- Red Hat Ansible Automation Platform
- 클라우드 서비스
- 모든 제품 보기
툴
체험, 구매 & 영업
커뮤니케이션
Red Hat 소개
Red Hat은 Linux, 클라우드, 컨테이너, 쿠버네티스 등을 포함한 글로벌 엔터프라이즈 오픈소스 솔루션 공급업체입니다. Red Hat은 코어 데이터센터에서 네트워크 엣지에 이르기까지 다양한 플랫폼과 환경에서 기업의 업무 편의성을 높여 주는 강화된 기능의 솔루션을 제공합니다.