1 / 48

Overcoming your web insecurity

Overcoming your web insecurity. Kirk Jackson Xero www.xero.com pageofwords.com kirkj@paradise.net.nz. This talk. Introduce some common threats Quick wins Best practice Not a comprehensive treatment. Demo. Classifieds Web Site Starter Kit Rebranded:

symona
Télécharger la présentation

Overcoming your web insecurity

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Overcoming yourweb insecurity Kirk Jackson Xero www.xero.com pageofwords.com kirkj@paradise.net.nz

  2. This talk • Introduce some common threats • Quick wins • Best practice • Not a comprehensive treatment

  3. Demo • Classifieds Web Site Starter Kit • Rebranded: • A couple of small tweaks for demo purposes 

  4. Demo Users Kirk Site Admin Chrome Marge Regular User IE Bob Naughty User Firefox

  5. Threats • Employees / students / other authenticated users • Malicious third parties • Malware • Phishing • Anonymous users

  6. Things we shouldn’t trust • GET’s • POST’s • Headers • Cookies • Any user content

  7. GETurl It’s very easy to edit a url • Nothing sensitive • Nothing destructive • No updates or deletes (idempotent) http://google.com/?q=codecamp GET /search?q=codecamp

  8. GET - demo

  9. POST data • Send data in the body of the request, rather than the url • Still just as easy to fake POST /path/foo.aspx HTTP/1.0 User-Agent: EvilHacker/2.0 Content-Type: application/x-www-form-urlencoded id=7&title=Hello

  10. POST - demo

  11. Redirects • Don’t redirect to untrustedurls

  12. Redirects - demo

  13. Cookie data • Use ASP.NET forms auth for authentication • Secure, non-predictable • Use Session for state • Only store unimportant stuff in cookies (theme choice vs username)

  14. Session • Not as bad as you might think! • Encrypting, transmitting, round-tripping probably worse than server memory usage • ASP.NET Session ID is hard to guess

  15. Storing and using data • Authorisation / Role: Server side only • Navigation data: In the url is fine (check access on server side) • Presentation flags / theme / lang: fine in cookies • Hidden fields: preferably change to server-side • Validate every request • Application secrets: Never visible to client

  16. SQL Injection • Use parameterised SQL so that arguments are escaped

  17. Phishing • A fake version of your website • Really hard to protect against! • User education is our best protection • Train to look at url bar (yeah, right!) • Never send links via email • Always address emails with their name

  18. Phishing – demo http://sideshowbob.local/fakelogin.aspx

  19. Framebusting • Many attacks wrap your page inside a frameset to trick the user • Bust out of your frame if (parent.frames.length > 0) { parent.location.replace( self.document.location); }

  20. Framebusting - demo http://sideshowbob.local/iframe.aspx

  21. XSS – Cross site scripting Displaying untrusted user input • Often used to steal a cookie

  22. XSS – Demo

  23. XSS – Cross site scripting Displaying untrusted user input • Sanitise all input • Encode all output • HTTP Headers – don’t insert untrusted content • Some ASP.NET controls don’t encode output • Use Anti-XSS Library rather than HttpUtility

  24. CDRF – Cross domain request forgery Posting a form from one website to another

  25. CDRF – Demo

  26. CDRF – Cross domain request forgery Posting a form from one website to another • Cookie checks aren’t enough • ViewState isn’t enough • Check referer • Use a token in the POST data / ViewState to validate

  27. Clickjacking • E.g.Content hidden behind a flash animation • Flash, CSS, PDF • Newly disclosed

  28. Clickjacking demo Here: http://blog.guya.net/2008/10/07/malicious-camera-spying-using-clickjacking/

  29. Clickjacking • E.g.Content hidden behind a flash animation • Flash, CSS, PDF • Newly disclosed

  30. Protection

  31. IIS / Windows • It all starts with the server • Patching • Hardening • File permissions • Open ports / network access • Other users

  32. Authentication / Authorisation • Use platform features wherever possible • Forms Authentication • Role based security • Web.config <authorization> • Every non-anonymous entry point should have an access control check • Every on-click, validator or update • AJAX libraries may side-step some of the page lifecycle

  33. Validation • Always remember to (re)validate data on the server side • If a multi-step process: • After every request • On final step

  34. ASP.NET Controls • The base ASP.NET controls come from a simpler era... • Some controls encode their Text, others don’t • Be careful! • Security Runtime Engine (coming) may help

  35. Protect static files / temporary files • Use file permissions on Windows • Store temporary files outside of the webroot • Ideally generate on the fly rather than off disk

  36. Protect your web.config • Use integrated database authentication • Encrypt connection strings • Permission files so that the website user(s) can’t modify them • Turn on custom errors • Don’t send stack trace to users

  37. Session attacks • Replay attacks • Man in the middle • Request forgery

  38. ViewState • Understand how ViewState works in ASP.NET • Evaluate your use of it for storing values • Is Session a safer choice? • Encrypt / tamper protection • Be mindful of the round-trip costs

  39. Fail safe • In case of failure, make sure the default state is secure • What if logs are full or can’t be written to?

  40. Logs • Logs should be write-once, read-many • Logs should be rotated, backed up securely, disposed of securely, confidential • Many uses: • General debugging • Forensic evidence • Attack detection • Quality of Service • Proof of validity – app working correctly • Each has different requirements • Always archive, rather than empty logs

  41. Mixing Administration • Administrators are not normal users – segregate them • Keep admin cookies on a different domain if possible

  42. Take-aways • Don’t trust anything given to you by the user’s browser • Be careful where you store sensitive stuff • XSS, CDRF, Clickjacking

  43. References • Clickjacking: http://ha.ckers.org/blog/20081007/clickjacking-details/ • Framebusting:http://pageofwords.com/blog/2008/10/06/FrameBustingInJavascript.aspx • ASP.NET Controls that need encoding: http://blogs.msdn.com/sfaust/archive/2008/09/02/which-asp-net-controls-automatically-encodes.aspx • AntiXSS library • Security Runtime Engine (coming) • OWASP – The Open Web Application Security Project – http://www.owasp.org

  44. More info http://pageofwords.com – my blog Come along to the Microsoft Unplugged day: • Tuesday 11 Nov, 1-5pm • Christchurch Convention Centre • WPF3.5 SP1 • Visual Studio Tips and Tricks

More Related