Web Application Security

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.) Sessions Database File System etc. EXTERNAL VARIABLES OUTPUT INPUT 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> -> < script > ....
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" />
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.

Web Application Security

by Adrian Schneider on Aug 25, 2010

Accessibility

Categories

Tags

Upload Details

Usage Rights

1 Embed 1

Statistics

Web Application Security — Presentation Transcript