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] [thread-next>] [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 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
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....

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.

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? ;)

-------------- 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/6fac12a6/attachment.bin