The Open Web Application Security Project (OWASP) is one of the most well-known organizations that aims to improve the security of software. Most security professionals are familiar with the popular OWASP Top Ten (the top 10 web application security risks). But OWASP also runs a large number of additional security projects (documentation, frameworks and tools), for the various phases of the Software Development Life Cycle (SDLC). In this blog we will talk about the Web Security Testing Guide (WSTG), which is a great resource for security professionals.
What is the Web Security Testing Guide (WSTG)?
OWASP has compiled a wealth of cybersecurity knowledge and know-how from both professionals and volunteers. The result: the Web Security Testing Guide (WSTG) – an excellent guide for web application testing that anyone can read and consult with freely. The OWASP Web Security Testing Guide (WSTG) is a comprehensive guide for testing the security of web applications. It describes techniques, methods, tools and resources for testing most common web application security issues.
WSTG’s current version is 4.2. It is web-hosted and also has a PDF document version. You can also access version 5.0 that is currently being developed and is continually updated. Since new attack vectors and new methods for attacking web applications are discovered daily, we recommend using this latest online version.
Where Does WSTG Fit in the OWASP Testing Framework?
The OWASP Testing Framework consists of activities in any phase of the SDLC:
Before Development Begins:
During Definition and Design
Reviewing Security Requirements
Reviewing Design and Architecture
Creating and reviewing Threat Models
During Development
Code Walkthrough
Code Reviews
During Deployment
During Maintenance and Operations
This framework is complete and integral, and can be adopted in any organization, no matter its size.
The WSTG focuses on the deployment phase, and specifically on Application Penetration Testing. After the development phase has been completed, Penetration Testing provides an additional check to ensure all security requirements are met and the application does not have relevant security bugs or vulnerabilities. WSTG fully helps the testing team complete this task in the best way.
WSTG Scope
The WSTG covers the following topics:
Information Gathering – In this section the guide includes tests to obtain information about the web server, the application and the application architecture.
Configuration and Deployment Management Testing – Tests for Network configuration, Application Configuration, HTTP enumeration and recently also topics like Subdomain Takeover and Cloud Storage. This is an example of how complete and updated this guide is!
Identity Management Testing – Tests for role definitions, user registration and account enumeration.
Authentication Testing – For Default Credentials, Weak Lock Out, Weak Password Policy and so on.
Authorization Testing – Directory Traversal File Include, Privilege Escalation and Insecure Direct Object References (IDOR).
Session Management Testing – Tests for Session Fixation, Cross Site Request Forgery, Session Hijacking and JSON Web Tokens.
Input Validation Testing – Covering Cross-Site Scripting (reflected and stored), all types of Injection including Server-Side Template Injection, File Inclusion and Server-Side Request Forgery.
Testing for Error Handling
Testing for Weak Cryptography – Covers Weak Transport Layer Security and Weak Encryption.
Business Logic Testing – For the tester to find flaws in business logic. Here is an example: the application needs the user to execute step 1 to continue with step 2. If we find a to execute step 2 without doing step 1, this is a flaw. There is no specific method you can apply to find this kind of vulnerability, but WSTG describes procedures for testing.
Client-Side Testing – Examples are: DOM Cross-Site Scripting, HTML and CSS injection, Cross Origin Resource Sharing (CORS) and Clickjacking.
API Testing – Testing GraphQL.
Generally, each test topic has these sections:
Summary
Test Objectives
How to Test
Remediation
Tools
References
There are also some interesting appendices. Here you will find useful information and references about:
Links to Testing Tools: OWASP ZAP, Burp Suite, Firefox and Chrome Extensions, sqlmap, John the Ripper, hashcat, Wfuzz, wget, Kali, Parrot, and so on.
Links to main Payloads for testing: Fuzz Vectors, payloads for Cross Site Script (XSS) testing, Injection and others.
Information and references on Encoded Injection
There is a lot of information and resources. Most of them are detailed, of great quality and updated.
To have an idea of the guide, let’s review some samples.
Test Cloud Storage
Nowadays, cloud services are very common – especially storage services. Security configurations are necessary, but in some cases, users publish cloud storage services (like Amazon S3 buckets) with misconfigurations. As a result, an attacker can access and modify the information published.
WSTG establisesh two tests. These can be executed using CURL or AWS-CLI (AWS Command Line Interface for managing AWS services):
This can be done using CURL:
curl -X GET https://<cloud-storage-service>/<object>
Or AWS-CLI:
aws s3 ls s3://<bucket-name>
An example of this:
curl -X GET /mybucket/userlist.txt
curl -X PUT -d ‘test’ ‘https://<cloud-storage-service>/test.txt’
With AWS-CLI:
aws s3 cp arbitrary-file s3://bucket-name/path-to-save
Example:
curl -X PUT -d ‘test’ /mybucket/test.txt
How are buckets identifed? WSTG recommends reviewing documents, HTTP messages, source code or other available sources. An example we can find in a Page Source is:
…
<img src=" https://s3.amazonaws.com/mybucket/toys.jpg">
…
To complete this information (not included in the guide), I can mention that there are tools for finding buckets like Bucket Finder.
Testing JSON Web Tokens
JSON Web Tokens (JWT) is a standard for transmitting JSON objects that can be verified and trusted because they are digitally signed. As a result, they are commonly used in web applications as authentication or session tokens.
As other standards it might be vulnerable depending on how they are implemented and the libraries used.
JWT has three components:
Header: Defines the type of token and the algorithm being used for the signature.
Payload: The data itself.
Signature: This is created using the header information, and is used to verify the message wasn’t changed. Any change in the header or payload results in an invalid signature.
If you want to build a JWT for testing you can do it online at https://jwt.io (this section is missing in WSTG).
WSTG proposes the following tests:
Testing signature verification. Verify if the application fails to validate the signature. This occurs when developers use the jwt.decode() function rather than jwt.verify().
The None Algorithm. Changing the algorithm to “none” can produce a valid verification:
{
"alg": "none",
"typ": "JWT"
}
Weak HMAC Keys. In this test we can try to crack the key with tools such as crackjwt.py and John the Ripper.
HMAC and Public Key Confusion. This occurs when the application expects the JWT to be signed with a public key algorithm but does not check the algorithm that has been used. The attacker changes the algorithm and the public key to generate a valid JWT.
WSTG also gives us additional tools (Burp Suite extension and ZAP add-on) that we can use for testing. There are also remediation tips including a JSON Web Token Cheat Sheet with plenty of information and details to review.
These are only samples but they should give you an idea of the contents of the WSTG.
How to Get Started With WSTG
Where should you start? The WSTG guide can be very intimidating due to the scope and quantity of information it has. Let’s discuss ways to implement WSTG and integrate it to your SDLC.
Integrating WSTG to Your SDLC
Here are my recommendations for a successful WSTG implementation:
Security Training – Developer and testing teams should be trained periodically on the WSTG, and the tools selected for the tests. Although WSTG is testing oriented, the guide includes recommendations and useful documentation for developers.
Prioritize your Tests – It is impossible to apply all WSTG tests at the beginning of your integration project. First, you should choose the tests that are appropriate for your organization and can answer the bigger risks. Give your team time for mastering the tests. Then, gradually add more tests to your SDLC according to your organization’s resources. Take into consideration that your development team will need to remediate these issues, which will also affect your software development process.
To identify which test are suited for your organization to initiate your WSTG project with, we recommend choosing:
Tests that are related to your application architecture and the information the organization protects. For example, if your application uses S3 buckets, then it is relevant to include Test Cloud Storage in your scope.
Tests related to OWASP Top Ten. These will cover the most relevant vulnerabilities in applications.
Tests in which the testing team has more expertise. As the testing team get trained and has more experience they can gradually add more tests in their scope.
Implement WSTG with other OWASP projects – The WSTG focuses on application testing, but OWASP has projects for different SDLC phases in addition to testing. For example, OWASP Application Security Verification Standard (ASVS) is a great resource for defining security requirements and is a basis for testing applications. The idea is to improve not only one part of the SDLC, but as many as the organization can, while optimizing your efforts. There are a lot of OWASP projects you can select to complement your WSTG implementation. Recommended are OWASP Top Ten, OWASP Application Security Verification Standard (ASVS) and the Cheat Sheet Series.
Assign a WSTG Champion, a member of your team that is the most skilled and knowledgeable in WSTG. This role will help all teams to support your implementation project.
Periodically monitor your results and report them to management. Indicators like “Number of vulnerabilities found by severity” can show you how the testing team is finding real vulnerabilities and how security practices are improving the security of your web applications.
By the way, these recommendations also apply for most security projects.
WSTG for Individual Testers and Pentesters
All WSTG documents can be reviewed by professionals, investigators and students. The information provided enables doing a very good job of penetration testing. For specialized Pentesters and Bug Bounty hackers, we recommend complementing the tests with other resources and recent publications about vulnerabilities and new testing methods. For example, about the Apache Log4J vulnerability publicly disclosed in December 2021 (CVE-2021-44228).
Improving Application Security
The OWASP WSTG is a centralized, organized and updated repository of quality information about application penetration testing. After running penetration tests, IT and security teams can remediate the findings with zero trust, a security model for secure access management and critical application protection. Learn more.
