[WEB SECURITY] Application Security Hacking Videos
pauls at utdallas.edu
Thu Jun 1 11:05:37 EDT 2006
Erez Metula wrote:
> 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
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
> 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
> WITHOUT TELLING IT THE SIZE OF THE BUFFER.
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
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
> 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
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
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...
Size: 5007 bytes
Desc: S/MIME Cryptographic Signature
More information about the websecurity