Web Application Security

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

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. 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. What is Web Application Security? (the elevator speech)

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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. Insecure Direct Object Reference • Occurs when a resource object is directly called via user input. • Examples • Directory Traversal • Source code disclosure

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. 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 • < = &lt; > = &gt; & = &amp; ……

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. 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 = “<script>alert(‘I pwnt j00’);</script>” • Result: <>alert(‘I pwnt j00’);</> • Name = “<scrscriptipt>alert(‘I pwnt j00’);</scrscriptipt>” • Result: <script>alert(‘I pwnt j00’);</script> • Sometimes this is a necessary evil • How would you take care of a text area?

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. 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. 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. 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. 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. 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. 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. 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. 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. Questions? Doug Wilson -- DougWilsonMoo@gmail.com Mark Bristow -- Mark.Bristow@gmail.com