full-disclosure - [anti-XSS]about CERT/CC:malicious_code

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks@...edu)
Subject: [anti-XSS]about CERT/CC:malicious_code_mitigation 

On Mon, 09 Aug 2004 21:59:10 PDT, dd said:

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

If your programmers can't even tell what *characters* are valid for a field...

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

... it would explain why 90% don't come close.

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

Well.. if you're REALLY ambitious.. :)  Yes, those would be good too,
once you get past the *really* basic stuff...

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

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

Note the caret ^ at the front - that means NOT matching...

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

Many schools of thought on that one..  Fixing is almost certainly a bad idea,
giving back a not-quite-generic error page is probably a good one - "Bad Input"
is a lot less helpful than "Hint: Phone numbers should look like +1 (nnn) nnn-nnnn"
or similar.

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

You'll probably find 3 classes of programmers:

1) The already-clued, who don't get dinged for much during the assessment.

2) The unclued but clever, who will get whalloped on the first assessment, but learn.

3) The great unwashed "Learn Foo in 21 Days" who don't learn the first time - they
almost certainly won't learn on the second one either.

Suggestion: Try to make sure the newcomer gets hit with at least 2 assessments
while they're still on "probationary" status, if you can... ;)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 226 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20040810/96abff28/attachment.bin