Web Security Demystified Justin C. Klein Keane Sr. InfoSec Specialist University of Pennsylvania School of Arts and Sciences Information Security and Unix Systems Twitter: MadIrish2600

Overview About your site, from evil eyes Attacker objective Means of attack Motive Why this stuff works What you can do

Erroneous Assumptions “I'm running a small site, who would want to hack it?” “I back everything up nightly, at most I'll only lose a days worth of stuff.” “I'm the only one with admin rights, so it's not an issue.” “It doesn't matter if the site goes down from time to time.” Your data isn't necessarily what an attacker wants!

Risk Analysis Risk is often calculated as:  Threat x Impact x Likelihood Unfortunately quantifying “threat” is almost impossible Likelihood is also tough to gauge Impact we can do though (maybe)

Objectives First the obvious ones:  p0wn your box3n  Deface your website  Abuse your e-commerce  Steal your data  Account access

Objectives (cont.) Less obvious:  Black hat SEO  Bandwidth (botnets) Spam Phishing Fast flux DNS  Hosting Drive by download RFI  Click fraud

Objectives (cont.) Ultimately you can never predict!

Means Script injection (user trust exploitation)  Stored and reflected XSRF (application trust exploitation) SQL Injection Account compromise  Brute force  Session flaws  Social engineering

Means (cont.) Privilege escalation Social engineering  Trust exploitation (content) Information disclosure Code execution Application exploitation  When features become flaws Access control bypass

Means (cont.) 10 years ago XSS wasn't a threat New means emerge regularly

Motive Prestige Money Political The world may never know...

Why hacking works Security is a specialization Security is an evolving, moving target No easy way to automate vulnerability detection Web app attacks don't require proximity Your site is always on You have to be right 100% of the time, the bad guys not so much

Unfortunately Software security flaws are inevitable Studies show a certain number of bugs per X lines of code A percentage of bugs will be security related

A Word... Open source vs. closed source  No matter what anyone tells you, neither is more secure Check out Verscode's analysis:  html html Closed source does put more onus on the vendor though

Roots of the Problem Mixing data with code  HTML is inherently flawed in this respect  Where does display stop and execution begin? Input validation Output validation It's usually easier to do things in an unsafe way

Emerging Sources of Vulnerability The web is evolving! Flash or other animation AJAX Remote data sources, API's and interoperability New platforms, code, and technology New programmers

Learn to Commit to an application lifecycle  Security is an ongoing process  Plan for vulnerabilities, and patches! Be sure your code evolves as threats do Keep your components up to date Use all the security tools of the stack  Database, filesystem, operating system, etc.

Learn to Protect, detect, react  If you can't prevent, log!  Segregate your detection mechanisms KISS  Complexity is the enemy of security Enforce permissions  You are using permissions right?  Privilege separations and privilege enforcement

Extend your Security Bake security in (from the start) Add security on  Use additions like: IDS Web application firewall IPS Encryption Code review and penetration testing etc.

Questions Thanks!