Web Application Security

A brief introduction to developing more secure applications for a safer internet.

Do not hesitate to ask any questions throughout the presentation!

Adrian Schneider

CTO / Co-Founder of Startup:Upscale International

6 years of development on the web Zend Framework / OOP Enthusiast Worked with hundreds of online communities

High traffic / large data sets High profile / angry members / high attack rates

Responsibility

As a developer, it's our responsibility to develop secure applications.

This responsibility is both moral and in many cases, legal.

The Risks

If you develop a sub-par application, and deploy it to a production environment, then

YOU are at risk.

Your job, your reputation, your business...

It doesn't matter if you are a freelancer, a contractor, an employee or a business owner.

The Risks

The Client or Customer Their credibility Their sensitive information Their website / business Their revenue

The Visitor Their trust in your client / website Their sensitive information Their computers

The Risks

Websites take a long time to earn trust

Trust is psychological, but can also extend to the visitor's browser security settings

Legal implications / Privacy Policy

Trust is very difficult to earn back The average person trusts a stranger more than

somebody has broken their trust.

The Risks

Read/write/delete content Pages Visitor Accounts / Admin Accounts Other websites or information on your server Other sensitive information

Add viruses to your website Visitors can no longer trust the site

Use your server for other attacks, or spam You can get blacklisted from sending mail You are now part of the problem

What is Hacking

Hacking is exploiting flaws in a system to do things that you shouldn't be able to do

Let's look at how an application typically works...

An Application

Applications read input, and respond with output.

-GET (URL)-POST (Form data)-Cookies Rendered Web Page

(or XML, JSON, etc.)

SessionsDatabaseFile Systemetc.

EXTERNALVARIABLES

OUTPUTINPUT APPLICATION

0

Never trust ANY user input This includes

URL / Query String (“/posts/?p=5”) POST Data (form submissions, uploads, etc.) Cookies

Always note data type. If you expect an number, then force it to be one.

What happens when the user enters other types? (arrays, for example)

User Input is Malicious

Types of Attacks

SQL Injection

Cross Site Scripting (“XSS”) & Cross Site Request Forgery (“CSRF”)

Others... DNS Poisoning DoS / DDoS attacks Session Fixation Brute Force / Rainbow Tables Spoofing (IP, Referrer)

SQL Injection

What is SQL? Database access language(programmatic access to spreadsheet-like data)

This is how applications typically read/write data

Reading:SELECT title, message FROM comment;

Writing:INSERT INTO comment VALUES ('x', 'y', 'z');

SQL Injection

SQL injection occurs when we put untrusted input into a database query.

Example:

$username and $password are variables representing fields posted through a form.

INSERT INTO user (username, password, admin)VALUES ('$username', '$password', false);

SQL Injection

For the average visitor, this is okay.

What happens if the user's name contains a single quote, which is used to separate the query instruction from a literal value?

They'll get some sort of error page.

SQL Injection

The good kind:

Something broke. That's all you need to know...

SQL Injection

The bad kind:You have an error in your SQL syntax; check the manual that corresponds to your

MySQL server version for the right syntax to use near ''' at line 1

INSERT INTO user (username, password, admin)VALUES ('Mr. O'Neil', 'f4k3p4ssw0rd', false);

Not only does this confuse/anger the visitor, but it reveals sensitive information about your application.

Error Handing

Never show errors in production

Log errors so they can be fixed Do check for them Or have them emailed instead

This way you will see potential bugs/security holes, and you can fix them promptly.

You may even catch hackers in the act.

SQL Injection

Examples of exploits: Writing data to fields the user was not supposed to.

Reading restricted data, and displaying it on the page. MySQL's built in tables (ex: user accounts) Other data on the site (visitor accounts, private content, etc.)

Executing multiple queries Potentially deleting entire tables, modifying privileges, etc. Inserting data into other areas of the site, or other sites on the

same database server

The attacker is often limited by: The actual query they are modifying Database configuration & permissions

SQL Injection Example

Often you'll see URLs like this:

http://site.com/page.php?id=12

Simply inserting a ' after the 12 should reveal if the page is easily exploitable.

If it is, you can potentially pull any information from the database and display it on the page.

Preventing SQL Injection

Do not use user input directly in queries.

To prevent quotes from breaking the query, you must “escape” them.

To escape a quote, you put a backslash in front of it.

In MySQL (depends on your database) Some systems use a second quote to escape it. ( '' )

Preventing SQL Injection

Bad: do not simply escape quotes! PHP: addslashes() - converts ' to \' There are ways around this!

Good: use your database's built-in escape functions

PHP: mysql_real_escape_string Properly handles your database's character set (multi-

byte characters) for the current connection

Best: Prepared Statements ... PHP: MySQLi, PDO

Prepared Statements

Instead of including user input in queries, a prepared statement sends it separately.

SELECT * FROM user WHERE id = :user_id

:user_id is a placeholder, and the values no longer need to be escaped to avoid injection.

Code quality also increases No more nasty concatenation No more hoping you escaped every query properly

SQL Injection Summary

Sanitize all input before using it in a query.

Cross Site Scripting (XSS)

Occurs when users modify HTML on your site.

This can be from posting HTML into something that gets saved and shown to other visitors

This can be from linking to your site from their own site if you directly show input on the screen.

XSS Risks

Attackers can hi-jack your user sessions. This can include admins At this point, all content on your app is at risk again.

Attackers can inject malicious HTML Client-Side security typically sucks. (Think IE6)

(Browser exploits, Font exploits, PDF exploits, etc.)

These are things that can damage the visitor's system. Viruses, other cookies, saved passwords, remote file

execution, etc.

At this point, the site's credibility is completely shot.

Preventing XSS

Do NOT allow users to post HTML Filter out any HTML tags if possible Partial filtering is hacky, and unreliable (allow only

<strong>, <em>, etc.) Inline CSS and JavaScript is also vulnerable!

Always escape any user content before printing it on the page.

<script>alert('XSS')</script> → &lt;script&gt; ....

This includes non-obvious input, such as URL parameters or even the request URL!

Cross Site Request Forgery (CSRF)

This one is not so easy.

CSRF occurs from remote sites, when the remote site can perform actions on your site on behalf of the user.

These attacks are extremely dangerous, and are very often overlooked.

Basic CSRF Example

Let's assumed you are logged in to your site (“A”), or your session is still active.

You visit site B, which contains this:

<img src=”http://yoursite.com/admin/user.php?do=delete&id=1” alt=”” width="1" /><img src=”http://yoursite.com/admin/user.php?do=delete&id=2” alt=”” width="1" /><img src=”http://yoursite.com/admin/user.php?do=delete&id=3” alt=”” width="1" /><img src=”http://yoursite.com/admin/user.php?do=delete&id=4” alt=”” width="1" /><img src=”http://yoursite.com/admin/user.php?do=delete&id=5” alt=”” width="1" />

Your session is still active on site A, so you have just unknowingly deleted 5 accounts.

More on CSRF

CSRF doesn't just need to be a GET request. You can also post form data back to the vulnerable site, even avoiding requiring any action from the user.

CSRF Solution

You only want to accept requests that originated from the same site.

Check referring page

Generate a security token at login, and pass it with each form. Deny all submissions that do not have the correct token.

Token should be a randomly generated string (such as a hash)

Notable Attack Victims

GMail YouTube All Google Sites (again) eBay Twitter MySpace Digg BC Online Gambling Site (last month)

Most of these were XSS / CSRF attacks. SQL Injection tends to happen more on lower

profile sites.

Closing Best Practices

Don't store plain-text passwords. Ever. Encrypt passwords with proper algorithms OR Hash passwords with salt

Always give minimum access to server accounts

File permissions Don't run things as root Database privileges should be restricted (drop tables?)

Use different accounts/passwords If one gets compromised, the rest will still have a

chance. Secure passwords too please. Symbols are fun.

Summary

Be responsible for your application Properly sanitize all input before using it Validate user sessions

Apps will never be 100% secure, because: Client machines can be compromised People use weak passwords, or give them out openly Network communications can be intercepted Hosting environment can be compromised Technology is always advancing

Do everything you can. Stay up to date.