Front page | perl.perl5.porters |
Postings from February 2000
Recently there's been some talk (admittedly, nearly drowned out in the noise from the DDoS attacks) about cross-site scripting problems in the WWW, mostly provoked by CERT CA-2000-02 at www.cert.org. The essense of the problem is that attackers have come up with any number of tricks to fool a user into visiting a URL, or posting form data, or sending cookies, or whatever, that the attacker has composed, and some websites will take this info and blat it back at the user without examining it. Combined with browser scripting languages this can make for problems. It just occured to me, if there were some way to mark stdout and stderr, to notify the perl interpreter that writing tainted data to either of those filehandles could be dangerous, that perl's taint checking could be extended to cover this class of problem. Is there any chance of getting some way to do this? Or is the taint checking too special-purpose and hardwired? If we could get flexible control over the taint checking, to extend it deliberately into other areas, another lovely one (in the same vein) would be at module interfaces; specifically, it'd be awfully nice if data passed in SQL to a relational database could be recognized as "dangerous" by the taint code. There might be a filehandle behind a given DBD driver, but it's probably buried inside the C API to the database that the DBD is built upon. Sure, DBI could be modified to check and see if taint checking is in place, and if so to check all its args for taintedness using something like the is_tainted test in perlsec, but that would be so cumbersome. Wouldn't it be lovely to write safer database-using CGIs with a simple use tainted qw(STDOUT STDERR DBI); or something like that? Combine that with a nice library of untainting functions, which check for valid data of various formats (e.g. numbers, perhaps dates) and "sanitize" arbitrary strings by applying various encodings (e.g. uri encoding, perhaps others) and it'd get a lot simpler to write more secure code in the nasty, hostile environment of the WWW. -Bennett