Basic Housekeeping - Plugging Obvious Security Holes In Web Sites - Paris Web2009

7,335 views

Published on

My talk at Paris Web 2009 about basic web security and how to avoid opening your site for attacks.

0 Comments
6 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
7,335
On SlideShare
0
From Embeds
0
Number of Embeds
412
Actions
Shares
0
Downloads
63
Comments
0
Likes
6
Embeds 0
No embeds

No notes for slide

Basic Housekeeping - Plugging Obvious Security Holes In Web Sites - Paris Web2009

  1. 1. Basic housekeeping Plugging obvious security  holes in web sites. Chris9an Heilmann, Paris Web, Paris, October 2009
  2. 2. A few things to remember  about basic web security.
  3. 3. A bit of pimping... Gérer la sécurité de vos applica9ons web (Salle 1) Présenté par : Sébas9en Pauchet (WS Interac9ve),  Frank Taillandier (Académie de Toulouse) a.k.a. Dirty Tricks with @DirtyF
  4. 4. The most annoying thing  is that the dangers on the  web are underes9mated.
  5. 5. Reasons for aRacks: Spam injec9on. Iden9ty theT. Data mining. Botnet / Zombies / DOS
  6. 6. A lot of clever terms are  used in security. SQL injec9on  XSS  CSRF ClickJacking  Phishing
  7. 7. In the end, a lot is about  keeping your web  products clean.
  8. 8. This very much starts on  the server side.
  9. 9. Think about your folders.
  10. 10. Telling the world too  much.
  11. 11. You don’t want the admin  folders of your app to be  indexed by Google Search Engines.
  12. 12. Your system might tell  more about your site than  you are aware of.
  13. 13. Error messages are only  needed in produc9on ‐ on  live servers they can tell  more than you want to.
  14. 14. Keep your server setup  secure.
  15. 15. hRp://yoursite.com/index.php?admin=true hRp://phpsec.org/projects/phpsecinfo/
  16. 16. hRp://phpsec.org/projects/phpsecinfo/
  17. 17. Basic server measures: Turn off folder browsing. Stop bot indexing (robots.txt). Secure your setup. Turn off error messaging. Disallow remote file inclusion. Delete old and orphan files.
  18. 18. The next danger is blindly  relying on soTware.
  19. 19. Predefined backdoors and  passwords.
  20. 20. admin/admin admin/password default/default user/user preset/preset buil9n/buil9n
  21. 21. Plugins
  22. 22. Basic soTware measures: Change every password. Check for presets. RTFM. Keep Plugins up‐to‐date. Check for security holes. Don’t trust “easy setup”. Upgrade.
  23. 23. Front end security issues. 
  24. 24. This is not hard. Don’t trust any user data. HTML is not a database. JavaScript is not a secure data  container. Do not rely on JavaScript.
  25. 25. Frontend is public. If you comment, comment on  the backend, do not  “comment out” func9onality.
  26. 26. Frontend is insecure. Anything in the frontend is  executed and can be used to  steal all your cookies. (frames, images, scripts, links...)
  27. 27. Filtering hRp://us2.php.net/manual/en/book.filter.php
  28. 28. Whitelis9ng
  29. 29. Clickjacking.
  30. 30. Basic frontend measures: Break frames. Filter inputs. Whitelist inputs. Avoid hacks (expression()). Avoid URL assembling.
  31. 31. Our users
  32. 32. Social engineering.
  33. 33. SocEng basics: Show authority. Create fake need of urgency. Take over responsibility.
  34. 34. Condi9oning helps. :‐(
  35. 35. I approve  of this!
  36. 36. Social networks
  37. 37. Step 1: Log in yourself
  38. 38. Step 2: Get list of followers
  39. 39. Step 3: Set the trap
  40. 40. http://twitter.com/statuses/ user_timeline/codepo8.xml? count=200
  41. 41. Step 4: Lure his followers
  42. 42. None  of this!
  43. 43. Predictability
  44. 44. Basic people measures: Don’t allow for auto log‐in. Share security responsibility with the users. Avoid stressful interfaces. Be very open about your  communica9on.
  45. 45. Bot aRacks.
  46. 46. Captchas to the rescue? hRp://caca.zoy.org/wiki/PWNtcha
  47. 47. Bot aRack measures. Honeyponng. Timed interfaces. Cookie check / Crumbing. Spike detec9on.  OpenID / third party logins.
  48. 48. Nothing beats being up‐ to‐date!
  49. 49. None  of this!
  50. 50. I approve  of this!
  51. 51. You learn a  lot from logs.
  52. 52. No strength in numbers.
  53. 53. Check your posts.
  54. 54. And query terms.
  55. 55. Some not‐so sci‐fi ideas...
  56. 56. Guest passes.
  57. 57. oAuth
  58. 58. OpenID
  59. 59. Caja/ADsafe
  60. 60. Caja limits and  secures web  standards.
  61. 61. Caja vs. “HTML” ★ Custom aRributes ★ Custom tags ★ Unclosed tags ★ <embed> ★ <iframe> ★ <link rel=‘… ★ javascript:void(0)  ★ Radio buRons in IE ★ Rela9ve url’s
  62. 62. Caja vs “JavaScript” ★ eval() ★ new Func9on() ★ Strings as event handlers (node.onclick = '...';) ★ Names ending with double / triple underscores ★ with func9on (with (obj) { ... }) ★ Implicit global variables (specify var variable) ★ Calling a method as a func9on ★ document.write  ★ window.event ★ .onclick ★ OpenSocial gadgets.io.makeRequest return JS
  63. 63. Caja vs “CSS” ★ * hacks ★ _ hacks ★ IE condi9onals ★ Insert‐aTer clear fix ★ expression() ★ @import ★ Background images in IE
  64. 64. Throwaway logins.
  65. 65. New challenges.
  66. 66. Social Network aRacks
  67. 67. The mobile web.
  68. 68. Camera access.
  69. 69. Loca9on based services.
  70. 70. Biometric recogni9on.
  71. 71. Right now things are not  safe.
  72. 72. But you can help making  the web safer.
  73. 73. Keep it clean, keep it up‐ to‐date and be alert.
  74. 74. MERCI!   Chris9an Heilmann   hRp://wait‐9ll‐i.com    hRp://developer‐evangelism.com   hRp://twiRer.com/codepo8   

×