Mitigating XSS in the mod_perl API

[Matt Sergeant]

At the moment it's possible to do nasty XSS things in mod_perl when you set a cookie. That's because $r->headers_out->add() (or set()) doesn't care if you include carriage returns in your header. Simple example would be:

$r->headers_out->add('Set-Cookie' => 'mycookie=' . $r->param('myparam'));

Just stick a couple of carriage returns in myparam and you can get the result:

Date: Sun, 26 Jan 2003 10:39:41 GMT
Server: Apache/1.3.26 (Unix) AxKit/1.6_01 mod_perl/1.27
Client-Date: Sun, 26 Jan 2003 10:39:42 GMT
Client-Response-Num: 1
Set-Cookie: mycookie=foo

<javascript>
....
</javascript>
Connection: close
Transfer-Encoding: chunked
Content-Type: text/plain; charset=ISO-8859-1

Thus giving you a full blown XSS bug.

Now wouldn't it be simple to just ban \n's in headers_out()? Throw an exception or something? It might be a bit tricky because headers_out is just a plain Apache table, but there's probably a way.

I suppose the opposition is that well, mod_perl is just an API, and we shouldn't be forcing programming styles onto the programmer, but there isn't a single legitimate use of \n in an outgoing header, so I don't think that argument has much weight.

Thoughts?


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]