Main navigation | Main content
This lab will give you experience with the basic mechanism of HTML/JavaScript injection behind cross-site scripting (XSS) attacks. To simplify the setup, we've designed the lab to not involve a real web server. Instead we'll just give you a script that is the equivalent of a very insecure server-side program vulnerable to reflected XSS. You'll provide the script with command-line arguments that are like what would be supplied in a GET URL, and it will create a web page based on those arguments. You can open the generated page in a browser, and if your attack was successful, JavaScript code you've injected will run. You'll want to use a real graphical browser to get the full capabilities and interaction, so we recommend either using a GUI connection to CSE Labs (e.g., Vole), or running both the vulnerable script and the browser locally if you have a Perl interpreter available.
In the online lab we'll randomly split you into breakout groups of 2-3 students: please work together, discuss, and learn from the other student(s) in you group. Use the "Ask for Help" button to ask questions or show off what you've done. We also recommend working in groups in the in-person lab, but there you can choose your own groups and physically raise your hand to ask a question. You may still find it useful to use Zoom or tmate for screen sharing in person while respecting social distancing.
The most basic usage of the script doesn't involve changing any inputs; if you run it without arguments it will just create a default version of the web page. For our purposes we'll assume you call that page page.html:
cp /web/classes/Fall-2020/csci4271/labs/06/make-page.pl perl make-page.pl >page.html
Some browsers have a menu entry for opening a local HTML file, or a browser may come up if you double-click on or otherwise try to open the file in a GUI. If neither of those work, you should also be able to give the browser a URL that starts with file:// and then an absolute path to the file. For instance in a file in your CSE Labs home directory might have a URL that looks like:
file:///home/goldy007/page.html
Next, you can try making benign changes to the program inputs that change the generated web page. The program accepts five different inputs labeled a through e, specified in command-line arguments with equals signs. For instance try the command:
perl make-page.pl a=apricot b=Banana_Republic c=coral >page.html
The inputs a, d, and e are included directly in the HTML output, while the b input is used as a part of a URL in a link, and the c input is used as a color in a CSS inline style sheet. Of course you can also try experimenting with other fruits, Wikipedia pages, and colors.
When the goal is just to verify the presence of an XSS vulnerability, rather than maliciously exploit it, the standard "payload" is just JavaScript that opens a popup box with a message; this is similar to overwriting a return address with AAAAAAAA for a buffer overflow or opening a calculator. Different attacks are possible against all five inputs to the script, but for instance to get started with the attack using input a, you can try to get the browser to execute the following JavaScript code:
alert("XSS a")
Input a doesn't have any additional defenses or complexities, so all you need is to know the standard way to insert JavaScript code in HTML. You can of course find lots of HTML documentation on the web.
Inputs b and c go in other contexts inside the web page, so your attack will need to be modified accordingly. In these cases it is enough to use a standard injection attack strategy of finishing off the construct that you were inside, hen putting in new top-level content. You can also make sure things are more consistent by restarting another of the construct you were already in, though web browsers are forgiving enough that this is rarely needed.
Inputs d and e are more a bit more complex in that the script tries to sanitize them by removing things that you might try to use in your attack. However sanitization to completely block XSS is difficult, and the script doesn't do a good job at all, so you can get around it. Feel free to look at the Perl script to get information about what it's doing. There are also a lot of resources on the web about strategies for XSS attacks in the presence of filters; two of our favorites are this older one from OWASP and another more recent one.
When writing more complex attack payloads as command-line arguments, we recommend you write them inside single quotes to protect most characters from interpretation by the shell:
perl make-page.pl a='<b style="color: orange">apricot</b>' >page.html
It's harder to use single quotes inside the attack if you do that, but you might find it helpful to know that all three kinds of ASCII quote marks can be used in JavaScript.