You are on page 1of 3

Interview with Robert “Rsnake” Hansen by David Sopas

David Sopas: How did you get interested in Web security?

Robert Hansen: One day I read a white paper on how you could use telnet of all things to
connect to any port you want and in the case of port 80 you could actually interact with
web servers. I couldn't believe it was true, because I thought telnet was a single use
program that spoke a specific protocol not a generic program that could talk to lots of
protocols. So once I telneted to port 80 and after some fiddling I saw HTTP headers and
data flying by. I couldn't believe my eyes. As soon as I saw it it was like a bolt of lightning
hit me. I finally got how totally insecure everything must be. Now mind you, this was
1995, so there weren't that many web applications out there that were interesting. But
every one that was out there suddenly seemed extremely exposed and ripe for
exploitation. It took my years to fully appreciate how right I was, but that's how I got my
first taste. It always surprises me how many security practitioners and web developers to
this day have never see HTTP headers.

DS: In your opinion, how has the Web security scene evolved in the last few years?
RH: Web security didn't exist when I started, there was no such thing and no one was
interested in it. There was literally just a handful of security researchers on earth at that
time, and even fewer who cared about websites. Back then it was all about being a good
sys-admin and a good network security guy. Much later a concept called CGI security was
in vogue because SSI and Perl opened people's eyes to how easy it was to make dynamic
websites. Much later the term webappsec came out and even then there were only a
handful of people who cared about it. It took many many years before people suddenly
realized that network security had forced everything to tunnel over HTTP. The day I heard
about a project that was designed to tunnel TCP over HTTP was when I realized there was
no stopping web security. It's here to stay.

DS: Are websites that you assess more insecure today in comparison to 3 years ago?
What changed?
RH: I don't assess the same websites that I used to assess. The kinds of websites I asses
now tend to be bigger in scope, but no, I don't see any major shift in the amount of
vulnerabilities except if you're talking about ASP.NET. The only reason ASP.NET is more
secure is because of ViewStates which, if encrypted and verified really does cut down on
certain vulnerabilities, like CSRF and XSS. The rest of the vulns, unfortunately, are still
there, as always. I don't like talking about compliance but PCI does seem to have forced
people to fix some of the lowest hanging fruit, but if you poke at the sites even a little, or
heaven-forbid, log in, you find that those automated scanners really aren't doing much.

DS: Of all the vulnerabilities out there, why did you decide to devote almost your work to
XSS? Do you consider it the most dangerous?
RH: I certainly do not consider XSS to be the most dangerous exploit. That honor should
be reserved for command injection, RFIs, SQL injection and so on. But I do consider XSS
to be the perfect blend of easy and high damage potential. If I'm an attacker who is new
on the scene, but wants to make a ton of money, why am I going to invest a ton of money
and time in learning something complicated when I can do the same damage with a single
line of JavaScript? It just doesn't make sense. So while I don't think it's the worst exploit
out there, it's so easy that it's impossible to ignore. Criminals don't care if the attack is
sexy or not, they just want money - so it's not really important to me what some people in
the security world tend to think - I'm much more interested in reality. I think it gets a bad
rap because it's not as sexy as other exploits, but if I can own your network with a few
lines of JavaScript or worse yet a single line of HTML if we're talking about CSRF, I
personally don't care how cool other exploits are - they're just far less likely. XSS and
CSRF are here to stay.

DS: Why are XSS errors so easy to make?

RH: Output encoding is a simple concept, but no one tends to understand how many ways
there are to bypass basic output encoding. Just because out encoded something to land
in HTML doesn't mean your buddy who is working on the same code won't throw it into
JavaScript space, or CSS space, or somewhere else. It's really hard to know where
something is going to be used unless you're in control of every aspect of the code. And
even then it requires that you know about the vulnerability. It's easier to get it wrong than

DS: What are some examples of the damage XSS flaws can cause?
RH: They have been shown (in various examples) to break into internal networks, take
over your local computer, steal credentials, phish usernames and passwords, change
information in websites, port scan, etc... etc... Really, aside from hiding your car keys and
dating your wife, XSS is capable of just about any bad thing you can think of. It's the swiss
army knife of client side vulnerabilities.

DS: Talk me about your book "Detecting Malice". Why people should read it and who
should read it?
RH: I wrote Detecting Malice as an extension to my blog. I thought it would be a good idea
to give security practitioners, programmers, analysts and so on, the insights that I've had
over the years. I tried to make it extremely easy to read, even though it goes over some
very complex topics. I used lots of real world examples, even if in some cases I had to be
vague to protect the innocent or guilty. A lot of the various security vendors have bought
the book and are talking about how they can try to implement some of the ideas in their
code. Now that would be interesting!

DS: What is the next area of application security to pay attention to?
RH: Inter-protocol exploitation is a hugely under-researched area of security. I'd love to
see someone really tackle that one, and prove how weak Mozilla's black-list port blocking
really is. You'd think after attacks against VOIP, Sendmail, IMAP3 and IRC they'd agree a
whitelist makes a lot more sense, but I think they're worried about breaking things. I hate
that we have to break the browser more than it already is for them to do what's right, but
that's where we are, I guess.

DS: What are your plans for the future? Any exciting new projects?
RH: I have more projects than I know what to do with. But I'm shutting down
as soon as I get to 1000 posts. I think after years of running that site, I need a well-earned
break. Unfortunately, I more busy than ever, so my plans are to grab a few beers with id
(the guy who runs the network) and then get back to work. There's no time to rest in this

DS: To end this interview, do you have some final words to our portuguese readers?
RH: Yeah, if you love security, don't let the people at the top of the security industry dictate
the terms by which you do your research, disclose your vulnerabilities, or do your job. You
have a ton of potential, and life is too short. My Father used to tell me that if you love what
you're doing you'll never work another day in your life. To paraphrase him - if you aren't
having fun in security, you're doing something wrong. Put a smile on your face, and go do
what makes you happy!

You might also like