1. 1 Web Application Security (and why it matters to YOU!) -Remix- By Mark Bristow and Doug Wilson Mark.bristow@gmail.com DougWilsonMoo@gmail.com

2. 2 Your presenters today are Doug Wilson Senior Application Engineer at SAIC Mark Bristow Information Assurance Engineer at SRA International

3. 3 Why are we here?

4. 4 A brief discussion on What is Web Application Security? and why does it matter? A look at the top problems on the web today And what you can do to remediate them. So, what is web application security?

5. 5 Web application security is... An overall process that Starts in the initial planning stages Continues through coding, testing, and deployment Doesn’t finish until the lifecycle is completely finished

6. 6 But why does this matter to me? Overcoming Denial No one would ever bother with my web site. We already have “security” We use open source We use “that” vendor We keep up on patches “So we have a firewall, an IDS, an IPS, and use SSL... we’re covered... right?”

7. 7 No, you are probably NOT ok... The web was designed as a trusted environment. It is NOT that anymore. Web applications are still “emerging technologies” for most organizations. The drive to stay competitive results in unrealistic expectations and unsafe practices.

8. 8 Looking at Some Recent IT nightmares VA and other government agencies  Personally Identifiable Information (PII) for 26.5 million veterans TJ Maxx and credit card processing  45 million credit card numbers AOL and User Data  19 million queries from 650,000 subscribers PaineWebber logic bomb  2000 servers, over $3.1 million just to restore

9. 9 Web App specific numbers Symantec ISTR Jan-Jun 2007 (from September 2007)  “61 percent of all vulnerabilities disclosed were Web application vulnerabilities.”  “users... can no longer place their trust in well known sites.” CIO Magazine interviews Jeremiah Grossman (5/07)  Vulnerabilities in 80% of websites analyzed  Remaining 20% are mostly static sites  Most C-level execs they talk to think firewalls protect against web application attacks -- THIS IS NOT TRUE!!!

10. 10 The bottom line? -- Liability Liability is not only costly financially, it can damage intangibles beyond repair. Even if you can afford to lose money, how much is your reputation worth? Regardless of the who broke it, the liability lies with the people who create and maintain these systems and their management.

11. 11 So, how can we fix this?

12. 12 OWASP -- what is that? Open Web Application Security Project www.owasp.org  Top Ten  “Guides” Building secure web apps and services Application testing Code review  Code projects  Local Chapters, meetings, and conferences

13. 13 OWASP Top 10 – err... Top 5?  Cross Site Scripting (XSS)  Injection Flaws  Malicious File Execution  Insecure Direct Object Reference  Cross Site Request Forgery (CSRF)

14. 14 Cross Site Scripting (XSS) What is Cross Site Scripting?  Occurs when an application takes user supplied data and sends it to a web browser without validating or encoding that content  In English: Can be anywhere you echo user input Getting the user to execute arbitrary code in their web browser XSS is everywhere, if you don’t find it, are you doing something wrong?

15. 15 Why is XSS so dangerous? Compromise victim computer Can steal user’s authentication credentials Intranet Port scanning Stealing Sensitive Data Key/Mouse logging WebWorms

16. 16 XSS Demo

17. 17 Injection Flaws Occurs when user supplied data is sent to an interpreter as part of a command or query Comes in many flavors: SQL, LDAP, XPath, XSLT, HTML, XML, OS command injection, and more

18. 18 Injection Flaws – SQL Injection So, most people here have probably heard of... SQL Injection Injecting code to modify the intent of a SQL query What can I do with SQL Injection? Break or bypass Authentication Has the potential to expose your database data to an attacker Attacker can potentially modify your database structure and data Select * from users where uname =‘’ and pw=‘’OR ‘Z’=‘Z’

19. 19 SQL Injection Demo

20. 20 Fixing Injection Flaws The top two flaws are based on Injection Most of these are easily solved by following a few simple concepts religiously, in the way that works for your environment. Don’t trust ANYTHING that comes from the client. Ever. 1. Validate and type all input as strictly as you can. 2. Encode and control all output as strictly as you can.

21. 21 Input Validation Client side -- doesn’t really do anything for security, though it still has its uses Server side – The only place where your validation provides security Regex – Your new best friend

22. 22 Mechanics of good Validation White listing – Pass only when content contains only known good input Black Listing – Fail when a known bad is detected Sanitization – “Clean” data before using it based on Black or White List

23. 23 Sanitization Issues Lets sanitize the name field against script injection  String name = request.getParameter( "name" );  name.replaceALL(“script”, “”);  out.println(name); Test cases  Name = “ alert(‘I pwnt j00’); ”  Result: <>alert(‘I pwnt j00’);  Name = “ alert(‘I pwnt j00’); ”  Result: alert(‘I pwnt j00’); Sometimes this is a necessary evil

24. 24 Output Encoding Output should be encoded to match the delivery medium If it will be HTML, HTML encode. Ex: < becomes < HTML Entity encoding will stop 99% of XSS attacks

25. 25 Implementing Input Validation We are going to implement a white list validation for the username field What charecters are allowed in usernames?  A-Z upper and lower case  Integers What regular expression matches this criteria  [a-zA-Z0-9] How would we implement it in PHP  if (preg_match('/[^a-zA-Z0-9]/', $username)){ *FAIL* }

26. 26 Implementing Input Validation

27. 27 Now, back to our top 10... or 5...

28. 28 Malicious File Execution Occurs when developers use user input directly in file or stream functions, or improperly trust uploaded content Can lead to rootkit installs and server compromise Many sites allow you to upload images or documents. The demo site allows you to submit reports. If this report submission is unfiltered you may be able to upload code to the website

29. 29 Malicious File Execution Demo

30. 30 Insecure Direct Object Reference A direct object reference occurs when a developer exposes a reference to an internal implementation object, such as a file, directory, database record, or key, as a URL or form parameter. Resource authorization checks should be conducted when the resouce is requested Common Examples  User ID on query string: showAccount.php?id=2345  Session ID on query String: index.php?PHP_SESSID=51h3nrstvi0mm60k2j179iqtg6  Directory Traversal

31. 31 Directory Traversal Demo

32. 32 Fixing Object Access Flaws Don’t trust ANYTHING that comes from the client. Ever.  Validate and type all input as strictly as you can.  Encode and control all output as strictly as you can. Do you sense a trend here? Perform authorization checks every time a resource is requested

33. 33 Cross Site Request Forgery (CSRF) When an attacker forces a victim’s browser to submit a request the victim did not intend to submit Also known as a “One click attack”, session riding or XSRF Exploits pre-established trust relationship (session) to force authorization High remediation costs Malicious requests and legitimate requests are indistinguishable. Originally dates to 1998 but is just becoming well understood

34. 34 CSRF DEMO

35. 35 Fixing CSRF CSRF is often labeled as “unfixable,” it’s inherent in how the web works. But you can take steps to help. Problems and safeguards  Data returned as javascript (Gmail) -- fixed by while(); loop  Digg article -- fix: secret tokens (a.k.a. Nonces)  Amazon One-Click -- fix: Password re-entered Fixes work -- unless you combine with XSS. Then the rules change, and some standard fixes go out the window (like secret tokens)

36. 36 The rest of the OWASP Top 10 Information Leakage  Error messages provide vital tools to an attacker Broken Session Management Insecure Cryptographic Storage Insecure Communications  SSL is a web attacker’s best friend Failure to restrict URL access  What happens when I request an admin page directly without logging in first?

37. 37 The AJAX question Does AJAX and other similar technologies make for “worse” application security? What about web services? Asynchronous applications and web services aren’t innately more “insecure,” but greatly increase complexity and attack surface. Both Asynchronous and Web Service style applications have the potential to reintroduce a lot of old problems. Minimalist approach is best

38. 38 Is the Sky Falling? The sky is NOT falling! All of the vulnerabilities mentioned here can be fixed Developer education and a robust software security program can help mitigate these issues Educate yourselves Educate your customers

39. 39 How do I get started? LEARN! What threats are out there and how they apply to your organization? Classify what data is most important to your organization Identify all of your web applications and assign them criticalities based on business needs and data classification Perform vulnerability assessments to determine how big the problem is “Bake security in” to your SDLC

40. 40 Resources Sites  http://www.owasp.org http://www.owasp.org  http://www.webappsec.org/ http://www.webappsec.org/  http://ha.ckers.org http://ha.ckers.org  http://www.sans-ssi.org/ http://www.sans-ssi.org/ Books  How to Break Web Software  Hacking Exposed : Web Applications  XSS ATTACKS Training  Certified Ethical Hacker (CEH)  Foundstone Ultimate Web Hacking  SANS Training Securing Critical Web Applications and Web Services (Aspect Security) Writing Secure Web Applications: Developer Training

41. 41 Questions? stop by onelittlewindow.org