[WEB SECURITY] Application Security Hacking Videos

Erez Metula erezmetula at 2bsecure.co.il
Thu Jun 1 08:34:10 EDT 2006


Paul, 
Installing mod_apache or even writing the module that "washes" the input
will not solve most of the application level attacks.
There are logical problems that could not be detected by a general
purpose solution like you suggested, such as doing input validation at
some layer before the application. Of course, some generic problems can
be detected ("technical problems"), but how can this "context-free"
component will be able to understand the meaning of the input?
For example, the following issues could not be avoided by just using a
general layer and not doing it inside the application itself (it has the
content!):
1)  Stopping applications from revealing too much information (ex. "the
password is wrong").
2)  Stopping sql injection by just not allowing ' or stuff like that
(remember, you have names that has ' in them, ex: O'brian).
3)  Stopping XSS by just removing <,>, etc. the application sometimes
need those chars from the user.
4)  Stopping from forceful browsing, example: someone skips application
workflow/business processes by just calling a specific url.
5)  Stopping from parameter tampering a variable (GET,POST,cookies,
etc.), for example someone changes the ACCOUNT_NUMBER variable to an
account that doesn't belong to him.
6)  Stopping from "what the user can't see in the menu means it's not
possible to operate"  - it means that the user doesn't have some
functionality in his menu (or when it's disabled/grayed), but can still
operate it by accessing the direct url of it.
7)  Stopping from buffer overflow - only the application knows the size
of the buffer, therefore it can not be stopped at some filtering module
WITHOUT TELLING IT THE SIZE OF THE BUFFER.

There are a lot of examples, and those are just a few.
It should convince you why it's not that easy to stop those kinds of
attacks with just installing some input validation
modules/mod_apache/WAF/etc.
It's a matter of secure programming practices. 
Although it seems like the programmers are to blame, but it's not their
fault. It all begins with education, and because the proper secure
development practices are not delivered appropriately to the junior
programmers in Universities and collages, they don't have the proper
knowledge to counter application security threats. And of course it's
also a management issue that should allocate resources & time for
security and give their developers some kind of security training. If
security will not be considered from the first stages of the application
development process, we'll end up with some issues that can't be
actually solved. And believe me, I saw beautiful projects that end up in
the garbage can because of security issues that could not be counter
measured.

Cheers,
Erez.

________________________________


Erez Metula, CISSP    
Application Security Department Manager
Security Software Engineer
E-Mail: erezmetula at 2bsecure.co.il Mobile:972-54-2108830 Office:
972-39007530     
 

-----Original Message-----
From: Paul Schmehl [mailto:pauls at utdallas.edu] 
Sent: Wednesday, May 31, 2006 4:52 PM
Cc: websecurity at webappsec.org
Subject: Re: [WEB SECURITY] Application Security Hacking Videos

Joel R. Helgeson wrote:
> I'd like some feedback from the community here on this...
> 
> I tend to take a very pragmatic approach to security, I evaluate
options, costs, 
and I go for the most cost effective option.  Now, I know that in an 
ideal world, all
software would be written secure and bug free, but we don't live in that

world.
> 
> I have been smitten by the Application Firewall, webScurity's
applicaiton firewall 
webApp.Secure.  Has anyone else out there played with it? Installed it? 
  I'm finding
this thing so cool that I'm trying to figure out if I just found a 
really cool hammer,
and all problems are looking like nails, or what.
> 
> Be honest with me, what do you think of application firewalls?  Have
you used 
them?  I wan't to talk about webScurity's product but I'm concerned that

it will
come off like I'm pushing a product... the thing is that I think this is

the coolest
thing I've seen in a long time.
> 
> The customers where I have installed them have said that to do an
application 
re-write would conservatively take 20 years (that would be to re-write 
all the apps
that they've developed over the past 10 years) and that when considering

options,
the app firewall was a no-brainer.  This has resulted in a rather large 
sale for me, and
I'm seeing a lot of movement in this field, especially with this company

and I'm just
starting to wonder if I'm the only one seeing it or if I've just gotten 
drunk on the kool-aid.
> 
> Yeah, I'm rambling and I know it... but I'm still interested in what
the community has to say.
> 
First of all, we're all professionals here, and I'm pretty sure everyone

knows how to read list traffic, so there's no need to cc everybody on 
God's green earth.

Responding to your request, from a "user" POV, I've been using 
mod_security on Apache for some time, on a webserver sitting "naked" on 
the internet, and it appears to work as advertised.  Having said that, I

chose to use it not to protect a specific application but to protect the

web server in general.  So, obviously I see some value in these
products.

However, I'm not convinced that the appliance based solutions to which 
you refer are worth the cost.  Yes, your demonstration video is 
dramatic, but good lord, the example you use is so fundamentally flawed 
that one has to wonder if it was a setup.

As to it taking 20 years to correct an input-verification 
problem.......I'd say they need to hire some new programmers.  ISTM this

problem is eminently solvable by simply writing a module that accepts 
all user input, washes it, rinses it, repeats and then returns it to the

calling function.  So, even in legacy apps, one new function would need 
to be written (or library, if you will), and then every input function 
would need one additional line - to wash the data before working with
it.

Something like this:

whitewash(data-in, data-type,data-size) {
     do some things here to purify the data
     return data-in-purified
}

So, then, the calling function would do this:

get_some_input(input) {
     input=whitewash(input,input-type,input-size)
     do my thing with the data without worrying about it
     return some value to the web page
}

This type of function/library could clean all sorts of data as well as 
eliminate buffer overflows, without requiring the writer of the input 
function to even know about data sanity or even worry about data size.

Here's what bothers me about application firewalls - they mask a 
fundamental problem - poor programming practices - and they *encourage* 
people not to address that fundamental problem.  If the appliance blocks

it, why do we need to fix it is not an attitude one wants to encourage 
in programming staff.

Yes, it's a quick and easy fix, but it's not a solution and even if you 
think it is, it's not the *right* solution.

Now, as a consultant, I can see the strong attraction that it has for 
you, because you can be a "hero" very quickly.  But have you really 
improved security for the customer?  I don't think so.  Not in the grand

scheme of things.  In fact, one could argue that you've done them a 
disservice by making them *think* they're more secure when in fact, if 
the appliance fails or is taken offline, the fundamental problem still 
remains.  *And* you've encouraged them to repeat the same mistakes again

and again.

At a minimum, when you sell this solution, you should be appending it 
with big red flags that say, THIS DOES NOT FIX THE UNDERLYING PROBLEM 
YOU HAVE.

-- 
Paul Schmehl (pauls at utdallas.edu)
Adjunct Information Security Officer
The University of Texas at Dallas
http://www.utdallas.edu/ir/security/

----------------------------------------------------------------------------
The Web Security Mailing List
http://www.webappsec.org/lists/websecurity/

The Web Security Mailing List Archives
http://www.webappsec.org/lists/websecurity/archive/



More information about the websecurity mailing list