Cross-Site Scripting Lab (XSS)

The goal for this lab is to learn the basics of XSS attacks.

What is XSS

Cross-site scripting (XSS) is a vulnerability that may exist in web applications. This vulnerability is present whenever an attacker is able to inject malicious code in a webpage. This code is usually written in the form of a small JavaScript program and will be run by the web browser of the client that accesses that webpage. This code may be included in the client's request or already present in the website. These two types of XSS are called respectively Reflected XSS and Stored XSS.

Although simple, this vulnerability is very powerful as an attacker may steal the victim’s credentials, such as cookies, allowing him to impersonate the victim.

To demonstrate these attacks we will use a purposely ill-developed blog application hosted in our website.

Remember, you must be in the IST VPN in order to be able to play these challenges.

Problem 1

This problem is running at http://mustard.stt.rnl.tecnico.ulisboa.pt:12003

We will start with a simple problem of using malicious code against ourselves and will then evolve to a scenario where we will use malicious code against the admin of our platform.

Task 1.1. Look at the website's functionality

Can you find a XSS vulnerability?

The first task whenever you are looking for a XSS vulnerability is to do some recon of the system searching for the presence of the vulnerability. Can you find one? Can you find a place where you can inject code that will be reflected, i.e., executed in your own browser?

Try to inject that code and see what happens.

• Does it affect just yourself? Or everyone else?

Task 1.2. Find a way to display your own cookies on the screen

Ok, you were able to find a place where you can inject code but can you make it more interesting? Can you use it to steal your own cookies and display them on the screen?

• Get your first flag (XSS1-Just my boring cookies) and submit it in our scoreboard.

Task 1.3. Send your cookies to a website you control

At this point you know how to display your own cookies in your screen but can you send them to a website that you control?

• You may use your Técnico's credentials to SSH to nexus.rnl.tecnico.ulisboa.pt (e.g. ssh <your_ist_user>@nexus.rnl.tecnico.ulisboa.pt) and run nc -vv -l -p PORT to listen for a request on PORT (where PORT should be between 30000 and 40000) and use ip a to get the IP address of the machine. IP should in principle be 193.136.164.129.
  • Notice that nc -l is only able to establish a single connection. Once you close it, you have to re-run nc -vv -l -p PORT to listen again.
• You can then test if it is indeed listening by going to the browser and running http://IP:PORT and see if you get anything in nexus.
• Setting this up, were you able to get your cookies in nexus? In some cases you might need to encode + as %2B.
  • Have a look at window.location. It might be useful.

Alternatives:

• You may also use sigma.tecnico.ulisboa.pt however in this case there is some load balancing involved and your ip address will possibly be different every time you login. Remember to check it with ip a after you login!
• You may use some listening server such as https://postb.in. Just create a bin to receive (an arbitrary number of) connections.
  • To connect to your bin just use https://postb.in/<whatever_random_string_they_gave_you>.
  • Upon refreshing the page, you have there all the connections established with your bin.

Task1.4: Steal admin's cookies

Can you find a way to steal the cookies of the admin of our website? As you have seen, there is a cookie SECRET in our application. You found yours in Task 1.2. The admin's cookie is different, after all he is the admin.

The goal here is to lure the admin to perform a request to the site where you are collecting the cookies. If he does that, then his request will have his cookies and consequently you will learn his SECRET.

• You can use the previously developed XSS payload.
• First, can you lure one of your colleagues and steal his cookie? Team up in groups of two for this task.
• Now, how can you lure the admin to click the link with the vulnerability you found?
  • Hint: The admin is very curious about your bug/feature request.
• Get your second flag (XSS2-My favourite cookies) and submit it in our scoreboard.

Lessons Learned

Although we have used this technique against ourselves, you can easily see that it is possible to lure someone else into clicking in a link that will run code in his own browser (as you did in Task 1.4).

Problem 2

This problem is running at http://mustard.stt.rnl.tecnico.ulisboa.pt:12004

Task2.1: Bypassing simple WAF

Now there seems like the developers created a very simple WAF that is blocking some words like script and img, and the traditional bypasses sCript, SCriPT, etc.

• What happens when you try your old scripts? Are you blocked?
• Find another way to get the admin's cookie.
• Get another flag (XSS3-Give me more than a simple WAF) and submit it in our scoreboard.

Lessons Learned

Avoid using ad-hoc filtering techniques. Rely on standard escaping techniques.

Problem 3

This problem is running at http://mustard.stt.rnl.tecnico.ulisboa.pt:12005

It seems that this feedback form is giving us enough problems so we decided to disable it. Also, we figured out that we would need more than a clumsy WAF and this time we asked our developers to properly protect ourselves from XSS attacks by properly escaping the necessary characters.

Task 3.1. Analyse escaped solution

Try your old attacks in this new version. View the page-source after running your attack and check the differences (against Problem 1). Check also the different answers.

Task 3.2. Explore the new feature. Review blogposts

Now our application allows you to submit new blogposts but, in order to perform a triage of malicious content, we have to review it first before putting it online. But no worries, we are you using the most recent AI+blockchain technology and we do it really fast. Five seconds max!

In fact, to avoid chaos, your blogposts will be reviewed but will never be shown in the main page nor in search. After solving the challenge, you will agree with us :-)

• Explore the new feature. Can you find any bugs in it?
• Don't just try a default payload. Use view-source to see what is actually happening in the html.
• Bear in mind that the admin WILL ONLY REVIEW YOUR POST once you click Update post and send it for admin review.
• Do you know what the XMLHttpRequest JavaScript object does?
• Recall that nc can only handle a connection at a time. You better use postbin this time.
• Get another flag (XSS4-Go on and censor my posts) and submit it in our scoreboard.

Task 3.3: Calling scripts hosted remotely

Can you perform this same attack even if your blogpost is limited to 120 characters?

This problem is running at http://mustard.stt.rnl.tecnico.ulisboa.pt:12007

• If your payload for Task 3.2 was smaller than 120 characters do let us know. Do not use it here as that is not the intended solution.
• Get another flag (XSS5-Twitter-blog) and submit it in our scoreboard.

Lessons Learned

1. There are more to XSS than reflection attacks.
2. You do not need to include all your code in the payload. It may be called from somewhere else this way obfuscating its mallicious intent.

Conclusion

In this lab you learned that it is possible to execute malicious code in a victim's browser and in particular to steal the victim's credentials by performing XSS attacks. We did not illustrate what you could do with these credentials but, as it is expected, you can do mostly everything that a user could do with such cookies. If these credentials were the session credentials of the user then you could perform the same actions as the user.