Hi everyone, Bryan here. My friend Ralph is a huge gadget lover. Whenever a new piece of electronic gadgetry comes out, Ralph has to have it. 1080p 3D HDTV and Blu-ray player? Check. Latest mobile phone? Check. Wireless network music player streaming from a RAID 5 NAS home media server? Check. So of course, when Ralph bought a new car, he had to get the GPS navigation system option. Now, GPS is a very cool and useful feature: You’ll always be able to find the fastest route home, or to the nearest gas station, or in Ralph’s case, to the nearest Best Buy. But consider the cost of that feature, not in terms of dollars and cents but rather in terms of attack surface. What would happen to Ralph, if someone stole that new car? The thief would not only have the car, but he’d have directions to Ralph’s house thanks to the GPS, and when he got there, he’d be able to let himself in with the automatic garage door opener.
There’s an obvious parallel here between cars and software. Consumers love features, consumers love convenience, and these things sell products. It’s our responsibility as security architects and developers to ensure that those features and convenience don’t add unnecessary attack surface. A classic example of this is the Microsoft Web server (Internet Information Services, or IIS for short) that’s included with Windows. In Windows 2000 and earlier, IIS was not only included as part of the operating system but also installed and activated by default. For those users who needed Web server functionality, this worked well and saved them some installation time. But the majority of Windows 2000 users probably never needed a Web server. My mother ran Windows 2000 on her home PC for a while, and I’d be surprised if she even knew what a Web server was! So when a vulnerability in IIS was discovered that allowed remote anonymous users to access private files, this vulnerability ended up affecting millions of users unnecessarily.
While this lesson has been learned (Microsoft still installs IIS with Windows, but you now have to manually enable it through the administrative Console Panel), I still see a lot of unnecessary attack surface present in SaaS applications. It may be easy to set allow-access-from domain=”*” in your crossdomain.xml file, but do you really need the extra attack surface that comes from allowing the entire Internet access to your resources? In products with wiki or blog features, it’s nice to allow users to use markup in their posts, but this one simple feature greatly complicates the difficulty of defending against cross-site scripting attacks. Or let’s say you’re developing a multitenant application: Simply adding a new “ClientID” column to your database tables instead of segregating your clients’ data into separate databases may lower hardware costs, but now you’re just one SQL injection vulnerability away from leaking all of their data.
I’ll be in San Francisco for RSA Conference next week to present “Stop Exposing Yourself: Principles of Attack Surface Analysis and Reduction” (session# AND-108, Tuesday 2/15 at 3:40 PM) along with Michael Howard from the Microsoft SDL team. We’ll be discussing these scenarios and many others, and Michael will be demonstrating their new Attack Surface Analyzer tool. If you’re attending the show, I hope to see you there!