The thing that strikes me is in the last six or eight years we've seen a big push toward software security, with what Microsoft has done with Trustworthy Computing. But, are these Web developers getting any of that training?
I'm glad you asked. If we're moving toward building the browser as the application or as the operating system, I mean, look at Google Chrome. The browser has a task manager. It is an operating system for all intents and purposes. It's not things you're installing on your desktop anymore, it's things you visit in your browser. This whole idea of storing things in the cloud to protect data, you're essentially yielding control to the people who write these latest and greatest Web apps. And it's like OK, what do these people know about security? It's kind of the same way the mid-90s desktop developers got their butts kicked. The same way desktop developers didn't know security, we're finding out Web app developers don't know security very well. They're not getting the types of training they need. You say cross-site scripting to them and they think that's stealing a cookie or popping up a little message dialogue. And you have to look at them and say, "Why do you think that message dialogue is appearing?" It's because it's code execution, I executed arbitrary code on your box. That's about as bad as you can get. The difficult part is, security used to be something the IT guys dealt with. That's something my IT guy put a little box on the perimeter to take care

of. But with application security, these are fundamental problems in the application itself. A firewall isn't going to help you with a Web app. A firewall is a gateway saying, yes you can talk to this port or no you can't. If no one can talk to your Web app, you don't have a very good Web app. The problem is we have this culture of quickness with our Web space. We have all these books, like learn Ruby in 24 hours. You can't learn anything in 24 hours. You can learn enough to be dangerous. You can learn enough to write really bad financial software. For the very applications you would want lots of thought to go into, we're putting no thought into. Let's go back in time a little bit here. Tell me about the infamous student research project you did at Georgia Tech that got you into a little bit of trouble.
Ah, once upon a time when I was young and silly. I was a student at Georgia Tech and I learned about our campus Buzz Card system and I found some security flaws in it and kind of learned firsthand the difficulty one can have in trying to do the right thing and letting them know there are issues, and how to remediate and solve when you discover vulnerabilities. Actually, this is a problem in the Web application security space as well, because people can reverse engineer or decompile and find buffer overflows and how it process and track changes of a Word doc. That stuff's processed on a desktop. For Web app security researchers, they have a really hard time. If I happen to inadvertently discover one of these things, how do I let them know? They own all the code. And by definition, you can't discover vulnerabilities on their apps without breaking the law. What are your thoughts so far on Google Chrome and what you've seen?
One, I'm glad somebody else is entering this space. Something I've heard a lot is, "why is Google doing this?" This is silly. We have had a lot of innovation stagnation after the first round of the browser wars, and now with IE 8 and Firefox 3 we're really starting to see great innovative features going in. And I love that. I love the fact that Google is going to play in this space. And I really love the platform they're building to run applications on. They redesigned JavaScript from the ground up with V8. Where I think they are falling short is in still talking about security as it relates to the host operating system. We're going to run as a low privilege. We're going to have a blacklist of sites that we know have malware and phishing and we're going to alert. Ok, that's nice. But 2004 called and it wants its security features back. But I think it's a good step. I think what they're really failing to address is Web application security vulnerabilities. Where's my built-in cross-site scripting filter? Where's my built-in password vault? Or maybe something that will generate one-time passwords. What about something that does blacklisting of sending requests to certain URLs? So not just, don't send requests to this site, something more akin to adblock or some of these privacy things with IE 8. They do have, I think they're calling it, Incognito mode. Everyone is calling it porn mode. Well, it does have a little picture of a guy in a trench coat.
It does. They're not trying to dispel what that thing is used for by 99% of the browsing population. They're starting to have an application security focus, because they're thinking about how this application endangers privacy or personal information. But I want to see them do more, and they're not there yet. In terms of a platform, I think it kicks the crap out of anything else out there. Because, for example, it has Google Gears built into it. So this whole idea of it's a Web app but you can use it on a plane. From a platform point of view, I think they're really doing it right. From a security point of view, I think they're doing stuff that the major browsers were doing either natively or through plug-ins four years ago. Tell me a little about the Black Hat talk you gave and the ways you found to evade malware analysis with JavaScript.

Listen to the Hoffman interview: Billy Hoffman of HP is among the top AJAX and JavaScript security experts in the industry. In this podcast he talks about the issues with Google Chrome, why JavaScript is so dangerous and why he dragged a vending machine up several flights of stairs to prove a point in college. Download MP3 | Subscribe to Security Wire Weekly

I was focusing on techniques that JavaScript malware can use to circumvent automated analysis. That's like a very esoteric topic that would be someone's Ph.D. thesis that never got read by anyone. Actually, it's incredibly relevant to both end users and browser manufacturers. One of the things attackers are doing now instead of just throwing down malware or throwing down malicious ActiveX or whatever, is they're first obfuscating them with JavaScript to get them past your firewalls. They don't understand what's going past them. Not only is JavaScript being used to hide traditional nastiness, over the last two or three years we've seen JavaScript itself can do very nasty things. It can actually work as a keylogger that would work regardless of whether you're on a Macintosh, PC, iPhone or Linux box. We've seen it used to find out what websites you've visited and what keywords you're searching for. It can port-scan internal networks. This isn't spawning ActiveX controls. This is just native JavaScript running in your browser that can do very nasty things. What a lot of security vendors are starting to do is run this JavaScript in a sandbox to figure out what it does. The problem is the sandbox they're running it in is different and behaves different than a normal browser. So what my research was about is whether it is possible for this nasty JavaScript, when it's being executed, to examine its environment and say, "Hmm, am I in a sandbox or am I actually inside a real browser?" Because if it's inside a sandbox, it can just stop, so it looks benign. If this sounds familiar, it's similar to the whole Red Pill-Blue Pill thing we had at Black Hat a few years back. The answer is yes, there are ways you can tell you're in VMware. The concept is the same. There are ways you can tell whether you're in a sandbox or a real browser. So I talked about the numerous different ways that malware can detect this. With all of this nasty stuff that JavaScript can do, why do people still use it? It's almost impossible to browse the Web without it. If you go into Firefox and disable it, websites essentially don't work.
I have to think somewhere, Tim Berners-Lee, who created HTML, must be really, really angry with a lot of people. He must want to take the people who created Dojo or worked on jQuery and just punch them in the face and be like, "It's a document layout language! What are you doing?" But, the hacker in me loves it. Because it's the perfect example of taking something that was built for a specific job, and you start augmenting it and hacking it and you find out you can do all sorts of crazy, cool things with something that was just supposed to be about laying out a document. So flat HTML and JavaScript have been the lowest common denominator. You basically cannot browse the Web today without JavaScript because we don't really have the Web of old. You have Google Documents and Gmail. You're at one URL and everything beyond that is JavaScript. You can't put the genie back in the bottle and say, let's redesign this.