The Testing Guide is broken up into distinct phases. Within Dradis, each testing phase is given a section in our methodology template with the individual tasks needed to complete each section. Below is an overview of each phase of testing. For more details, visit the OWASP website.

---

Information Gathering

During the information gathering phase, the tester gets a high-level view of the server, the application, and gathers information for the next phases of the test. The tests in the information gathering phase should allow the tester to collect basic data like the web server version and type of a running web server, figure out what web applications are hosted on a web server and the frameworks used for those applications, understand typical requests/responses and map the application, and check search engines, robots.txt files, folder paths, commments, metadata, and more for information leakage.

---

Configuration and Deployment Management

This phase builds on the information gathered previously to start digging deeper. The tester has already mapped out the application, now they dig into how the infrastructure identified impacts the application security (e.g. testing for known vulnerabilities).

Next, the focus switches back to the server, looking at and testing aspects like the platform configuration and architecture, then testing how the server handles different file extensions, and finally checking "forgotten" files for important data. The tester also looks for administrator interfaces in the server or the web application that can be exploited.

Finally, the tester puts their focus back on the web application itself by testing to see what HTTP methods are supported by the web server, testing whether HSTS header is present, and testing for cross-site or cross-domain policies that they can exploit.

---

Identity Management Testing

This section deals with account, priviliges, and access. The tester spends most of their during this phase on the login page working to understand how the application allows users to sign up and whether this system can be exploited if you know part of the login information (like the username).

During the configuration and deployment management testing, the tester looked for administrator interfaces. During Identity management testing, all possible application roles (user, administrator, author, etc) are to understand what access or priviliges come with different roles.

Next, the tester checks the requirements and the process to create an account and how accounts are deleted. Finally, the tester digs into the system to prepare for future tests by checking whether error messages give clues about existing usernames and trying to find username patterns to help them find those existing usernames and accounts.

---

Authentication Testing

Identigy Management testing is all about understanding the user accounts, usernames, and roles. However, during Authentication Testing, the tester is almost completely focused on passwords.

The tester spends time looking at default and simple username/password combinations. How many systems can you log in using the username/password combination of administrator/password123 or a similarly simple combination? You'd be surprised. Because of this, the tester also checks password strength rules during this phase of testing because without rules to force complexity, the average user will default to passwords like "password" and "qwerty".

Test lockout mechanisms. Strong security measures should include a lockout measure so that multiple incorrect login attempts kick the user out and prevent them from trying to log in again for a period of time. This measure prevents a brute-force attack where an attacker bombards the application with password guesses until they guess the correct password and gain access.

Most applications have security questions to help verify your identity in case you need to reset your password or if you log in from a new system. These questions can be an important security measure but if the answers are easily guessable (e.g. "what's your favorite color?"), they aren't going to be particularly effective. The tester looks at the strength of the existing questions to see whether they can be exploited to give an attacker access.

The tester also looks at more technical aspects like whether a user's login data is transmitted via an encrypted channed or in a non-secure clear text form. Or, whether it is possible to bypass the login process altogether. They check whether the browser cache and history store any sensitive data. If they do, this data is easily accessible through something as simple as the "Back" button. They also examine how passwords are stored to make sure they aren't in clear text form that is vulnerable to attackers. And, the tester examines the password reset process to see whether any aspects of the process are insecure.

Finally, the tester repeats this whole process for any alternative login channels. In some cases, users may be able to log in through the main website, a mobile-optimized version, a mobile application, or a host of other similar alternative channels. All of the different channels need to be tested for security vulnerabilities.

---

Authorization Testing

These tests focus on how web applications authenticate access to file systems.

The tester looks for common vulnerabilities like path traversal or file include flaws. The tester also tries to bypass authorization schemes and verifies how every function of the application is affected by user role, authentication status, and other authorization factors.

Testing for vertical privilege escalation (e.g. gaining Administrator access as an Author) or horizontal privilege escalation (e.g. gaining access to another Author's account).

---

Session Management Testing

After spending a good amount of time on the login process, the tester checks the logout process in more depth during this phase of testing. Applications allow users to stay logged in for a certain amount of time but if the cookies or session tokens aren't secure, an attacker could hijack legitimate sessions. The tester also checks that session time-out is in place so that a user is automatically logged out after a certain period of time without activity. And, the tester checks the entire logout process to make sure that sessions are effectively terminated.

The tester also checks for common problems related to user sessions. The first is session variable overloading. If the application uses the same session variable for multiple purposes, an attacker could exploit this and gain access to unintended (more priviliged) locations. The tester also looks for potential sross-site reuqest forgery (CSRF) which can force a logged-in user to execute actions within the application. Often, links are sent via email or social media and if clicked, the user has no control over the actions performed (like changing their email address or even transferring money).The tester also looks to see whether session tokens like cookies or session IDs are exposed. If they are, an attacker may be able to impersonate a user to access the application. Then, the tester checks the specific attributes of the cookies to ensure they are adequately protected.

---

Input Validation Testing

In this phase, the tester goes through a total of 15 different input validation tests looking at everything from Cross-site scripting (XSS) to SQL injection. Why? Input validation is the most common web application security weakness. If all of the data coming from the client or from the environment isn't being validated before it's used, the application is vulnerable a host of different issues.

In the words of Michael Howard, "All input is evil."

---

Testing for Error Handling

The way that errors are handled by the application can reveal useful information to an attacker. The tester checks whether it is possible to access any stack traces or find relevant information within them. They also look at all of the error codes they come across while testing to try to get more information about the technologies used in the application, bugs, or databases.

---

Testing for Weak Cryptography

The tests in this phase can be summarized with the question: "is sensitive data protected?". The tester checks whether and how sensitive data is being protected during transmission and whether it is possible for an attacker to decrypt the encrypted data.

---

Business Logic Testing

The tests in this phase require the tester to "think outside the box" and try to break the application security measures by bypassing the normal processes or patterns. These tests cannot be automated like many other tests can be. Instead, the tester has to try to "outsmart" the application design. This set of tests also draws heavily from the information gathered in earlier phases of testing. The better the tester understands the logic and processes of the application, the better chance they will have to identify creative ways to "break" it.

---

Client Side Testing

The final phase of testing involves executing code within the browser rather than on the server.

The tester looks at a variety of different client-side aspects of the application to check for common vulnerabilities. Many of the vulnerabilities tested in this phase are related to cross-site scripting (XSS) or injection.

---

The above is a condensed overview of the OWASP Testing Guide v4, visit the OWASP website for more details.