On Tue, Jan 28, 2003 at 01:08:28PM +0200, Issac Goldstand wrote:
> ----- Original Message -----
> From: "Thomas Eibner" <[EMAIL PROTECTED]>
> Subject: Re: Mitigating XSS in the mod_perl API
> 
> 
> > On Mon, Jan 27, 2003 at 02:45:13PM +0000, Matt Sergeant wrote:
> > > On Mon, 27 Jan 2003, Thomas Eibner wrote:
> > >
> > > > So, because a programmer doesn't check the validity of the input he
> gets
> > > > it's a bug that should be fixed in Apache? Maybe someone should make
> > > > sure that the same thing can't happen with allowing CGI input going
> > > > straight into a form.. oh wait.
> > > > I don't see anyone from dev@httpd wanting to "fix" this bogus error
> when
> > > > it's really just doing what the programmer wants to do (when he is not
> > > > validating the input).
> > >
> > > The programmer wants to output a header. If he accidentally tries to
> > > output something thats not a header he actually ends up outputting body.
> > > Thats a bug.
> >
> > I can see the validity of your point, but it's still a programmer error.
> > The same thing could happen if you did this as plain CGI and outputted
> > something you weren't supposed to do.
> 
> Right - except that if he's outputting it raw from CGI, we can assume that
> he knows what he's doing, while if he's using a function which is DESIGNED
> to output a header (which should NOT have an extra \n), that's obviously
> either a mistake or a malicious misuse.  Neither of which warrants the
> function doing what it was asked to do.  If the programmer wants to
> intentionally bypass the "header_out" rule, he should bypass some more and
> send the headers himself.  I know that sounds weak, but I've got to say that
> I side with Matt here.

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)
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.
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.
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 :-))

1) http://use.perl.org/~Matts/journal/10161


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

Reply via email to