On Tue, 28 Jan 2003, Thomas Eibner wrote: > Yes, that sounds very weak. To me it sounds like Matt doesn't know what > he is doing if he's passing RAW input from a client directly into > something. I know it sounds harsh and I'm not trying to degrade Matt as > I have great respect for the work he is and has been doing for Perl and > mod_perl in general, but from looking at use.perl it does indeed sound > like Matt just figured this out 1)
I had just never realised it was a possible source of XSS bugs - mostly because if I'm creating a cookie (which is the only time user passed data might go in the headers) I'd use libapreq, which escapes the data anyway. So it's not something I would normally do, but I found it intruiging that it was possible. Mostly what it comes down to for me is that AxKit already prevents other XSS bugs (tag injection) by its nature of using XML, so I was looking for an automated way to mitigate other ways of doing XSS. On my list I've got: 1. Tag injection. Check - AxKit prevents these. 2. Href javascript injection. Must be manually checked in the app. 3. Header \n\n injection. Only preventable in ap_send_header_field. (if anyone knows any XSS bugs I've missed do shout) > All this really boils down to is that the stuff that operates on > r->headers_out and r->err_headers_out shouldn't allow for line endings > to be in there, but directly putting input from the client in there is > even worse IMHO. I agree. It's like you always check your code to make sure that it's well written and does the right thing, but I still always turn on warnings and strict :-) > And I don't really think it's designed to output a header. Tables where > used because it made it easy to implement (I assume), and it's only in > mod_perl and not the C api that there are specific functions for adding > to r->headers_out and r->err_headers_out, so ultimatively if anything > should deal with it, it's either the mod_perl functions OR as Matt has > submitted around line 1570 (in my non-up-to-date cvs copy) in > http_protocol.c, and yes, I do believe it's the right thing to do so you > can't output \n nor \r's in headers. I'm not really sure it's possible to fix in mod_perl either. Otherwise I would have done it there because I find it easier to maintain a patched mod_perl than a patched Apache. > And if you would have to bypass the header_out rule you would have to > write to the socket yourself and somehow make sure apache doesn't send > the headers, right? (I'm not so sure about this part :-)) Well, then you should be using AxKit ;-) -- <!-- Matt --> <:->get a SMart net</:-> Spam trap - do not mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
