How to use automated Dynamic Application Security Testing in PWSLab?
In a Rapid Application Development Cycle, security teams often initiate DAST tools to locate vulnerabilities just before the launch of a new product or a new version of the previously-launched product. This became non-scalable and extremely time-consuming and costly, mainly with strict sprints for quick releases with no substantial long-term security-related benefits. Fortunately, PWSLab could automate Dynamic Application Security Testing, with ZAP - a leading OWASP DAST Security tool.
PWS DAST is primarily used to identify serious security vulnerabilities in runtime when the application is deployed to Staging/UAT/Test environments before production deployment.
PWS DAST Features
- Automatically identify security vulnerabilities like SQL injections, Click-jacking, in your web applications while you are developing and testing your applications.
- AJAX spidering is performed during a penetration test to discover requests on an AJAX-rich web application, which cannot be discovered with the regular Spidering tool.
- Testing of Websockets is very critical in today’s day and age with its pervasive implementations across applications. With DAST, intercepting, analyzing or tampering the WebSocket traffic between the client and server can’t be any easier!
- Fuzzing payload lists to inject a variety of payloads to force the application to go to an undesired state, possibly exposing a potential vulnerability.
- Authentication and Session support to crawl resources that are otherwise not viewable directly to the Spider.
SPIDER is a tool that is used to automatically discover new resources (URLs) on a particular site. It begins with a list of URLs to visit, called the seeds, which depends on how the Spider is started. The Spider then visits these URLs, it identifies all the hyperlinks in the page and adds them to the list of URLs to visit and the process continues recursively as long as new resources are found.
Note: It should be noted that DAST can only find certain types of vulnerabilities. Logical vulnerabilities, such as broken access control, will not be found by any active or automated vulnerability scanning. Manual penetration testing should always be performed in addition to DAST to find all types of vulnerabilities.
How to identify vulnerabilities in Runtime?
PWSLab fits DAST perfectly into the CI/CD workflow for vulnerabilities detection in runtime before they make their way to production.
Generally, it is configured in such a way that once the application is deployed in the UAT/Staging environment, the DAST job is triggered to crawl and identify vulnerabilities. If any authentication protocols are specified they are used to crawl the pages. Once the Spider crawls the application, it then renders all the vulnerabilities metrics to PWSLab, which are further exported as HTML report to PWSLab Job Artifacts.
After running the PWS DAST job, PWSLab writes the reports into Job Artifacts as
pws_dast_report.html. Open it and start investigating the issues.
For PWS DAST configuration in your PWSLab project's pipeline, please raise a DevSecOps Support Request.
Support Ticket Guidelines and Information Required
PWSLab Job Environment Variables:
Please raise a DEVSECOPS Support Request in the PDS Department providing the below information:
|Set "true" or "false" for receiving DevSecOps Reports as an email notification|
Set the Email Recipient for receiving Report Email notifications if PWS_EMAIL_STATUS is set as "true"
Set PWSLab Docker Hub Username
Set PWSLab Docker Hub Password
Pass the Target URL for DAST testing
Set the Login URL of the Target application for DAST
Set the Login URL Username of the Target application for DAST
Set the Login Password of the Target application for DAST
Set the Username's HTML field name of the Target application for DAST
Set the Password's HTML field name of the Target application for DAST
Set this variable "true" to disable the DAST job.
- Which environment/s or URLs do you want the PWS DAST to be configured for, share any extra target application authentication information if required to run the tests?
- Do you want this job to run on UAT/STAGING (or other test deployment environments) or every time a code-commit is pushed?
- Do you want this job to run for a specific branch like UAT after merge requests are accepted by maintainers? So, before anything is merged to MASTER, it is verified by DAST.
Have any more questions? Please email us at firstname.lastname@example.org or raise a PDS Support Request.
Also, let us know if the article is helpful!