1. Lecture 14 – Web Security SFDV3011 – Advanced Web Development 1

2. Types of Vulnerability In web applications, there are 5 categories of vulnerabilities : 1.SQL Injection 2.Cross-site Scripting (XXS) 3.Cross-Site Request Forgeries (XSRF) 4.Session fixation 5.Session hijacking 2

3. SQL Injection Consider the following query: SELECT fieldlist FROM table WHERE field = '$email' What if $email contains: anything' OR 'x' = 'x 3

4. Protect against SQL Injection Protect against SQL injection in two ways: 1) Use the language's quote-removal mechanism: for PHP and MySQL, use mysql_real_escape_string() 2) Use prepared statements: Replaces variables with placeholders e.g. WHERE field = ? When values get bound to placeholders, they are guaranteed to be treated as data, not as part of the query 4

5. Most common use of database Is to store a list of usernames, passwords, and associated user information Basic technique: get username and password from a form Consider: transmitted in clear! Hash the password using md5 or sha1 Check database for username and hashed password match If match is exactly one row, set session variable to let user in 5

6. Refinements to Authentication Use a “salt”. This is a string that only you know, that you add to passwords before hashing Choose a unique session ID and set your session to be valid Store error codes for failed logins in a session variable, and tell users on the login page that they failed Regenerate the session ID cookie any time a user changes status with session_regenerate_id For serious security, only authenticate over HTTPS 6

7. Cross-site Scripting (XXS) In simple terms: this is when a Web application allows unintended HTML, JavaScript, or CSS to run on a client's machine Simple example: a comments form that allows un-escaped HTML/JavaScript, coupled with a display page that treats comments as plain HTML Least bad thing that can happen: malicious user puts in a URL to an inappropriate image Other things: user adds JavaScript that redirects other users to a completely different site Or, user adds inline CSS that makes your page vanish 7

8. Cross-site Scripting Implications More subtly, suppose a malicious user has an account on the same site as you And is able to create a JavaScript injection JavaScript can use XMLHttpRequest to POST back details (to the origin server) JavaScript has access to your cookies Attacker now has your cookie, and can impersonate you on the site Cross-site scripting is like a \gateway drug" - it leads to bigger things like XSRF and session hijacking. 8

9. Cross-site Request Forgery (XSRF) The situation: suppose you are logged in to Site A An attacker tricks you into clicking on this link in Site B (or in your email): The image trick requires a GET, but you can do this with POST if there is a JavaScript XSS vulnerability on Site A Solution: generate a token with your forms and require the form-submitter to present it on the URL 9

10. XSRF Mitigation <?php $token = md5(uniqid(rand(), TRUE)); $_SESSION['token'] = $token; $_SESSION['token_time'] = time(); ?> <input type="hidden" name="token" value=" "> 10

11. Session Fixation Attacker uses a link or a redirect to send them from their site to a site you belong to At the end of the link, or in the header, is a PHPSESSID of their choice You log in; they know your session ID (they fixed it) Solution: regenerate the session ID after any change in privilege level for your users (session_regenerate_id()) 11

12. Session Hijacking Attacker goes to the trouble of getting a valid PHPSESSID (perhaps after you have regenerated it or using a packet snifer) Attacker then impersonates your valid user One solution: generate random tokens and put onto the URL using output_add_rewrite_var() require token to match as well Best solution: remain in HTTPS 12