IBM Acquires Ounce Labs, Inc.

[arian.evans at anachronic.com (Arian J. Evans)]

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<jsteven at 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" <ljknews at 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 at 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.
> _______________________________________________