Great answer, John. I especially like your point about web.xml. This goes dually for black-box testing. There would be a lot of advantage to being able to get (and compare) these types of config files today for dialing in BBB (Better Black Box vs. blind black box) testing. I don't think anyone is doing this optimally now. I know I am eager to find static analysis that can provide/guide my BBB testing with more context. I definitely think we will see more of these combined-services evolve in the future. It only makes sense, especially given some of the context-sensitive framing considerations in your response.
Thanks for the solid thoughts, -- Arian Evans On Wed, Jul 29, 2009 at 5:44 AM, John Steven<jste...@cigital.com> wrote: > All, > > The question of "Is my answer going to be high-enough resolution to support > manual review?" or "...to support a developer fixing the problem?" comes down > to "it depends". And, as we all know, I simply can't resist an "it depends" > kind of subtlety. > > Yes, Jim, if you're doing a pure JavaSE application, and you don't care about > non-standards compilers (jikes, gcj, etc.), then the source and the binary > are largely equivalent (at least in terms of resolution).... Larry mentioned > gcj. Ease of parsing, however, is a different story (for instance, actual > dependencies are way easier to pull out of a binary than the source code, > whereas stack-local variable names are easiest in source). > > Where you care about "a whole web application" rather than a pure-Java > module, you have to concern yourself with JSP and all the other MVC > technologies. Placing aside the topic of XML-based configuration files, > you'll want to know what (container) your JSPs were compiled to target. In > this case, source code is different than binary. Similar factors sneak > themselves in across the Java platform. > > Then you've got the world of Aspect Oriented programming. Spring and a > broader class of packages that use AspectJ to weave code into your > application will dramatically change the face of your binary. To get the same > resolution out of your source code, you must in essence 'apply' those point > cuts yourself... Getting binary-quality resolution from source code > therefore means predicting what transforms will occur at what point-cut > locations. I doubt highly any source-based approach will get this thoroughly > correct. > > Finally, from the perspective of dynamic analysis, one must consider the > post-compiler transforms that occur. Java involves both JIT and Hotspot > (using two hotspot compilers: client and server, each of which conducting > different transforms), which neither binary nor source-code-based static > analysis are likely to correctly predict or account for. The binary image > that runs is simply not that which is fed to classloader.defineClass[] as a > bytestream. > > ...and (actually) finally, one of my favorite code-review techniques is to > ask for both a .war/ear/jar file AND the source code. This almost invariable > get's a double-take, but it's worth the trouble. How many times do you think > a web.xml match between the two? What exposure might you report if they were > identical? ... What might you test for If they're dramatically different? > > Ah... Good times, > ---- > John Steven > Senior Director; Advanced Technology Consulting > Direct: (703) 404-5726 Cell: (703) 727-4034 > Key fingerprint = 4772 F7F3 1019 4668 62AD 94B0 AE7F EEF4 62D5 F908 > > Blog: http://www.cigital.com/justiceleague > Papers: http://www.cigital.com/papers/jsteven > > http://www.cigital.com > Software Confidence. Achieved. > > > On 7/28/09 4:36 PM, "ljknews" <ljkn...@mac.com> wrote: > > At 8:39 AM -1000 7/28/09, Jim Manico wrote: > >> A quick note, in the Java world (obfuscation aside), the source and >> "binary" is really the same thing. The fact that Fortify analizes >> source and Veracode analizes class files is a fairly minor detail. > > It seems to me that would only be true for those using a > Java bytecode engine, not those using a Java compiler that > creates machine code. > > _______________________________________________ > 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. > _______________________________________________ > _______________________________________________ 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. _______________________________________________
