Part

$1$

: Auditing and Test Cases

For this part, your job will be to find some flaws in the program, and then create test cases that expose flaws in the program. You should write:

One attack, that exploits a XSS

$($

cross

$-$

site scripting

$)$

$$vulnerability to call the javascript alert

$($

$"$

hello

$"$

$)$

$.$

One attack that allows you to force another user to gift a gift card to your account without their knowledge.

One attack that allows you to obtain the salted password for a user given their username. The database contains a user named admin that you can use for testing the attack.

One attack that allows you to run arbitrary commands on the server.

A text file, bugs.txt explaining the bug triggered by each of your attacks and how to remediate each bug. This write

$-$

up should be stored in the root of the repository.

These attacks can take the form of a supplied URL, a gift card file, a web page, a javascript function, or some other method of attack. To create your attacks, you may want to look at the HTML source code of the templates and the code of each view, and find a way they can be exploited. Tools like burp suite can help in finding ways to attack the site, but are not required.

Please submit these attacks in a folder called part

$1$

$$in your git repository:

xss

$.$

txt: A URL starting with

$/$

foo

$,$

$$when visited in a browser, causes alert

$($

$"$

hello

$"$

$)$

$$to be executed.

xsrf

$.$

html: An HTML page that, when opened in a browser, causes a gift card to be gifted to a user named test

$2$

$$by the currently logged

$-$

in user. This user is already created for you by default, and will have the password test

$2$

$.$

sqli.gftcrd: A gift card file

$($

in JSON format

$)$

$$that$,$ when uploaded to a vulnerable form on the site, that will retrieve the admin user's password hash.

cmdi.txt: A text file where the first line should be the vulnerable URL, and the remaining lines are of the form variable

$=$

value, representing a POST request that will execute the command touch pwned on the server. If successful, this will create an empty text file called pwned. For example, your file should look like:

$/$

foo

$/$

$2$

var

$1$

$=$

bar

var

$2$

$=$

baz

cmdi.gftcrd: a gift card file that is uploaded with your command injection request.

Fixes and Testing

Finally, fix the vulnerabilities that are exploited by your attacks, and verify that the attacks no longer succeed on your site. You are allowed to use Django plugins and other libraries to fix these vulnerabilities if necessary, but please add any new libraries you use to requirements.txt

$.$

$$To make sure that these bugs don't come up again as the code evolves, write some test cases for Django that verify that the vulnerability is no longer present. Then have GitHub Actions run these tests with each push.

Tests can be run using Django's built

$-$

in test infrastructure. Create your tests in LegacySite

$/$

tests

$.$

py and then run python manage.py test. You should be able to write all of your tests using the built

$-$

in Django test client

$-$

$-$

there's no need to use something like Selenium. This will also simplify your GitHub Actions testing, which can also just run python manage.py test.

You also do not need to carry out the actual attack in the test; you can check that your fix is working as intended. For example, when testing CSRF

$,$

$$it would be challenging to actually open the xsrf

$.$

html page and carry out the CSRF attack from inside the test case. Instead, you can mimic what the attack does by making a request to the right URL without a CSRF token and checking that the site returns an error. Likewise for verifying your fix for XSS you can check that when getting the attack URL the tag is properly escaped.

Note that by default, Django runs your tests with an empty database

$$

$$which means many pages will not work as you expect. The solution for this is to use the "fixtures" feature, which lets you load sample data into the test database before it runs the test:

$ mkdir LegacySite

$/$

fixtures

$ python manage.py dumpdata

$>$

$$LegacySite

$/$

fixtures

$/$

testdata

$.$

json

Then add at the top of your test case in LegacySite

$/$

tests

$.$

py:

class MyTestCase

$($

TestCase

$)$

:

$$ fixtures

$=$

$[$

$\text{'}$

testdata

$.$

json'

$]$

$$ # rest of test code goes here

This will save a copy of the current database contents into LegacySite

$/$

fixtures

$/$

testdata

$.$

json, and load it when you run the test. You can update the fixture data by re

$-$

running the python manage.py dumpdata command. Remember to add the LegacySite

$/$

fixtures

$/$

testdata

$.$

json file to git so that it is available when you run your GitHub Actions workflow!