[WEB SECURITY] Application Security Hacking Videos

Joel R. Helgeson joel at helgeson.com
Thu Jun 1 23:18:25 EDT 2006


As a side note/follow up to this thread:
The 20 year estimate came from the customer, was to fix their estimated 
1,500 web applications running on just over 800 servers.  Their estimates, 
their numbers, not mine...

They purchased site licenses for the webApp.Secure App Firewall.

I think that with that sale, webScurity became the #1 Application firewall 
by number of sold installs...  I don't know, but I know that they're 
profitable where everyone else is being propped up by VC funding and are 
being bought/sold left & right.

Joel
----- Original Message ----- 
From: "Paul Schmehl" <pauls at utdallas.edu>
Cc: <websecurity at webappsec.org>
Sent: Wednesday, May 31, 2006 9:51 AM
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