Mitigating XSS in the mod_perl API
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
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]
Re: Mitigating XSS in the mod_perl API
Matt Sergeant wrote:
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
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?
If that causes a bug, may be this should be fixed in Apache?
__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Mitigating XSS in the mod_perl API
On Sunday, Jan 26, 2003, at 22:28 Europe/London, Stas Bekman wrote: If that causes a bug, may be this should be fixed in Apache? That sounds plausible. Perhaps you could bring this up on new-httpd@ for me since I'm not subscribed ;-) I guess the argument you could use is that if you write out a header with a few line feeds in it, you actually end up writing the body, which isn't what the API is for. Matt. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Mitigating XSS in the mod_perl API
Matt Sergeant wrote: On Sunday, Jan 26, 2003, at 22:28 Europe/London, Stas Bekman wrote: If that causes a bug, may be this should be fixed in Apache? That sounds plausible. Perhaps you could bring this up on new-httpd@ for me since I'm not subscribed ;-) You know that bringing up things on httpd-dev (it's not new-httpd anymore) doesn't really work, as the httpd developers are busy scratching their personal itches or having responsibilities. So, thanks, but not me. I guess the argument you could use is that if you write out a header with a few line feeds in it, you actually end up writing the body, which isn't what the API is for. That's true. So now you have a good reason to subscribe to httpd-dev and have this omission fixed ;) __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
