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]
Message-ID: <200408101438.i7AEcYun024970@turing-police.cc.vt.edu>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ