I'm finally getting around to finishing my post on minimizing attack surfaces. Here's Part 1 <http://www.veracode.com/blog/?p=111> , in case you missed it.
First, a quick clarification. I noticed that some of the readers who commented on that first post wanted to talk about improving security through the use of various development methodologies or coding frameworks. Those are interesting tangents (and ones that I may write about in the future), but my intention with this post is to discuss a very specific problem related to how people integrate third-party code -- that is, the stuff you import or link in but didn't write yourself. As I mentioned previously, developers have a tendency to "bolt on" third-party components to applications without understanding the security implications. Often, these components are glossed over or ignored completely during threat modeling discussions. I attempted to illustrate this with my fictitious WhizBang library example in Part 1. When integrating a third-party component, developers familiarize themselves with the API but generally don't care how it's implemented. Granted, that's how an API is supposed to work; you don't have to futz around with code beyond the API boundary, and you can blissfully ignore parts of the library that you don't need. In past consulting gigs, I've sat in threat modeling discussions where nobody knew whether a particular library generated network traffic. "We just use the API," they say. The fact that it works is good enough; nobody seems to care how it works. That mindset is ideal for rapid development but problematic for security. Failing to understand the complete application, as opposed to just the part you wrote, prevents you from accurately assessing its security posture. It's also no coincidence that web app pen testers love third-party components -- we get excited when we see "bolted on" interfaces, because we know that developers tend to leave extraneous functionality exposed. The resulting findings usually generate reactions such as "I didn't even know that servlet had an upload function." An Example Here's a close-to-home example related to my post about DWR 2.0.5 <http://www.veracode.com/blog/?p=115> from the other day. DWR is an Ajax framework that has a variety of operating modes. In-house, we use a subset of DWR's full functionality -- specifically, we interact with it using the "plaincall" method only, so we made sure that the features we didn't need were disabled via the configuration file. As it turned out, there were vulnerable code paths prior to the "do you have this thing disabled" check. In hindsight, if we had taken more time to understand the exposed interfaces, we could have reduced the attack surface by filtering out unneeded request patterns before they even touched the third-party code. But wait, you say. What about maintainability? If I whitelist using a point-in-time application profile, doesn't this create the same maintenance headache as the reviled WAF? It doesn't have to. Certainly, one option would be to whitelist each and every unique URL that references the DWR framework, e.g. /dwr/call/plaincall/myMethod1 /dwr/call/plaincall/myMethod2 /dwr/call/plaincall/myMethod3 But then you'd have to update the whitelist every time you added or removed functionality from your application. Also, don't lose sight of the security goal, which is to minimize the amount of exposed third-party code. If I add or remove URLs that list, provided they are still using the "plaincall" method, I'm hitting the same DWR dispatcher every time. So I've increased maintenance cost without any security benefit. A better option is to simply tighten the URL pattern a bit in the J2EE container. Here's the default configuration: <servlet-mapping> <servlet-name>dwr-invoker</servlet-name> <url-pattern>/dwr/*</url-pattern> </servlet-mapping> Now, instead of allowing every URL starting with /dwr/ to be processed by the DWR library, you could be a little more restrictive: <servlet-mapping> <servlet-name>dwr-invoker</servlet-name> <url-pattern>/dwr/call/plaincall/*</url-pattern> </servlet-mapping> In this configuration, you don't have to worry about /dwr/call/someothercodepath any more. There is less third-party code exposed, thereby reducing the overall attack surface of the application. (NB: DWR also serves up a couple of Javascript files, so those URL patterns will have to be whitelisted too) A Logical Extension Even if you're not a developer, you should still be thinking about attack surfaces. People download and install blogging platforms such as WordPress, Movable Type, etc. all the time, but how many take additional <http://blogsecurity.net/wordpress/wordpress-security-whitepaper/> steps to harden their installations? The concept is the same as the OS hardening analogy I brought up at the very beginning of this discussion. Similarly, people install third-party WordPress plugins <http://milw0rm.com/search.php?dong=wordpress+plugin> or Joomla <http://milw0rm.com/search.php?dong=joomla+component> components without considering that most of them are written by some random programmer who is a whiz with the plugin API but knows nothing about security? At the risk of sounding trite, always remember that security is only <http://www.schneier.com/blog/archives/2005/12/weakest_link_se.html> as strong as the weakest link. [Ph4nt0m] <http://www.ph4nt0m.org/> [Ph4nt0m Security Team] <http://blog.ph4nt0m.org/> [EMAIL PROTECTED] Email: [EMAIL PROTECTED] PingMe: <http://cn.pingme.messenger.yahoo.com/webchat/ajax_webchat.php?yid=hanqin_wu hq&sig=9ae1bbb1ae99009d8859e88e899ab2d1c2a17724> === V3ry G00d, V3ry Str0ng === === Ultim4te H4cking === === XPLOITZ ! === === #_# === #If you brave,there is nothing you cannot achieve.# --~--~---------~--~----~------------~-------~--~----~ 要向邮件组发送邮件，请发到 [email protected] 要退订此邮件，请发邮件至 [EMAIL PROTECTED] -~----------~----~----~----~------~----~------~--~---
<<inline: image001.gif>>
