[Owasp-leaders] I am glad to announce we've just set a new project up - the OWASP Myth Breakers Project, led by Stefano Di Paola & Dinis Cruz.

[Andre Gironda]

On Tue, Mar 1, 2011 at 2:12 PM, Juan Carlos Calderon Rojas
<juan.calderon at softtek.com> wrote:
> I totally agree Dave.
>
> I think there is "natural" trend to do pen test since it is easier to
> report/demonstrate and to automate (HTTP is well defined, Code is not). Show
> a popup and the guy will say "wow what shouldn't  have happen".  But
> try to convince him showing a line of code and he will simply say "I don't
> think that's possible" or "No, the application/technology would not allow
> that". But you cannot match the power of "going to the source"
> of the security issues.

Juan,

Great response to Dave's already awesome work here.

> Notice also that you don't have to do line-by-line code
> review, that would be stupid. Is using code as enabler to speed
> up application understanding, vulnerability detection
> and exploitation where code review really shines. Why spending a lot of
> time trying to figure out the correct filter evation combination if you
> can just go to the app source and craft yourself a nice and mostly
> 100% effective evation patern for your pen test?.

In a book, written by Mark Dowd, Justin Schuh, and John McDonald, it
was said that the authors prefer to read code line-by-line, from top
to bottom, all files, until complete (and then do it again after
sharing results).

However, I think they were talking about Assembly and C. ;>

When I perform a code review [and pen-test], I always ask others
involved how they map URIs and parameters to source code. I ask them
how they do their traversals. Everyone kind of does it a little
differently. The methods described in the literature are called "code
auditing strategies", and are a bit broader in scope than just code
traversal -- but I think many concepts therein also apply to runtime
analysis.

There is a tool that works great for code comprehension code auditing
techniques -- it's called OWASP CodeCrawler. I've also seen some work
done with Notepad++ on the OWASP ASVS Project pages. Many of the best
code reviewers I know use Source Insight. I mostly use SciTE. Yes,
freely available, open-source source code viewers/editors don't have
the fancy output or flashy report generation engines, but I find that
those "features" slow me down. SciTE is extensible via Lua, much like
ModSecurity, Snort, Wireshark, and Nmap.

If a codebase is small enough, you can read the code many times and
find traversals quickly. If it's Java Enterprise, this can get
confusing -- you have to read all of the framework specific app server
components, or at least their configuration files. App routing and URL
rewriting can confuse things a lot. Many apps have a Views folder,
which doesn't necessarily simplify anything but does put some things
in one place. I can think of a few shortcuts, but many are dependent
on the framework and framework components, so it's too much to discuss
here.

That's really all I have to say, other than that I agree with Dave...
always try to do both manual code review and manual pen-test together.
And of course, the manual efforts are tool assisted and can leverage
automated analysis tools.

-Andre