…and says “Make me one with everything.” Aside from that fact that most hot dog vendors don’t carry Tofu Pups, we’re taking this joke seriously for the next iteration of BlueHat, and giving you some attack content as well as talking about proactive defense.
Coming this October, the BlueHat team will partner with the SDL team to create two full days of content, the first day focusing on new attacks and the emerging threat horizon, and the second day focusing on steps we can take as software architects, developers, testers, and maintainers to make code more secure in the first place.
Stay tuned for guest blog posts here and on the SDL blog from both sets of speakers, with topics ranging from attack to defense. It’s about changing the balance between attackers and defenders; it’s about showing both sides of the same coin; and it’s about time.
Katie Moussouris, Security Strategist II
Bryan Sullivan, Security Program Manager
Hello everyone, this is Robert "RSnake" Hansen. It’s been a while since I’ve talked with the BlueHat folks but only because I’ve been busy behind the scenes working on some cool stuff with the Microsofties. I was pleasantly surprised to hear I am now allowed to talk about one of the things I have helped work on. David Ross mentioned it in a blog post he wrote some time ago, but it has come a long way from that point. He called it “XSS-Focused Attack Surface Reduction goodness” for lack of a better term, but now I think we’ve happily settled on a shorter and more memorable name - “XSSFilter.”
In Internet Explorer 8.0, users will be protected from the vast majority of real world XSS attacks. David spent a lot of time analyzing the most common variants and has built a tool to isolate and protect against those attacks for the vast majority of Internet users out there. The tool protects against reflected XSS in particular, and not against the lesser common DOM or persistent XSS varieties. XSSFilter is certainly not a panacea and it’s still recommended that developers follow good programming practices, but this comes as welcome news to me personally and the vast majority of Internet users who will be protected from an attack they probably couldn’t even spell. And best of all, it will be by default – asking consumers to install security plug-ins has never worked well. Taking it out of the consumer’s hands is a huge leap forward.
I’ve been talking about browser security for quite a while in my speeches and on my site – we can’t expect programmers to fix all their flaws, especially in legacy applications. The browser is one of the few important choke points on the Internet, where client side issues can be heavily mitigated and we can begin to get ahead of the problem. Indeed, XSS is a prime example of what can happen when attackers start using the browser as a conduit for attacks against web applications and consumers. Since we know it’ll be a long time (or maybe even never) until we see every critical web application protecting itself, this is a great short term stop-gap for the vast majority of XSS issues against the Internet Explorer browser.
Only time will tell how attackers move and adjust to these changes, but in the near term, I’m happy to have played a small part in adding one more weapon in the fight to protect consumers.