1. Web Application Security (and why it matters to YOU!) By Mark Bristow and Doug Wilson

2. 2 Your presenters today Doug Wilson Security Lead and Network/Systems Engineer for EMIB at NIH DougWilsonMoo@gmail.com Mark Bristow Application Security Engineer at GAO Mark.Bristow@gmail.com (and yes, we are “security guys”)

3. 3 Why we are here A brief discussion on What is Web Application Security? Why does it matter to you? Instances of real-world problems... And what you can do to remediate them.

4. 4 What is Web Application Security? (the elevator speech)

5. 5 Web application security is... An overall process that Starts in the initial planning stages Requirements gathering Business logic Application structure and design Continues through Coding Testing Deployment And doesn’t finish until The full lifecycle of the application Including decommissioning

6. 6 But why should this matter to me? No one would ever bother with my web site. We already have “security” We use open source -- it has peer review We use a vendor -- it has the vendor backing it and they are getting better these days We keep up on patches/versions/revisions “So we have a firewall, an IDS, an IPS, and use SSL... we’re covered... right?”

7. 7 The time to fix this is NOW The web was designed as a trusted environment. It is NOT that anymore. Web technologies allow a degree of interoperability and integration of data never before dreamed of, for good and for bad. Web applications are still “emerging technologies” for most organizations. The drive to stay competitive results in unrealistic expectations and unsafe practices.

8. 8 Recent IT nightmares VA and other government agencies 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 Jul-Dec 2006 (from March 2007) 2,526 vulnerabilities in 2006 (second half) 66% affected Web Applications!!! Government Sector had the highest percentage of data breaches that could lead to identity theft 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 very costly, it can damage intangibles. Public sector groups often care more about intangibles. Private sector financial damages can put you out of business. Regardless of the who the bad guy is, the liability lies with the people who create and maintain these systems and their management.

11. 11 OWASP Top 10 Cross Site Scripting (XSS) Injection Flaws Malicious File Execution Insecure Direct Object Reference Cross Site Request Forgery (CSRF) Information Leakage and Error Handling Broken Authentication and Session Management Insecure Cryptographic Storage Insecure Communications Failure to Restrict URL Access

12. 12 Cross Site Scripting What is Cross Site Scripting? Getting the user to execute arbitrary code in their web browser Why is XSS So Dangerous? Compromise victim computer Can steal user’s authentication credentials Intranet Port scanning Stealing Sensitive Data Key/Mouse logging WebWorms XSS is everywhere FBI, AOL, HBO, CNN, BBC, FOX, Weather.com… to name a few

13. 13 Injection Flaws Come in many flavors: SQL, LDAP, XPath, XSLT, HTML, XML, OS command injection, and more SQL Injection What is SQL injection? Injecting code to modify the intent of a SQL query What happens if I set my password to ‘ OR ‘z’=‘z? 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’ p\/\/nd

14. 14 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. Validate and type all input as strictly as you can. Encode and control all output as strictly as you can.

15. 15 Malicious File Execution Often found when developers directly use user input with file streams Can allow for remote code execution, root kit installation and more. Include $userinput.”.php”

16. 16 Insecure Direct Object Reference Occurs when a resource object is directly called via user input. Examples Directory Traversal Source code disclosure

17. 17 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? In fact, let’s talk about this for a moment

18. 18 Input and Output 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 Double-escaping and understanding the logic of how this works Regex – Your new best friend <3 Output Encoding Output should be encoded to match the delivery medium HTML Entity encoding will stop 99% of XSS attacks = > & = & ……

19. 19 Mechanics of good Validation Techniques 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 Examples Lets generate a white list for a “name” field Lets generate a black list for the same “name” field

20. 20 Sanitization Issues Lets sanitize the name field against script injection String name = request.getParameter( "name" ); name.replaceALL(“script”, “”); out.println(name); Is this a white or black list? 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 How would you take care of a text area?

21. 21 Object Access, Part II This (and other things on the list) is not strictly a code issue Server configuration is also key, and flaws in server software need to be patched ASAP. If you don’t need the functionality in the application, don’t have it, or make sure you do it safely.

22. 22 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” or session riding or XSRF Exploits pre-established trust relationship (session) to force authorization High remediation costs Malicious requests and legitimate requests are indistinguishable. Origionally dates to 1998 but is just becoming well understood Example Victim logs into their bank website Victim views attacker’s blog or infected page CSRF Exploit initiates a request to the bank website to make a money transfer User’s state automatically appended to CSRF Request Bank sees an authenticated and valid request to the transfer action to transfer funds and executes it Attacker gets victim’s money

23. 23 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 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)

24. 24 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? “Logic flaws” and why they are only really found by people.

25. 25 The AJAX question Does AJAX and other similar technologies make for “worse” application security? What about web services? Hot topic of debate -- 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, and hide exploitation from being readily visible. Minimalist approach is best

26. 26 The Sky is 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

27. 27 Pick a place, we can add security Already up and running? Assessments -- Humans and Tools Managed Services WAF/IPS/IDS -- Monitor, Monitor, Monitor!!!! Deployment Make sure it’s secure before it goes out the door Development Educate your developers Code review -- Humans and Tools Architecture Educate your architects consider security from day one

28. 28 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

29. 29 Resources Sites http://www.owasp.org http://www.webappsec.org/ http://ha.ckers.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

30. 30 Questions? Doug Wilson -- DougWilsonMoo@gmail.comDougWilsonMoo@gmail.com Mark Bristow -- Mark.Bristow@gmail.comMark.Bristow@gmail.com