return
Improving the security of web applications is an important aspect of the operations of the software development process. In order to carry forward and maintain order in security testing, OWASP has the Web Security Testing Guide (WSTG). It provides comprehensive guidance for security professionals and developers.
This post aims to present a simple guide to deploy and leverage WSTG v4.2 features in your organization.
Main features
The test framework approach is intended to convey in an orderly fashion the What? Why? When? And Where? of web application security testing.
Within the What, we can find systems and applications that will be compared with a set of criteria through a procedure that allows to ensure confidence, in this approach we find the triad of People, Processes and Technology. The focus is not only technical, but also on management and operation.
Within the When can we align to our software development cycle (SDLC), whatever methodology we are adopting, the objective is to consider times when improving security is "cheaper" in terms of overall effort.
In addition, the WSTG has specifically designed features, the latest of its updates includes the introduction of new test scenarios, including testing, for example, on GraphQL APIs. This serves to provide a more comprehensive security testing approach covering the latest web technologies.
To enable a more systematic testing process, objectives have also been added to all scenarios. The importance of these objectives is that they provide the test team with clear goals and expected results for each test scenario.
The reading experience has also been significantly improved by standardizing the scenario formats. This makes it easier for your team to understand and follow the test guide.
Test Framework Structure
The WSTG is structured in 5 phases marked by different typical stages of the software development cycle:
Phase 1: Before development begins
Test planning includes not only aligning to the current SDLC framework but also the review of policies and standards that are applicable to the application to be tested, its existing documentation and the definition of metrics or elements to be measured in order to evaluate test compliance.
Phase 2 During definition and design
In this phase the security objectives and requirements to be evaluated are defined, including current security mechanisms such as: User Management, Authentication, Data Confidentiality, Communications Security, Integrity, among others.
Application design and architecture are also evaluated in contrast to threat models, with the objective of finding gaps in the initial and fundamental stages of development.
Phase 3 During development
Quick code reviews are performed in a "tutorial" format to understand the general structure and then drill down with specific reviews where necessary (this is where OWASP Top 10 comes in!).
Phase 4 During implementation
At this stage we already have some functional part of the application on which to perform "dynamic" tests. We test the design through penetration tests or functional tests of different types.
Phase 5 During maintenance and operations
This phase is usually the most complicated to support or guarantee, it contemplates everything that happens after the deployment of the application, as periodic evaluations are carried out to ensure the maintenance of the security level obtained during the tests.
Implementation of WSTG
To deploy WSTG in an organization, in a simplified and general way, we propose the following steps:
Preparation:
• Know your objectives: Understand what you want to achieve with security testing. This could include identifying vulnerabilities, complying with specific regulations, or simply improving the overall security of your web application. You can frame your planning by modeling threats and defining some metrics that you consider relevant to your business.
• Gather information: Gather information about the application you are going to test. This includes URLs, technologies used (e.g., frameworks, databases), and any other relevant information.
• Get permission: Make sure you have explicit permission to perform security tests on the web application. Testing without consent may be outside the legal framework or ethically incorrect.
Configuration of the test environment:
• Tools: Install the necessary tools to perform the tests, such as vulnerability scanners, interception proxies (e.g. OWASP ZAP, Burp Suite), and static or dynamic code analysis tools (OWASP has a list of options for each case).
• Test environment: When possible, set up a test environment that is an exact replica or representative of the production environment. This allows you to test without risk of affecting the data or availability of the production system.
Tests execution:
• Recon Tests: Start with recon tests to gather more information about the application, such as identifying entry points, exposed services and software versions. Within these tests you can perform a source code review directly, which will allow you to get a more detailed look at the application or piece of code being evaluated.
• Vulnerability testing: Use the OWASP WSTG Testing Guide as a reference to perform specific tests, such as SQL injection, cross-site scripting (XSS), insecure authentication and session handling, security misconfiguration, and sensitive data exposure, among others. Each of these tests will contain a look at the threat point of view and a set of possible mitigations applied at some point in the development cycle.
• Automation and manual testing: Combine the use of automated tools with manual testing for more complete test coverage. Tools can help you identify known vulnerabilities, while manual testing is crucial to identify logic problems and other issues that tools cannot detect. Within the testing approaches we can find:
• Identity, authentication and access control
• Input validation
• Encryption
• User and session management
• Error and exception handling
• Logs and auditing
Vulnerability reporting and remediation:
• Document your findings: Create a detailed report of the vulnerabilities found, including severity, problem description, and recommendations for remediation.
• Communicates results: Presents results to relevant teams (development, safety, operations) and discusses corrective actions.
• Vulnerability remediation: Work with the development team to remediate identified vulnerabilities. This may include modifying code, changing configurations, or patching third-party components.
Verification and monitoring:
• Verification of fixes: Once the fixes have been applied, perform follow-up testing to verify that the vulnerabilities have indeed been resolved.
Conclusion
The WSTG v4.2 guide is a valuable resource for improving the security of your organization's web applications. Its simplified methodology and scope make it applicable to organizations of all sizes. Remember that web application security is not a one-time event, but an ongoing process.
Stay up to date and secure.
