Thanks for your concern. This is what I now have, which merely expands
each value into its usable type (unquotes them):
# filter each value
try:
var=int(var)
Should be safe, although I suppose if an attacker passed (say) five
hundred thousand "9" digits, it might take int() a while to generate the
long int. Instant DOS attack.
A blunt object fix for that is to limit the user input to (say) 500
characters, which should be long enough for any legitimate input string.
But that will depend on your application.
except ValueError:
if var in ('False', 'True'):
var=eval(var) # extract booleans
Well, that's safe, but slow, and it might encourage some future
maintainer to use eval in less safe ways. I'd prefer:
try:
{'True': True, 'False': False}[var]
except KeyError:
pass # try something else
(To be a little more user-friendly, use var.strip().title() instead of
just var.)
else:
var=cgi.escape(var)
This is really no filtering at all, since all CGI variables are written
to a dictionary without checking. However, if there is no receiver for
the value I should be safe, right?
What do you mean "no receiver"?
If you mean that you don't pass the values to eval, exec, use them in SQL
queries, call external shell scripts, etc., then that seems safe to me.
But I'm hardly an expert on security, so don't take my word on it. And it
depends on what you end up doing in the CGI script.
I am also trapping some input at mod_wsgi, like php query strings. And
that IP address gets quarantined. If you can suggest what attack words
to block I'll thank you for it.
That's the wrong approach. Don't block words in a blacklist. Block
everything that doesn't appear in a whitelist. Otherwise you're
vulnerable to a blackhat coming up with an attack word that you never
thought of. There's one of you and twenty million of them. Guess who has
the advantage?