Re: Mitigating XSS in the mod_perl API
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 ;-) -- <:->get a SMart net Spam trap - do not mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Mitigating XSS in the mod_perl API
On Thu, Jan 30, 2003 at 02:36:53PM +, Matt Sergeant wrote: > > 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. What I was thinking was just that since you can add a header with $r->headers_out->add it would be possible to add something there to remove newlines, but since it's probably just an Apache::Table operation it wouldn't "know" which table it is working on either. Actually getting it fixed in Apache will probably benefit many other people and not just modperl users (not probably, it will!) Are they being responsive or? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
anyone recieving this too? (again)
From: Service FC <[EMAIL PROTECTED]> Reply-To: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> Subject: Removed From APX Listings X-Mailer: Version 5.0 MIME-Version: 1.0 Didn't we have a problem with them on the other list at one point? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: anyone recieving this too? (again)
Thomas Eibner wrote: From: Service FC <[EMAIL PROTECTED]> Reply-To: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> Subject: Removed From APX Listings X-Mailer: Version 5.0 MIME-Version: 1.0 Didn't we have a problem with them on the other list at one point? I get a 'you have been removed' email from them about once a week. --Geoff - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Mitigating XSS in the mod_perl API
On Thursday, Jan 30, 2003, at 15:24 Europe/London, Thomas Eibner wrote: What I was thinking was just that since you can add a header with $r->headers_out->add it would be possible to add something there to remove newlines, but since it's probably just an Apache::Table operation it wouldn't "know" which table it is working on either. Actually getting it fixed in Apache will probably benefit many other people and not just modperl users (not probably, it will!) Are they being responsive or? No, I don't even think it got past non-subscriber moderation. However my original patch was naive, and didn't account for continuations. So I'm going to clean it up a bit more and post it as a bug report on bugzilla (though bugzilla doesn't seem to be sending me a password, so maybe I'll post it to bugtraq and just piss someone off ;-) Matt. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Mitigating XSS in the mod_perl API
Matt Sergeant <[EMAIL PROTECTED]> writes: > On Thursday, Jan 30, 2003, at 15:24 Europe/London, Thomas Eibner wrote: [...] > > Are they being responsive or? > > No, I don't even think it got past non-subscriber moderation. However > my original patch was naive, and didn't account for continuations. > > So I'm going to clean it up a bit more and post it as a bug report on > bugzilla (though bugzilla doesn't seem to be sending me a password, so > maybe I'll post it to bugtraq and just piss someone off ;-) I feel your pain, brother :-) -- Joe Schaefer, - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
using ModPerl::MM as a replacement for Apache::src
Doug, have you intended ModPerl::MM to be used only internally to the mod_perl build or by other 3rd party modules as well? I like it much more than Apache::src. I'm currently porting Apache::Peek and the Makefile.PL is: use Apache2; use mod_perl 1.99; use ModPerl::MM (); ModPerl::MM::WriteMakefile( NAME => "Apache::Peek", VERSION_FROM => "Peek.pm", ); And it works ;) The only issue is that ModPerl::MM uses the source build include dirs when compiling things, which should not be used for building 3rd party modules. So should it have a special mode for mod_perl build time, e.g, saying: ModPerl::MM::BuildWriteMakefile(...) which will add all the build-time includes, and 3rd party modules will use: ModPerl::MM::WriteMakefile(...) and it'll know to include only system-wide paths? __ 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]
public mod_perl 2.0 C API
As I was exposing mpxs_Apache_request as I needed it in Apache::Peek, I was thinking what is the public C mod_perl API. Is that everything that is defined in mod_?perl.*\.h and modperl_xs.*\.h files? What about the XS extensions, if a 3rd party app wants to use a C function which is not in the core, but in an XS extension, how does it get to that header file? Most of those things are autogenerated with static functions, so the header file is of no use. __ 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]
Changing Apache->request's behavior in 2.0
In mod_perl 1.0 Apache->request was always there. In 2.0 it's there only if
it's configured to be there('PerlOptions +GlobalRequest' or 'SetHandler
perl-script'). I believe that if I write a module that relies on
Apache->request, I shouldn't test whether Apache->request has returned
something or not, but let mod_perl handle that and croak if it's not
available, because it's a user's configuration error. And I'd rather have
mod_perl nicely hint what should be changed in order to get Apache->request
work, than write my own verification and explanations.
Remember that the code developed under mod_perl 1.0 relies on always having
Apache->request, so people will have weird problems if we don't assert.
Currently I've changed the code to assert, and let the user handle this.
Developers can always trap the croak in eval {Apache->request} if they use
this only as an optional functionality.
__
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: [patch + rfc] installing modperl .h files
On Thu, 2003-01-30 at 12:32, Stas Bekman wrote:
> The attached patch (because it has \t embedded) enables the installation of
> src/modules/perl/*.h and xs/*.h files, because we need them to be installed
> for XS extensions to be built.
+1 Great!
> First of all I'm not sure if that's the right way to install these, but it
> works for me.
>
> Second, I've chosen to install them to $APACHE_INSTALL_DIR/include in parallel
> with $APACHE_INSTALL_DIR/modules where we install mod_perl.so to. Is this a
> good choice, or do we want to install it under the perl lib tree as in
> mod_perl 1.0?
I would rather see it installed in the perl tree, just like in 1.0.
> Me thinking that it's nice to have all the headers in the same
> location (we have the ap_ and apr_ headers there already) and we don't need to
> mess with Apache2 prefixes here. The potential drawback that I could see is
> the various packaging approaches which will have to know where apache is
> installed.
That, and what if apache is upgraded/reinstalled and the content of the
destination include directory is whiped+reinstalled ?
> __
> 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]
--
Philippe M. Chiasson /gozer\@(cpan|ectoplasm)\.org/ 88C3A5A5
(122FF51B/C634E37B)
http://gozer.ectoplasm.org/F9BF E0C2 480E 7680 1AE5 3631 CB32 A107
88C3 A5A5
Q: It is impossible to make anything foolproof because fools are so
ingenious.
perl
-e'$$=\${gozer};{$_=unpack(P7,pack(L,$$));/^JAm_pH\n$/&&print||$$++&&redo}'
signature.asc
Description: This is a digitally signed message part
Re: using ModPerl::MM as a replacement for Apache::src
On Fri, 2003-01-31 at 07:01, Stas Bekman wrote:
> Doug, have you intended ModPerl::MM to be used only internally to the mod_perl
> build or by other 3rd party modules as well?
>
> I like it much more than Apache::src. I'm currently porting Apache::Peek and
> the Makefile.PL is:
>
> use Apache2;
> use mod_perl 1.99;
> use ModPerl::MM ();
>
> ModPerl::MM::WriteMakefile(
> NAME => "Apache::Peek",
> VERSION_FROM => "Peek.pm",
> );
>
> And it works ;)
Looks very nice to me ;-)
> The only issue is that ModPerl::MM uses the source build include dirs when
> compiling things, which should not be used for building 3rd party modules. So
> should it have a special mode for mod_perl build time, e.g, saying:
>
> ModPerl::MM::BuildWriteMakefile(...)
>
> which will add all the build-time includes, and 3rd party modules will use:
>
> ModPerl::MM::WriteMakefile(...) and it'll know to include only system-wide paths?
How about :
ModPerl::MM::WriteMakefile(
NAME => "Apache::Peek",
VERSION_FROM => "Peek.pm",
MODPERL_BUILD => 1,
);
For the mod_perl core build ?
>
> __
> 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]
>
>
--
Philippe M. Chiasson /gozer\@(cpan|ectoplasm)\.org/ 88C3A5A5
(122FF51B/C634E37B)
http://gozer.ectoplasm.org/F9BF E0C2 480E 7680 1AE5 3631 CB32 A107
88C3 A5A5
Q: It is impossible to make anything foolproof because fools are so
ingenious.
perl
-e'$$=\${gozer};{$_=unpack(P7,pack(L,$$));/^JAm_pH\n$/&&print||$$++&&redo}'
signature.asc
Description: This is a digitally signed message part
Re: [patch + rfc] installing modperl .h files
Philippe M. Chiasson wrote: On Thu, 2003-01-30 at 12:32, Stas Bekman wrote: The attached patch (because it has \t embedded) enables the installation of src/modules/perl/*.h and xs/*.h files, because we need them to be installed for XS extensions to be built. +1 Great! First of all I'm not sure if that's the right way to install these, but it works for me. Second, I've chosen to install them to $APACHE_INSTALL_DIR/include in parallel with $APACHE_INSTALL_DIR/modules where we install mod_perl.so to. Is this a good choice, or do we want to install it under the perl lib tree as in mod_perl 1.0? I would rather see it installed in the perl tree, just like in 1.0. I'm +0 on any place, it just was easier for me to implement it that way ;) Me thinking that it's nice to have all the headers in the same location (we have the ap_ and apr_ headers there already) and we don't need to mess with Apache2 prefixes here. The potential drawback that I could see is the various packaging approaches which will have to know where apache is installed. That, and what if apache is upgraded/reinstalled and the content of the destination include directory is whiped+reinstalled ? You still need to have to install mod_perl.so there (don't have to, but that's where we currently install to), so if you reinstall things by removing the apache tree, you have to reinstall mod_perl anyways. Perhaps mod_perl.so should be installed under the perl tree as well. Don't know if it's a good idea. __ 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: using ModPerl::MM as a replacement for Apache::src
Philippe M. Chiasson wrote: On Fri, 2003-01-31 at 07:01, Stas Bekman wrote: Doug, have you intended ModPerl::MM to be used only internally to the mod_perl build or by other 3rd party modules as well? I like it much more than Apache::src. I'm currently porting Apache::Peek and the Makefile.PL is: use Apache2; use mod_perl 1.99; use ModPerl::MM (); ModPerl::MM::WriteMakefile( NAME => "Apache::Peek", VERSION_FROM => "Peek.pm", ); And it works ;) Looks very nice to me ;-) The only issue is that ModPerl::MM uses the source build include dirs when compiling things, which should not be used for building 3rd party modules. So should it have a special mode for mod_perl build time, e.g, saying: ModPerl::MM::BuildWriteMakefile(...) which will add all the build-time includes, and 3rd party modules will use: ModPerl::MM::WriteMakefile(...) and it'll know to include only system-wide paths? How about : ModPerl::MM::WriteMakefile( NAME => "Apache::Peek", VERSION_FROM => "Peek.pm", MODPERL_BUILD => 1, ); For the mod_perl core build ? It really doesn't matter how to differ, we could definitely do what you suggest. I'd even have ModPerl::BuildMM which subclasses ModPerl::MM and overrides things as needed. __ 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: Changing Apache->request's behavior in 2.0
On Fri, 2003-01-31 at 12:34, Stas Bekman wrote:
> In mod_perl 1.0 Apache->request was always there. In 2.0 it's there only if
> it's configured to be there('PerlOptions +GlobalRequest' or 'SetHandler
> perl-script'). I believe that if I write a module that relies on
> Apache->request, I shouldn't test whether Apache->request has returned
> something or not, but let mod_perl handle that and croak if it's not
> available, because it's a user's configuration error. And I'd rather have
> mod_perl nicely hint what should be changed in order to get Apache->request
> work, than write my own verification and explanations.
>
> Remember that the code developed under mod_perl 1.0 relies on always having
> Apache->request, so people will have weird problems if we don't assert.
>
> Currently I've changed the code to assert, and let the user handle this.
> Developers can always trap the croak in eval {Apache->request} if they use
> this only as an optional functionality.
+1 I think its a good way to do this
> __
> 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]
>
>
--
Philippe M. Chiasson /gozer\@(cpan|ectoplasm)\.org/ 88C3A5A5
(122FF51B/C634E37B)
http://gozer.ectoplasm.org/F9BF E0C2 480E 7680 1AE5 3631 CB32 A107
88C3 A5A5
Q: It is impossible to make anything foolproof because fools are so
ingenious.
perl
-e'$$=\${gozer};{$_=unpack(P7,pack(L,$$));/^JAm_pH\n$/&&print||$$++&&redo}'
signature.asc
Description: This is a digitally signed message part
