Project 3: Web Security
=======================
.. toctree::
:hidden:
.. |ss| raw:: html
.. |se| raw:: html
- **Due:** 05/04/2025 (Sun) 11:59pm
Introduction
------------
In this project,
you will perform a series of attacks to exploit some vulnerabilities
in an online bulletin-board, called **hackme**.
Your attack will consist of several phases.
You will conduct
cross site scripting,
cross site request forgery, and
SQL injection attacks.
You are also required to implement modifications to
the web site to prevent such attacks.
Getting started
~~~~~~~~~~~~~~~
**If you have not finished setting up your project environment,
please follow the instructions in**
:doc:`Project Setup `
**to set it up first.**
We expect you will work on this project remotely
in the project server through SSH, and
test it using a web browser from your own machine through HTTP.
Login to the project server.
.. code-block:: sh
[host] $ ssh NetID@csa-chk22b.utdallas.edu
Once you are successfully logged in,
fetch the source code of Project 3.
To do that,
use Git to commit changes you've made since handing in Project 2 (if any),
fetch the latest version of the course repository, and then create a
local branch called ``project3`` based on
our project3 branch ``origin/project3``:
.. code-block:: sh
$ cd ~/infosec
$ git pull
Already up-to-date.
$ git add -A
$ git commit -am 'changes to project2 after handin'
Created commit 734fab7: changes to lab1 after handin
3 files changed, 28 insertions(+), 7 deletions(-)
$ git push
Enumerating objects: 5, done.
Counting objects: 100% (5/5), done.
Delta compression using up to 4 threads
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 308 bytes | 308.00 KiB/s, done.
Total 3 (delta 2), reused 0 (delta 0), pack-reused 0
remote:
To ssh://s3lab.utdallas.edu:2224/cxk200010/infosec.git
88682b1..494dc56 lab1 -> lab1
$ git checkout -b project3 origin/project3
Branch project3 set up to track remote branch refs/remotes/origin/project3.
Switched to a new branch "project3"
$ git clean -dfx
$
You will now need to bring your ``student.info`` file
from the ``project1`` branch
into the ``project3`` branch, as follows:
.. code-block:: sh
$ git checkout project1 student.info
$ git commit -am "Bring student.info from project1"
Project 3 includes the ``hackme`` directory.
This is your website's home directory,
which you can use for running your solution.
You can access any file placed there online at
http://csa-chk22b.utdallas.edu/~NetID/hackme/
using a web browser from your own machine.
If you are outside the UTD campus,
your machine needs to connect to the UTD VPN before
accessing the website using a web browser.
In the project server,
keep your permissions on the ``~/infosec`` and ``~/infosec/hackme``
directories appropriate as well as the hackme source files.
You may need to modify them using the following commands,
so that the web server can run your website.
.. code-block:: sh
$ chmod 701 ~/infosec
$ chmod 701 ~/infosec/hackme
$ chmod 604 ~/infosec/hackme/*.*
$ chmod 701 ~/infosec/hackme/images
$ chmod 604 ~/infosec/hackme/images/*.*
All your website instances will connect to the same MySQL database.
Your website uses the configuration parameters stored in ``config.php``
to connect to the database.
**Please do not modify these configuration parameters.**
Modifying them may result in connection errors.
.. note::
**Even though you have your own version of the website hackme,
other students are sharing the common database with you,
so make sure that you play nicely.**
Hand-in procedure
~~~~~~~~~~~~~~~~~
You will turn in your project by pushing your progress
to the repository and tag the final version of the project.
When you are ready to hand in your project code and report,
please place the report in a file called ``report-project3.pdf``
in the top level of your directory before handing in your work.
After that,
add your report to the Git repository with
``git add report-project3.pdf`` and ``git commit``.
If you have obtained help of any kind while working on this project,
make sure to write the names or URLs of your sources in
``references-project3.txt`` in the top level of your directory,
and add it to the repository with ``git add references-project3.txt``
and ``git commit``.
After completing the project,
add any new files you have created into the Git repository,
commit, and push. For example,
.. code-block:: sh
$ git add XSS.txt SQL.txt passwords.txt
$ git commit -am 'project3 complete'
$ git push
Tag your final commit as ``project3-final`` and
push the tag to the repository to submit your progress.
**We only grade the commit with this tag.**
.. code-block:: sh
$ git tag project3-final
$ git push
$ git push origin --tags
# if you want to change the final tag,
$ git tag -d project3-final # this will delete the local tag
Deleted tag 'project3-final' (was 75411c7)
$ git push origin :refs/tags/project3-final # this will delete the remote tag
To ssh://s3lab.utdallas.edu:2224/cxk200010/infosec.git
- [deleted] project3-final
Password and Session Management (20 pts)
----------------------------------------
Securely managing sessions and passwords is vital to prevent
a number of attacks on a webpage.
Many website designers, however, neglect to take a few important
security measures when dealing with passwords and cookies.
In this part, you are going to explore hackme's code and identify
a set of exploitable vulnerabilities.
Password management
~~~~~~~~~~~~~~~~~~~
hackme manages passwords in an inherently insecure way.
Familiarize yourself with the password management techniques
employed by hackme by examining the following files:
``index.php``, ``register.php``, and ``members.php``:
- **Describe** how the passwords are stored, transmitted and
authenticated.
- **Identify** and **describe two** vulnerabilities in the password
management system and explain **how** they can be exploited.
Your answer should not involve the possibility of
"weak passwords" and should not involve cookies.
- **Describe** and **implement** techniques to fix the above
vulnerabilities. Your description should be thorough, and should
indicate which files/scripts need modification and how they should be
modified. You should then write code to fix the vulnerabilities.
Your code will be graded on how well it fixes the vulnerabilities.
No points will be given if the code gives runtime errors.
Session management
~~~~~~~~~~~~~~~~~~
hackme relies on cookies to manage sessions.
Familiarize yourself with the how cookies are managed in hackme.
- **Describe** how cookies are used in hackme and
how sessions are maintained. Include in your description
on what is stored in the cookies and
what checks are performed on the cookies.
- **Identify** and **describe three** vulnerabilities in the
cookie management system and **how** they can be exploited.
- **Describe** and **implement** techniques to fix the above
vulnerabilities. Your description should be thorough and should
indicate which files/scripts need modification and how they should be
modified. You should then write code to fix the vulnerabilities.
Your code will be graded on how well it fixes the vulnerabilities.
You will not get any points for code that gives runtime errors.
.. note::
We have provided two empty columns, ``extra`` and ``extra2``,
in the database, that can be used for your implementation.
XSS Attack (20 pts)
-------------------
Cross site scripting (XSS) attacks are one of the most common attacks
on websites and one of the most difficult to defend against.
Popular websites, including Facebook and Twitter (now X),
were once vulnerable to such attacks.
Naturally, hackme is also vulnerable to XSS.
In this part, you will perform a XSS attack to steal users' cookies.
The attack
~~~~~~~~~~
Craft a special input string that can be used as part of a posting
to the bulletin board to conduct a XSS attack.
The attack should steal the cookies of any user who views your posting.
The cookies must be stored in a file on the attacker's server
(not storing the cookies will only get you partial credit).
You need to:
- Provide the **exact** input string you need to post to the webpage.
The input should be typed and submitted in a file named ``XSS.txt``
in the top level of your Git repository.
The CS 6324 staff should be able to copy your string and paste
it in order to replicate your attack. To get full credit, your attack
must be 100% hidden from the victim.
- **Explain** what your string does and how it performs the attack.
Also **describe** how the attacker can access the stolen cookies.
Be precise in your explanation.
- Provide any extra web pages, files, and/or scripts that are needed
to conduct a successful attack. Provide a complete description of
each item and its intended purpose. Include in your description
the required permission bits for each new file.
- **Describe** the exact vulnerabilit(y/ies) that made your attack possible.
The defense
~~~~~~~~~~~
- **Describe** and **implement** a method to prevent this attack.
Your description should be thorough and should indicate
which files/scripts need modification and how they should be modified.
- You should then write code to fix the vulnerability.
Your code will be graded on how well it fixes the vulnerability.
You will not get any points for code that gives runtime errors.
XSRF Attack (20 pts)
--------------------
Cross site request forgery (XSRF) attacks are malicious exploits
which allow unauthorized commands to be transmitted to a webpage
on behalf of a victim user.
The attack can be used to perform unauthorized transactions on
the victim's behalf.
In this part, you will perform a XSRF attack to post an advertisement
to the website without the user's consent.
While the user is still logged on to hackme, you need lure him/her
to a malicious webpage that runs the attack.
The attack
~~~~~~~~~~
Create a new webpage that runs the XSRF attack.
The attack should post an advertisement for
"awesome free stuff!!". You need to:
- **Describe** the components of your webpage.
Include a thorough description of the component performing
the attack and explain **how** the attack is performed.
- Make sure that the attack is 100% stealthy (hidden from the victim).
The victim should only visit/view the malicious website for the attack
to work. Attacks which require user interaction or which are not
hidden (e.g., cause redirection) will only get partial credit.
- **Identify** a method of luring the victim to visit your malicious
website while he/she is logged into hackme.
- **Describe** the specific vulnerabilit(y/ies) in hackme that allowed
XSRF attacks. Be precise in your description.
The defense
~~~~~~~~~~~~
- **Describe three** methods to prevent XSRF attacks on hackme.
You need to be thorough in your description:
mention **what** needs to be done,
**how** to do it, and **why** it will prevent the attack.
SQL Injection Attack (20 pts)
-----------------------------
For this part, you will use a private version of the website available
at http://csa-chk22b.utdallas.edu/hackme/.
.. note::
This private version of hackme uses a different database instance
which uses login credentials that are not available to you.
In an attempt to limit access to this bulletin board,
we added one more verification step to the registration process.
Now, only users that have been given a secret access key can register
as users.
When creating a new account, the user has to enter a secret key.
The hash of this key is checked against a stored hash.
If it matches, then the registration process continues normally.
This is the only time the key is checked.
Unfortunately, the secret key was not given to you,
and you cannot register on this website.
For this attack, you will bypass this requirement by
performing an SQL injection attack.
The attack
~~~~~~~~~~
By crafting a special input string to one of the HTML forms,
you need to perform an SQL injection attack to make a post
on the bulletin board by an unregistered user.
Specifically, you may need to:
- **Identify** the webpage you are using for the attack
(i.e. ``index.php`` or ``register.php``).
- Provide the exact input to every field on the webpage;
this should include your attack string.
The CS 6324 staff should be able to copy your string and paste it
in order to replicate your attack from a file named ``SQL.txt``
in the top level of your Git repository.
To get full credit, your attack should not return an SQL error.
- **Execute** the attack to **post** something on the bulletin board.
The username should be your NetID (e.g., cxk210000).
- **Describe** the exact vulnerabilit(y/ies) that made your attack possible.
The defense
~~~~~~~~~~~
- **Describe** and **implement** a method to prevent the above SQL injection
attack. Your description should be thorough and should indicate which
files/scripts need modification and how they should be modified.
You should then write code to fix the vulnerabilities.
Your code will be graded on how well it fixes the vulnerabilities.
You will not get any points for code that gives runtime errors.
- The way the secret key is handled is inherently insecure.
**Describe** a more secure method of providing the extra authentication
step. That is, assuming that an adversary **can** perform the SQL
injection attack, how can you prevent him from logging in
to the website?
.. note::
You can assume that "magic quotes" are disabled in the
``php.ini`` file by the system administrator.
You cannot override this setting.
Weak Passwords (20 pts)
-----------------------
Simular to the previous part,
we will use a private version of the hackme website.
As you can tell, hackme does not check the strength of
a user's passwords.
The website only enforces the condition that passwords
should be non-empty.
As a result, 100 users registered accounts with very weak
and/or common passwords.
The attack
~~~~~~~~~~
The file ``users.txt`` contains a list of 100 users with weak passwords.
You need to perform **a brute-force dictionary attack** to recover these
passwords.
For this, you need to find a corpus of weak passwords
(a number of them are available online).
Output your result in a text file called ``passwords.txt``.
Each line in this file should correspond to one user
in ``users.txt``, following **the same order**.
The **format** of every line should be:
**the username**, followed by **a space**, and
followed by **the password**.
If you are unable to recover the password for some users,
then output the username alone on that line.
For example,
.. code-block:: sh
jasmine s0m3p@ssw0rd
patterson s0m3p@ssw0rd
judy
baker s0m3p@ssw0rd
...
That is, the CS 6324 staff should be able to run ``diff``
on your output and the correct output to get the number of incorrect
answers you have.
**Failure to follow these rules will not give you any credit.**
.. note::
**Tip**
No password is used twice. If you are missing a few passwords
after your dictionary attack, think about common bad
password habits made by users.
The defense
~~~~~~~~~~~
Read the paper
"Testing Metrics for Password Creation Policies by Attacking Large Sets of Revealed Passwords" by Weir et al.
A PDF copy of this paper can be found `here <../_static/pwdtest.pdf>`__.
- **Describe** the current NIST standard for measuring the strength of
passwords.
- Briefly outline **why**, according to the paper, the NIST standard is
ineffective.
- Based on your understanding, suggest **a set of rules** that can be
employed by hackme to prevent "weak passwords".