Stored XSS [Front-end To Back-end]

Stored Cross Site Scripting

Hello Friends,

This is my 28th blog on web application security penetration testing. In this blog I will explain about Stored Cross Site Scripting.

In my last blog, I have explained about Reflected Cross Site Scripting. Hope everyone liked it. If you haven’t read it yet please follow along.

Mohammad Mohsin - Medium

I will give complete walkthrough like, “How Stored XSS payload transferred from front-end UI to back-end if XSS prevention is not in the place?”

What is Stored Cross Site Scripting?

Stored based Cross Site Scripting: [Stored in Database] : When a user supplied input is not validated or sanitized properly and stored into database and later on access in some other part of application from database then we called it as stored cross site scripting attack.

How to Test for Stored XSS?

1] Find pages which collect user information or some other info and saved to DB. Like signup page, comment box, contact us page, etc.

2] Enter some simple text and click on submit. If it is stored in DB and displaying on page then here is good to test stored XSS.

3] Enter payload and submit to server. Re-visit the same page or different page where payload is getting called from DB and if payload is executing successfully then there is stored XSS.

Lab Setup:

To demonstrate Stored Cross Scripting, I have created one sign-up/Register Page. I have used below technologies:

Microsoft Visual Studio 2015

Microsoft SQL Server 2008

Firefox Web Browser

Below is the Step-by-step POC:

1. Code to create Register Table in Backend SQL server. Note that, Id parameter is auto generated.

Code to create Register Table

2. Below records are added to Register table.

3. Below page allow user to register themselves. Registration page has Name field which is vulnerable to Stored XSS.

Register Web Page UI

4. Below code is used to store/bind user registration details from UI to backend database i.e. MS-SQL -Server.

Code to Save registration details into DB

5. I have added Breakpoint to debug step by step execution to understand “How registration details getting stored to DB?”.

Breakpoint Added to debug execution when Submit button is clicked from Front-end UI

6. As an attacker, I have entered malicious payload as shown in below screen for testing Stored XSS.

Attacker entered stored XSS payload into Name field

7. But the ASP .NET framework by default prevent XSS attack due to page validation. So, I have got below error on Web page.

Error.aspx

8. For demo purpose I have intentionally disabled page validation by setting up “ValidateRequest:False” on the top of Web Page.

9. Now again enter the malicious payload i.e. “<Script>alert(1)</script>” in the Name field and click on Submit button.

Malicious payload in the Name field

10. Notice, this time our Breakpoint hits and we can monitor that malicious payload is getting pass from front UI to backend for Name field.

Breakpoint Hits

11. As shown in below screen, user details which we have entered in Step 9 is stored to backend without proper validation and input sanitization.

XSS Payload Stored in Backend.

Now consider if this record is viewed on any different web page. What will happen? Our XSS payload for id=5 has malicious payload which will get executed without any restrictions as it is coming from backend itself resulting Stored Cross Site Scripting.

Below is the code run which I have captured for live demo:

Stored XSS YouTube Video

Cross Site Scripting Impact:

Cookie Theft

Keylogging

URL Redirection

Phishing Attack

Downloading Malwares on victim’s computer, etc.

Cross Site Scripting Prevention:

Preventing cross-site scripting is trivial in some cases but can be much harder depending on the complexity of the application and the ways it handles user-controllable data.

In general, effectively preventing XSS vulnerabilities is likely to involve a combination of the following measures:

• Filter input on arrival. At the point where user input is received, filter as strictly as possible based on what is expected or valid input.
• Encode data on output. At the point where user-controllable data is output in HTTP responses, encode the output to prevent it from being interpreted as active content. Depending on the output context, this might require applying combinations of HTML, URL, JavaScript, and CSS encoding.
• Use appropriate response headers. To prevent XSS in HTTP responses that aren’t intended to contain any HTML or JavaScript, you can use the Content-Type and X-Content-Type-Options headers to ensure that browsers interpret the responses in the way you intend.
• Content Security Policy. As a last line of defense, you can use Content Security Policy (CSP) to reduce the severity of any XSS vulnerabilities that still occur.

Labs to Practice XSS:

1. http://www.xssgame.com/
2. https://jlajara.gitlab.io/web/2018/12/16/XSS-Google-Game.html
3. https://alf.nu/alert1
4. https://prompt.ml/

In my next video I will show you how earlier stored, XSS payload will get executed when data loaded from backend and displayed on web page.

I hope everyone is enjoying reading my blogs. Please comment for any doubt related to Stored XSS or this demonstration. Please do like and follow for more reads.

Thank!