Python cross-site scripting exploits?

[Paul Boddie]

"Erlend J. Leiknes" <nookieNO_SP_AM at online.no> wrote in message news:<mD5H8.4099$fG3.139824 at news2.ulv.nextra.no>...
> The python cgi lib doesnt offer any security at all.
> The url entered by the client is the one that will end up in your cgi
> script, and you will have to perform your own security checks on it, which I
> think is a good thing (Who want your programming language to halt your work
> in a windoze way?)

I don't really see what Windows has to do with security checks in
either a programming language or its libraries. You might have a point
if you were to refer to Java's security model, however.

> from www.python.org online docs
> (http://www.python.org/doc/current/lib/cgi-security.html)
> 11.2.6 Caring about security
> There's one important rule: if you invoke an external program (via the
> os.system() or os.popen() functions. or others with similar functionality),
> make very sure you don't pass arbitrary strings received from the client to
> the shell.

[...]

The problem with this advice with respect to cross-site scripting
exploits is that the advice is only partially relevant in the light of
such exploits. Yes, one should always treat untrusted input very
carefully and to try and avoid recycling that input, but the
well-known, longstanding precaution of not just passing anything
you've received to the shell doesn't in any way suggest that emitting
input data in generated HTML pages could be dangerous.

It is common knowledge that if you're writing a HTML message board
program, it may be advisible to disallow the posting of arbitrary
HTML, but this is only strikingly obvious because of the nature of the
interactions between the user and the software - they are actually
being allowed to post content onto your site. Still, such restrictions
have typically been enforced to prevent "mischief", whereas the
exploits under discussion are more serious than that.

So, even if someone were to religiously follow the above advice, and I
suppose that most developers have been doing so since around 1995,
when most people stopped even considering writing the smallest of CGI
scripts in various shell languages anyway, they could still be
surprised by the exploits being discussed here. Of course, there are
other kinds of shell-like exploits such as the ineffectual use of
SQL-quoting on untrusted data in an application, but I would argue
that the exploits being discussed here are conceptually almost
different.

I suppose the best advice is: don't allow user data to enter your
"command/instruction model" - keep data and instructions separate at
all times.

Paul