Message-ID: <4118561E.2080507@ghettohackers.net>
From: dd at ghettohackers.net (dd)
Subject: [anti-XSS]about CERT/CC:malicious_code_mitigation

Valdis.Kletnieks@...edu wrote:

> On Mon, 09 Aug 2004 19:45:07 PDT, dd said:
> 
> 
>>Real solution is to have "per input" input validation which will always 
>>let some "potentially bad" things through, but help mitigate exposures 
>>and then do things "right". 
> 
> 
> Actually, you should be doing "per input" validation on each field, which tries
> to totally eliminate the "potentially bad" for each field, as appropriate for
> the field in question - my example of alphanumeric, space, hyphen, and

<nitpick>
I have always approched input validation more from a buisness side of 
things then attempting to filter out bad characters.  Mitigation of some 
attacks is a nice side affect of proper input validation.  Making 
developers sweat over what characters to include tends to confuse 
things, and scare buisness people into limiting things to a point that 
impacts usability of an application.
</nitpick>

> underscore may not be suitable for all fields (as one clued person pointed out
> to me in private mail).  A real program will almost certainly end up with a
> separate filter for each field type....

I have yet to meet many real programs I guess :)  I would say 90% of the 
applications I see never come close to performing robust input 
validation, web or otherwise.  Most of the small number of applications 
I do see performing input validation tend to be ASP.NET applications.  A 
trend I put to the addition of field validators with stock validators 
for common input types.  Hopefully it will continue to get easier for 
developers to implement reasonable (read: low dev and perf hit) input 
validation which has always been a sore point in all application 
development.

It might also be worth saying, for those reading along, that input 
validation should also look for  things like format, size, possibly min, 
max, and other things.

> 
> The *important* part is that you're *not* using 's/[list-of-known-bad]//g',
> but that you use 's/[^list-of-known-good]//g'.  Making the known-good list
> for each field is the programmer's problem.

Ah, the black list.  Oh the black lists I have seen, crushed, and walked 
passed.  The many pages of regex to locate sql injection that have 
caused major performance impacts.  The injection of NULL's, spaces, and 
odd encodings that cause failures, heart attacks, and buffer overflows. 
  Oh the black list.

PS- I assume it wasn't really your intent to remove the good chars... <grin>

Of course that raises the question, what todo with bad input?  I would 
suggest in much humbleness that a generic error page be displayed and 
proper error logging occur.  Never attempt to fix such input.

> 
> How many CGI scripts have had directory traversal issues that would have been
> completely and totally prevented if they had done the filtering right and dropped
> the '/' character (and probably '.' too) out? ;)
>

*yawn* silly cgi programmers... Who was just saying we should require 
developers get a license to code?  Some days, as I'm finding hundreds of 
buffer overflows, encryption that's a bad night out with xor, and home 
rolled auth, it seems like a good idea...  Imagin sending a bad 
developer to a safe database course for to many sql injectio infractions :)

I'll have to figure out the number of developers who learn from the 
mistakes found durning an application assessment vs. those who do not. 
I think its not that bad actually.

dd

Powered by blists - more mailing lists