[WEB SECURITY] Application Security Hacking Videos

Paul Schmehl pauls at utdallas.edu
Thu Jun 1 11:05:37 EDT 2006

Erez Metula wrote:
> 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?

I'm not suggesting that there is a magic potion that will solve all 
problems.  However, if you noticed, my pseudo-code required three 
arguments to the "wash" routine - data, data type and data size.  (It 
could certainly allow other, optional arguments as well.)  Data type 
could be things like "SSN" or "BD" (birthdate) or "PASS" (or Types 1, 2, 
3, etc.), and the resultant function would only allow those types of 
data to pass after being sanitized.  Data size would allow the 
programmer to define the max_buf_size as an argument to the "wash" 
function, and the wash function would simply reject any data size larger 
than that.

No, it's not perfect, and no it won't solve every problem.  But it would 
go a long way toward solving the simpler and more common attacks.

> 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").

Easily solved.  If data type is password, then optional arguments could 
be supplied (min_size, required char types, etc.) and the function could 
return "Invalid input.  Please re-enter".  Furthermore, by object-tizing 
the data filtering, you would get consistent error messaging.

> 2)  Stopping sql injection by just not allowing ' or stuff like that
> (remember, you have names that has ' in them, ex: O'brian).

Yes, but what you don't have is a name with ' or 1=1, so your filter 
only allows, for names, Alpha characters and dashes, periods and single 
quotes.  No numbers, no equal signs, etc.

> 3)  Stopping XSS by just removing <,>, etc. the application sometimes
> need those chars from the user.

And the programmer could define those.  Or not use the "wash" function 
for that part of the code.

> 4)  Stopping from forceful browsing, example: someone skips application
> workflow/business processes by just calling a specific url.

How is that an input validation problem?  (I'm asking, because I don't 

> 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.

Sure, but a "wash" function doesn't deal with that problem.  It merely 
verifies that the data is correct in size and content for its type. 
Other things have to be done to deal with this problem.

> 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.

Again, not a data input validation problem.

> 7)  Stopping from buffer overflow - only the application knows the size
> of the buffer, therefore it can not be stopped at some filtering module
Which is precisely what the data-size argument does.  When a programmer 
creates an array, he or she knows exactly what its purpose is and what 
its normal size should be.  By providing that information to the wash 
function, the programmer doesn't have to worry about unanticipated ways 
to get data into that buffer.  If the array is 256 bytes, the wash 
function looks at the size and says, "Invalid input", because the data 
size was 298.  Bingo, not buffer overflow!

> 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.

Well, again, I never said it was easy.  I said this was a possible 
solution to many of the problems with data input validation.  There is 
not one size fits all solution, but there are many common problems that 
could be solved by a library-type set of functions that do data input 

> 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.

So colleges and universities are to blame *as well*.  That doesn't 
excuse the programmers.  It merely explains why they lack the knowledge 
when they first go to work because they never took an interest in 
learning it on their own.

> 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.
Sure, management is *also* to blame, but that *still* doesn't excuse the 
programmers.  I took two semesters of C++.  I can assure you, I was 
taught what a buffer overflow is and why it's bad.  No, I didn't get 
security training, but college students are also supposed to be able to 
think and learn for themselves.  They're not like containers that 
knowledge gets dumped into, and if the knowledge isn't dumped, it 
doesn't exist.

Yes, we need much better training.  Yes, we need much better awareness 
of the complexities of attack vectors.  But until programmers and 
leadership in software companies take the bull by the horns and start 
addressing the problem, we will continue to see point solutions that 
hide the ugly warts.

BTW, there are security companies that I will not even consider 
purchasing prodcuts from simply because they have had remote exploit 
vulnerabilities in their code.  I can assure you I'm not alone.  As more 
of us practitioners begin to cull the poorly programmed applications 
from our purchase mix, we will weed out the bad programmers ourselves.

That's something that all software companies might think long and hard 

Paul Schmehl (pauls at utdallas.edu)
Adjunct Information Security Officer
The University of Texas at Dallas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5007 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.webappsec.org/pipermail/websecurity_lists.webappsec.org/attachments/20060601/143aecf5/attachment.p7s>

More information about the websecurity mailing list