In our bank robbery metaphor, the big day has finally arrived! Now’s the time to put our plan into action.
We’re now ready to move on to the most technical phase of web penetration testing: the search for vulnerabilities in the application. We may have already found some during the mapping and reconnaissance phases, but the bulk of the work starts here.
Learn About the Most Common Vulnerabilities
In this fourth part of the course, we’re going to take a look at the main vulnerabilities found in web applications—in other words, the most frequently identified ones.
There are many families of vulnerabilities that exist. Within these family groups, there are subgroups, and for each subgroup, there may be specific features linked to the technology used by the application.
Take injections, for example. This is a large family of vulnerabilities, grouped together under the category A03:2021-Injection:
Client-side injections.
Server-side injections.
SQL injections:
Error-based SQL injections.
Boolean-based SQL injections.
Time-based SQL injections.
Command injections.
XXE injections.
Let’s start with the first type of vulnerability: XSS injections.
Manipulate Users with XSS
XSS injections are known as client-side injections. This is because they affect the application’s client (i.e., its users) rather than the server directly. This family of injections is usually combined with a little social engineering to ensure that the attack works end to end.
There are currently three main types of XSS injections:
Reflected XSS (non-persistent).
Stored XSS (persistent).
DOM-based XSS.
We’re only going to cover reflected XSS here, as these are the most common and easiest to understand. They’re also the least dangerous.
Head over to the OWASP website if you’d like more information on the two other types of XSS.
How do XSS injections work?
XSS allows an attacker to inject HTML and JavaScript code into a vulnerable field or parameter. By injecting this code, the attacker can force the client to execute JavaScript code (because JavaScript code is executed on the client side). It is then possible to do virtually anything that JavaScript allows in the client’s browser. Attackers generally use XSS to:
retrieve users’ session cookies if they are not properly protected.
redirect users to a malicious site.
change the appearance or behavior of a page to the attacker’s advantage, such as to retrieve login information.
Let’s look at an example from our example.com application.
We have a search field that allows users to search for a patient in the database, and when performing the search, the application tells us:
“You searched for [<patient name>].”
If the application does not escape HTML special characters (e.g., < , > , and / ), then you probably have a vector for an XSS attack!
We performed all the exercises using Firefox on a Kali virtual machine.
Remember that I’m pointing out some vulnerabilities in a practice application before we look for them on our client’s example.com application.
Let’s walk through detecting and exploiting this type of vulnerability step by step :
The simple XSS vulnerabilities shown in the demonstration video are becoming much rarer. These days, you often need to be a little more creative.
You will sometimes find that you’re banned from using <script> tags and instead need to use other tags, such as <svg> , to trigger JavaScript on certain events!
What’s the best way of protecting against this vulnerability?
All you have to do is escape the various HTML special characters that clients may send, using the functions available in the respective languages, such as the htmlspecialchars function in PHP. I also recommend taking a look at the Stop Cross-Site Scripting (XSS) chapter in the “Secure Your Web Application With OWASP” course, which deals with this subject.
In addition to encoding characters correctly, you can recommend the use of a Web Application Firewall (WAF), which usually provides effective protection against these vulnerabilities.
Let’s Recap!
There are three types of XSS vulnerabilities:
Reflected XSS
Stored XSS
DOM-based XSS
These vulnerabilities run in the victim user’s browser and are usually combined with a bit of social engineering for the attack to work.
These vulnerabilities manipulate the behavior of the client-side browser in order to trick users by changing the appearance or behavior of the page, redirecting them, or stealing session cookies, where possible.
In the next chapter, we’ll take a look at our first server-side injection, focusing specifically on the use of SQL injection (often abbreviated as SQLi) attacks on databases.
