Without instrumentation this will be major, costly, epic fail. Assuming life without it for the time being, I think the future is brighter for dynamic-to-static integration. Let's consider a few of the logistical issues going the opposite way - from static findings to exploit generation after a simple source-to-sink, tool-identified path for a SQL injection vulnerability found deep in the business logic of an application: 1. The application has no idea what it's method/scheme/hostname/port for invoking it should be. It seems like a simple thing to deduce, but I guarantee it's a huge PITA for anyone actually doing the work to make it 100% reliable. After all, if it's not 100% reliable, how can we claim that this technology helps us any more than the static trace alone? The value-add here is in ease of verification. A mistake made in figuring out any of these values will mean that the exploit will not be verified and will turn out to be a false negative. All the infrastructure touched before the app makes this a complex problem - and if this little tiny bit of obvious information is complex to generate, what hope is there of getting the rest of the complex set of circumstances right that are required to re-create a vulnerability in action? Realistically the VA and the SA (VA+SA, it's everywhere you want to be) need to maintain synchronization per request to make this a semi-sane idea. You could hardcode these values, but what if you use a mix of values and therefore aren't static across the application? Knowing the tools, I know the finding will still be reported somewhere deep in a "don't bother checking these" category. =) 2. The SQL injection vulnerability would have to understand the query and how to manipulate it in order to generate a meaningful query and resulting exploit. If proof that you can cause a syntax error is enough to verify exploitability then I guess this isn't such a big deal. But what if the syntax error never reaches the screen? Have you verified anything in this case? 3. The application would have no idea what server-side forwards, virtualized paths and filters were traversed to reach the application's action entry point. This reverse-engineering is especially hairy in J2EE, yet would be needed to be reliably generated in order to form an exploit. Put Spring on top of it and we're talking complexity that's practically impossible to re-model. This is just the tip of the iceburg, I think. The only technically feasible application of this kind of integration can be found in instrumentation ideas like Fortify's "attack path tracing", which would ideally be tied into unit testing and regression testing when it makes sense. Are there any competitors to them in this market? Does anybody have real-life experiences with this tool set? The idea of VA+Fortify+ptrace is intriguing, but we're looking at an explosion of complexity that I doubt many customers have the expertise to manage. +1 to Fortify for innovation, but can we get some technical information or user experiences here? Arshan P.S. Has anybody talked about cost/value analysis? It'd be cool tech, for sure, but is it worth it? I'm not trying to dissuade anybody from pursuing these ideas, but I just want to make sure all the cards are on the table.
________________________________ From: Jeremiah Grossman [mailto:jerem...@whitehatsec.com] Sent: Thu 8/6/2009 8:22 PM To: James Landis Cc: sc-l@securecoding.org; websecur...@webappsec.org Subject: Re: [WEB SECURITY] Re: [SC-L] Integrated Dynamic and Static Scanning Good catch, that is exactly right. My oversight. A while back Fortify released a white paper entitled "Misplaced Confidence in Application Penetration Testing" [reg required] http://www.fortify.com/security-resources/library/overviews.jsp Tools also available to help measure. On Aug 6, 2009, at 5:04 PM, James Landis wrote: > There's a big claim in area 2) that actually does exist: > instrumentation of static code to give you code coverage metrics for > your dynamic scanning efforts. Well, maybe it's not area 2), but > it's definitely a static analyzer vendor feeding dynamic analysis. > > -j > > On Thu, Aug 6, 2009 at 4:30 PM, Jeremiah Grossman <jerem...@whitehatsec.com > > wrote: > Hey all, > > I've been monitoring this thread [1] and some excellent points have > been raised (cross-posting to websecurity as the subject matter > applies). I'm personally very interested in the potential benefits > of an integration between dynamic and static analysis scanning > technology. The spork of software security testing. The desire of > many is a single solution that unifies the benefits of both > methodologies and simultaneously reduces their respective well- > described limitations. For at least the last couple of years there > have been vendors claiming success in this area, of which I remain > skeptical. > > A brief explanation of the bi-directional and somewhat simple > sounding innovations that vendors are trying to develop: > > 1) Dynamic Scanner -> Static Analyzer > A dynamic analysis engine capable of providing HTTP vulnerability > details (URL, cookie, form etc.) to a static analysis tool. Static > analysis results narrowed down to a single line of insecure code or > subroutine to speed vulnerability remediation. Prioritize issues > that are located in a publicly available code flow vs. those that > are not technically remotely-exploitable. Isolate security issues > where source code was not available, such as third-party libraries. > > Static Analyzer -> Dynamic Scanner > 2) A static analyzer capable of providing a remotely available > attack surface (URLs, Forms, etc.) to a dynamic analysis tool. > Dynamic analysis may realize additional testing comprehensiveness, > measurement of coverage depth, and hints for creating exploit proof- > of-concepts. Not to mention able to provide more detailed > application fix recommendations. > > <vendor bias> > As it stands currently, the state-of-the-art is basically a > reporting mash-up. Very little of the aforementioned advancements > have been proven to funtion outside of the lab environment. If > anyone has evidence to the contrary they can point to, please speak > up. For those curious as to Tom Brennan's comment, these are the > areas Fortify and WhiteHat are together working on. > </vendor bias> > > This is an excellent time to be in the application and software > security industry. Over the next few years there is going to be a > lot of innovation and awareness in the "defense" side of the > industry. Talent, skill, and experience is going to command a premium. > > > [1] http://www.mail-archive.com/sc-l@securecoding.org/msg02731.html > > > Regards, > > Jeremiah Grossman > Chief Technology Officer > WhiteHat Security, Inc. > http://www.whitehatsec.com/ > blog: http://jeremiahgrossman.blogspot.com/ > twitter: @jeremiahg > > ---------------------------------------------------------------------------- > Join us on IRC: irc.freenode.net #webappsec > > Have a question? Search The Web Security Mailing List > Archives:http://www.webappsec.org/lists/websecurity/archive/ > > Subscribe via RSS:http://www.webappsec.org/rss/websecurity.rss [RSS > Feed] > > Join WASC on LinkedIn > http://www.linkedin.com/e/gis/83336/4B20E4374DBA > > ---------------------------------------------------------------------------- Join us on IRC: irc.freenode.net #webappsec Have a question? Search The Web Security Mailing List Archives: http://www.webappsec.org/lists/websecurity/archive/ Subscribe via RSS: http://www.webappsec.org/rss/websecurity.rss [RSS Feed] Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA
_______________________________________________ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. _______________________________________________
