Learn XSS through practice and create a XSS vulnerable website. It is vital for you to know the most common web vulnerabilities. Both if you are working on the defensive blue side or if you are working on the offensive red side. Knowing them and their potential impacts helps you to become a better security practitioner.
Web injection – create your own cookie stealing XSS payload
We already have explored an OWASP top 10 injection vector: SQL injection and created a Flash app login vulnerable to SQL injection. There are however more injection vectors and one of them is Cross-Site Scripting (XSS).
By design websites and web applications will be published to the internet and could be accessed by anyone in the world. This opens you up to hackers – or – lets you hack anyone. Since the nature of web apps makes them exposed, security is extremely important and the basics matter. Variations of the basics are always involved in one way or another in hacks.
Create a xss vulnerable website in PHP
To understand XSS and the potential impact you will create our own vulnerable website in PHP. In the lab available at https://bowtiedguppy.substack.com/p/xss-cookie-stealer
you will do the following:
- Create a website in PHP with login functionality
- Successful logins creates cookies
- Once logged in – introduce the possibility for a user to enter input to the website that is reflected back to the user.
- Develop a payload to steal your own cookie
- Rework the payload so that another user’s cookie can be sent to a server of your choosing.
What is XSS
In short, XSS is when a user has the ability to enter some input into a website and that input is reflected back in some way. The reflection might be directly to you or later to another user. The key thing that makes it XSS is that the input is treated as code by the website – and that code will be executed by the user that it is reflected back on.
XSS affects the javascript code of a website. The frontend code. For someone to be affected by your code they would have to load the page with your code on it. Most likely you would have to prepare a link containing your payload and send it to them in one way or another.
Different types of XSS
- Reflected XSS: something you as a user enter is reflected back to you on a website – in the source code. For example, a search bar with the reflection “you searched for X”. If your entered data is reflected unfiltered you could enter javascript code and voila reflected XSS.
To attack someone with reflected XSS you would have to for example send them a link with the malicious code prepared.
- Stored XSS: In this case the input you provide to the website is somehow stored and does not depend on you entering the input every time. Think of your Twitter feed. What you enter is saved and visible for everyone that visits your profile. If your input would have been executed as code: stored XSS.
- Blind XSS: Similar to stored XSS but the data is not immediately reflected back to you. Think of a contact form on a website – you will never see the other end of that. You are blind. But someone managing the website might and can be affected.
- DOM based XSS: This lets you as a user modify the website’s DOM (Document Object Model). This is the website structure. Exploiting DOM based XSS lets you inject links or other stuff on the webpage. Since you have control over the DOM you can replace the entire website with some content of your choosing if you want.
How to identify XSS
- Can you enter data into the website that is reflected back to you or another user at some point?
- Does the website treat your input as text or can you make the website treat it as code?
Use your hacker’s mindset and start looking!
If you want to take a look at another vulnerability – why not start and create a SSRF vulnerable website?
