Web Security

The goals of this project:

● Students are asked to read up on web security basics and write simple web vulnerabilities using
Javascript/HTML
● A series of warm up activities will help ease students into the assignment
● With their knowledge of web security, the students are expected to attack three targets using the
following web exploits:
● Target 1 - Cross-Site Request Forgery (XSRF)
● Target 2 - Cross Site Scripting (XSS)
● Target 3 - SQL Injection (SQLi)
● Read Ed – Lots of questions are answered there daily. Be sure to check there before asking a
question. Note: We will not review code in private posts so please don’t post these.
Intro:
Congratulations! You just started your first day at your summer internship at Red Team Inc., a penetration
testing company that specializes in testing customers’ web applications. Your mentor, Jason, introduces
himself to you, and lets you know that you’ll be working with him and the rest of his team for the next few
weeks doing a penetration test on the payroll site for your own school, Georgia Tech!

To get you up to speed on the skills required to do your job, he starts off by assigning some readings and
warm up exercises.

Prior Reading and Important Notes from your Mentor:

This project requires submitting forms. If you do not know how to do so, you may consult http:/
www.w3schools.com/html/html_forms.asp

This project requires writing JavaScript. Only a very basic knowledge of JavaScript is needed. You may
find http:/ eloquentjavascript.net/ useful if you are completely new to JavaScript. Even if not completely
new, you may find chapters 13 (JavaScript and the Browser), 14 (The Document Object Model), 15
(Handling Events), and 18 (HTTP and Forms) particularly useful.

You are required to use the provided templates for all parts of this project.

You are NOT submitting any PHP code in this project. Thus, your exploits should not modify the
provided PHP files on the VM besides for debugging purposes. If you do happen to modify the PHP files,
make sure you revert your changes when you test your exploit. We test your exploits using your
submitted .html files and run them against the original, unmodified payroll server provided in the VM.
This is a common mistake our interns make, so please make sure to use the original files to test your final
exploits.

This project will require you to read and understand PHP (PHP Hypertext Preprocessor), which runs on a
web server and responds to HTTP requests with dynamically generated pages and responses. It essentially
works by taking template HTML files and filling them in by running scripts embedded in the template.
Getting Your Development Machine Set Up:
NOTE: The project uses the same exact VM that you used for Malware Analysis. If you already have
that up and running there is no need to download it again. The link here is provided only if you wish
to download it again.

Link: https:/ cs6035.s3.amazonaws.com/cs6035_p2_p3_p4_spring2023.ova Use

the same username and password you used for project 2:

Username Password

debian debian

Helpful Hints from your Mentor:

● The primary site we will be exploiting in this project is http://payroll.gatech.edu, which you
can only visit on the VM. Please note again that this does not point to a legitimate site in the real
world and only exists in the VM. For testing purposes, you may register accounts at your will.
However, please DO NOT use your actual passwords and banking account information.
● The developers for the website have tried to implement some safeguards to protect
against some common web exploits. However, these may or may not be effective, and part
of your role will be to audit the correctness of their safeguards.
● The source code of the site can be found on the VM in /var/www/payroll. There is a
bookmark added to the file manager to make your job a bit easier.

● You will be using the Chrome browser to complete all portions of this project. Do not use
Firefox. It will fail on some targets and you’ll waste a ton of time.

Use Chrome for this project!

 Disclaimer:
This project is solely for educational purposes. Professor Wenke Lee and the people a ffiliated with his
teaching and research are NOT responsible in the event of any criminal charges brought against any
individuals misusing the information in this project to break the law. When in doubt, please consult the
TAs or Professor Lee regarding any questions or issues you may have.

We hope you enjoy this challenging yet rewarding project. Now onto the details.
Target 1: XSRF (20 points)
Having completed the warmup tasks Jason assigned (you did do them, right? They’re a lot of fun), you
walk up to him for your first task. He explains that he has discovered a vulnerability in the GT payroll site
that he’d like you to craft a proof-of-concept exploit for. Suppose a user, say Alice, is already logged into
the Georgia Tech payroll site located here in the VM -> http://payroll.gatech.edu. He noticed that you
can craft a web page so that when Alice visits your web page, she gets redirected (NO popups) to the
Georgia Tech payroll page with her account number and routing number set to some values of her choice.

Not wanting you to use your own bank account information (for obvious reasons), Jason tells you to use
some information from a script that he wrote.

To fetch your bank account number and routing number, run the get_bank_info script inside the VM
and pass in your GTID# 903379008. Example command on the terminal:

debian@debian:~$ get_bank_info 903379008

Here is an example of what the script will print out:

Username: 903379008
Account number: ?
Routing number: ?

If you enter the wrong GTID#, which generates a different account and routing number, your exploit will
fail our scripts, and you will receive zero points for this part, so be sure to double and triple check.

The user must NOT see the contents of your crafted page! However, a split second due to browser rendering
is acceptable. This is because in a real-world attack, the attacker might send this page via email to a user as
part of a social engineering attack, and if the user sees the contents of the page it would arouse suspicion.
We want the PoC to be as realistic as possible to drive home the point to the client.

Deliverables

● t1.html
● You are required to use this template when submitting your constructed URL. This will
be autograded so the template is required.
https:/ drive.google.com/file/d/1lcL8k_PgfZBegcpMdgtJ-BCszIhnzCyK/view?usp=sharing

Milestones
A successful attack earns 20 points automatically.
If you are unable to complete the task, you will earn partial credit as follows:

Points Milestone (you earn points in this order)

10 out of 20 pts You see the “CSRF attempt prevented!...” message

with your exploit and cannot progress further.

20 out of 20 pts Able to change the account number and routing

number without extra browser tabs or popups. If
you get to this point you’ve earned the full 15
points.

Caution: Double check that the values you use are

the ones assigned to you by running get_bank_info.
You WILL lose points even if the value is off by
one.

Notes
You can visit your web page by entering the path of your file in the browser URL bar. For example, this
would be file:///home/user/t1.html assuming that your exploit lives in /home/user/. You can also
simply double click to open the file in Chrome. This opens your exploit in another tab but this is OK and it
works. Your actual exploit code must NOT open a new tab via JavaScript or other means. You can also
open your file using the CTRL+o hotkey.

Do NOT use relative paths for site URLs in your exploits.

● WRONG -> /somefolder/somefile.php

● CORRECT -> http:/ payroll.gatech.edu/somefile.php

We see this every semester from a handful of students. Your exploit will fail, and you will not receive credit.

Example of Successful Exploit

Our autograder is a Selenium script so it will simulate button clicks using the same exact browser and VM
that you have. It will do the following for Task 1:

● Log into the site using a known good username and password.
● Launch your t1.html file in the same open tab
a. It must auto-submit!
● Verify that the URL starts with “http:/ payroll.gatech.edu”
● Verify that the Changes Saved is on the page and that the account number and routing number
matches your assigned values. Do not use 1234567890 as this is just an example. See the
screenshot below.
Target 2: XSS Username and Password Theft (25 points)
Now that you’ve finished your PoC exploit for the first vulnerability, Jason thinks you are ready to write
one for a potentially more-severe vulnerability. He noticed that you could steal a user’s username and
password. You can craft a web page such that whenever a victim, say Bob, visits the page (by clicking the
attachment in a phishing email), it will redirect him (NO popups) to http://payroll.gatech.edu/ with a
malicious script injected into the page.

The web page should look as if Bob visited the site directly without going through your page. When Bob
enters his login information into the page and clicks Log In, an email with his username and password will
be sent. Jason asks you to craft such a PoC web page. You will have to send the email to the local user
account on the virtual machine.

This attack requires an email to be sent to user on the system. The good news is that you can use
hackmail:

http://hackmail.org/sendmail.php

Open the above URL from within virtual machine for instructions on how to send emails via your attack
script. Any mail that the user account receives will appear in /var/mail/user file. A bookmark has been
added to the file manager for your convenience. Note: Initially the user file will not be there. Your exploits
will cause it to be generated.
Requirements
● The attack must be performed using XSS. Providing a phishing web page will result in 0
points. The browser URL bar should contain the domain payroll.gatech.edu and not a
phishing URL. If you find yourself copy and pasting html code from the payroll site into your
t2.html then you’re likely heading down a very wrong path.
● The email payload should be the user’s username (login) and password separated by a single
space. i.e. username password <- notice the space!
○ The sender of the email (look at the screenshot below before asking questions) should
be set to
MjAyM1NwcmluZyYmRWFzdGVyRWdnYGBUYXJnZXQyLVRoaXNPbmVDYW5CZUR
pZmZpY3VsdF5e
○ Failure to follow this format will result in 0 points for this part.
● The redirected page must be cosmetically identical to the original page. The web page
source can be different as long as the user cannot tell without looking at the source. This may
take some trial and error. This part can be difficult! Use the developer tools to help you. Extra
html characters such as < and > are not ok. Shifted alignments that can be noticed are also not
ok. You should be able to hide all traces of your injected script.
● The page must be functionally identical. This means the user can log into the site in the
normal fashion and will not notice any visual/functional differences. Yes, you must be able to
log in to pass this test.

Deliverables

● t2.html

Sample t2.html deliverable:

You are required to use this template when submitting your constructed URL. This will be autograded so
the template is required.
https:/ drive.google.com/file/d/1s5WmU6Ygu8CTl0VfIQeyupr9-CDZ_a6I/view?usp=sharing

Milestones

A successful attack earns 25 points automatically.

If you are unable to complete the task, you will earn partial credit as follows:

Points Milestone (you earn points in this order)

10 out of 25 points Can inject a script and send an email to the user
account but cannot progress further

25 out of 25 points Steal the user’s username and password and send them
to the user account via email.

Caution: The values need to be exactly correct. Extra

spaces, quotes or anything WILL result in
 point loss. The exploited web page must be
cosmetically identical to the original website. Hint:
your exploit may initially introduce odd styling issues
or show characters on the page. You must hide these.

Notes

We suggest playing around with hackmail outside of your exploit to make sure you can generate data within
the “user” mail file. Right click it and open with the Text Editor to view the contents. Do not delete the user
file. If you do, hackmail will create a new one but you may be required to run Linux commands in order to
view the contents. Just don’t delete it.
Use the developer tools built into Chrome. Simply click F12 in Chrome and you’ll see the dev tools pop up
at the bottom. This tool is your friend, get to know it and use it to help you through this task.

Example of Successful Exploit

Our autograder is a Selenium script so it will simulate button clicks using the same exact browser and VM
that you have. It will do the following for Task 2:

1. Open your t2.html file

a. It must auto-submit!
2. Verify that the URL of the page is correct and that it is cosmetically identical to the
original site. See screenshot below.
3. Input a known good username
4. Input a known good password
a. Note: Your code does not need to handle invalid username and/or password. We’ll
only test happy path.
5. Click the Log In button
6. Inspect the file system for the user file
7. Validate that the user file contains username and password and that the sender is
MjAyM1NwcmluZyYmRWFzdGVyRWdnYGBUYXJnZXQyLVRoaXNPbmVDYW5CZURpZm
ZpY3VsdF5e See screenshot below.
8. Ensures that the user is logged in correctly. Your exploit cannot break the login
functionality of the site.

After opening t2.html, the resulting web page should look exactly the same as the legitimate site. Notice
there are no cosmetic differences! The reason, you ask, is because it IS the payroll site and not a phishing
site. Hint: your code needs to inject and redirect to the payroll website. Do not reconstruct a version of the
site within t2.html. This is wrong.
The email should be sent via hacker mail.
Target 3: SQL Injection (25 points)
Impressed with how much you’ve learned so far (and in so little time), Jason thinks he can entrust you to
create a final PoC HTML webpage with the following requirements to show the website developers how
easy it is to bypass their site’s authentication:

● The crafted page has a text field for the username and a submit button.
○ NO password field!
● The user of this page is not logged into Georgia Tech payroll system, but when he or she enters
a valid Georgia Tech payroll registered username (for example, judyhopps) and clicks submit,
the user is redirected to http://payroll.gatech.edu/account.php and logged in as judyhopps.
● Do NOT execute destructive SQL commands such as DROP tables. System
administrators can easily detect data loss!
● Do not change the id of the input field ‘targetlogin’, and the button id ‘exploit’. This is very
important as the autograder specifically looks for these elements. Failure to include them will
result in a zero for this target. See the template below.

Deliverables
● t3.html

Sample t3.html deliverable:

You are required to use this template when submitting your constructed URL. This will be autograded so
the template is required.
https:/ drive.google.com/file/d/1C8CDBSLerl-RQZZAWJm4GH1CVboKwcwN/view?usp=sharing

Milestones

A successful attack earns 25 points automatically (so long as it does not execute destructive SQL commands).
There are no partial credit opportunities for target 3.

If you implement the attack with a destructive SQL command that causes our scripts to fail to grade your
target you’ll not receive points for this Task. You will not need to modify the database schema in any way
in order to exploit this.

Example of Successful Exploit

Our autograder is a Selenium script so it will simulate button clicks using the same exact browser
and VM that you have. It will do the following for Task 3:

1. Launch your t3.html file in Chrome. See screenshot below.

2. Find the targetlogin input field and replace whatever text is there
with a known good username
3. Find the exploit submit button and click it
4. Inspect the resulting redirected page to ensure it is the correct page,
see screenshot below, and that the user is successfully logged in.
5. Ensure that the resulting redirected page is cosmetically &
functionally identical to the original site.

After visiting t3.html, the page displays an input field for the attacker.

After typing in the username of an existing user in the payroll system, you should be
successfully logged in. The site should function as if you are logged in legitimately.