Re: Finally - [Logical vs. Technical] was Curphey award 2004 to SPI Dynamics

[Jeremiah Grossman <jeremiah () whitehatsec com>]

The points you touch on are very important understand. The realization 
that there are complex vulnerabilities in a system sheds light on the 
current limitations of scanning in the industry. Perhaps also the 
limits of the software security process as well. As you said, if a 
human/developer has a difficult time identifying business-logic issues 
in their code (cause its complex), how can an automated tool  be 
expected to find it? Also note, even two completely secure blocks of 
code and can be combined creating and insecure scenario.

I've given presentations about this where I categorize webappsec 
vulnerabilities into two groups, Technical and Logical. Technical 
issues (example: SQL Injection, XSS) are often easy to identify by 
automated means. You send something in (example: ';), you get some back 
you can recognize (an ODBC error message). Simple right. Ok, over 
simplified, but you get what I mean.

On the other-hand, when dealing with Logical vulnerabilities, the 
results will require knowledge of context. Scanners are capable of 
manipulating params all day long, but how does the tool know if the 
data is gets back it was supposed to see or not. Did the page contain 
my bank account data or someone else's?  Determining what was supposed 
and not-supposed to happen in a generic fashion is amazingly difficult. 
Humans can perform this task very well. Score 1 for the human brain! 
But at this point, tools that hit or miss is the best we can hope for.

This is where many have said... "scanner suck because they don't find 
everything". Though I think its simply better to say technology is not 
a complete solution. The reality of the situation is that Logical 
problems are not something the industry has had to deal with before. 
We're all new at this. This is especially true for network 
vulnerability scanning and the scale we are facing is massive.

In my opinion, technologies such as vulnerability scanning and secure 
code libraries will help out with the Technical issues, but without new 
solutions, we'll be dealing with the Logical issues for years to come. 
Manipulate a hidden form field and you bought the laptop for a dollar.  
There are simply too many web sites and too few humans to review it 
all. And did I mention web sites have a habit of changing? :)

Regards,

Jeremiah-



On Tuesday, June 29, 2004, at 07:59  AM, <PPowenski () oag com> wrote:

> In addition to the points below.....
>
> Even though Security awareness should be provided to developers to
> understand the implication of creating code it should not be as heavy
> burden as it is turning into. The aesoteric aspects that some of the
> attacks take and the combination of events to gain access is an 
> entirely
> different stream of thought that Developers ususally do not focus on. 
> At
> least the ones I have come across.
>
> the core problem related to security with all the api's, tools,
> scripting engines, and compilers can be attributed to those who created
> them for developers to create code.
> If a developer has to engage in working out for himself the complex
> issues of using the api and where it touches the system, its access
> control mechanisms, and paths to network then the burden detracts
> significantly from getting the job done. Understanding these aspects is
> a large undertaking in itself. Most manufacturers do not want many 
> folks
> to know these details as well.
>
> If the founders of our set of developer tools had enough insight to
> consider this it would probably be much better for all of us.
>
> just my2c
> paul