Date post: | 02-Nov-2014 |
Category: |
Technology |
Upload: | adrian-schneider |
View: | 5 times |
Download: | 0 times |
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> → <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" /><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.