1

Lecture 14 – Web Security

SFDV3011 – Advanced Web Development

Types of Vulnerability

In web applications, there are 5 categories of vulnerabilities :

1. SQL Injection2. Cross-site Scripting (XXS)3. Cross-Site Request Forgeries (XSRF)4. Session fixation5. Session hijacking

2

SQL Injection

Consider the following query:

SELECT fieldlistFROM tableWHERE field = '$email'

What if $email contains: anything' OR 'x' = 'x

3

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

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

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

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

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

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):

<img src="http://Site-A.com/transfer.php?

to=badguy&amount=1000000">

• 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

XSRF Mitigation

<?php$token = md5(uniqid(rand(), TRUE));$_SESSION['token'] = $token;$_SESSION['token_time'] = time();

?><form action="transfer.php" method="post"><input type="hidden"name="token" value="<?php echo $token; ?>"><!-- rest of form -->

10

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

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