Re: RES: Fail Open Authentication and Parameter Injection

[Mark Curphey <mark () curphey com>]

For a long time I have been trying to find people who are experts in
secure code review to start a secure code review methodology or at least
add a section in the OWASP testing methodology. There are a few papers
out there but I haven't seen an open methodology that people could
provide metrics against or use as a yardstick to judge services. I am
not even sure how practical it is to be honest.

On Tue, 2003-03-25 at 12:23, Mads Rasmussen wrote:
> > -----Mensagem original-----
> > De: Jeff Williams @ Aspect [mailto:jeff.williams () aspectsecurity com]
> > Enviada em: terça-feira, 25 de março de 2003 17:06
> > Para: Mads Rasmussen; webappsec () securityfocus com
> > Assunto: Re: Fail Open Authentication and Parameter Injection
> >
> > Absolutely.  The key is coming up with a standard for the review.
> Saying
> > you're doing a code review is meaningless unless you define what kinds
> of
> > problems you're looking for.  Also, there are lots of ways to "review"
> the
> > code.  Going "line-by-line" is really not optimal from a security
> > perspective in my opinion.  You use different techniques for each type
> of
> > vulnerability.
>
> It would be nice if OWASP could include some general guidelines on this,
> I could imagine something like listing some priorities and maybe some
> examples of how to identify bad code
>  
> > To me, the hardest problems to find are integrity issues and trojans.
> > Integrity is difficult because unless you understand the business
> rules,
> > you'll never know what should be allowed and what shouldn't.  Trojans
> are
> > supremely difficult, because a strong attacker will obfuscate the
> attack.
> > If you don't absolutely trust the developers who wrote your code and
> you
> > haven't reviewed it, you're taking an insane risk.
>
> You hit the soft spot, I don't have a clue as how to avoid this. If you
> must spend time to understand the business rule the code review becomes
> very time consuming and thus expensive for the client.
>
> In this outsourced world trojans seems to be an increasing risk, might
> be somewhat avoided be testing communication of app with a sniffer, but
> it won't capture all, Trojan might be time invoked
>
> Mads
-- 
Mark Curphey <mark () curphey com>