[EMAIL PROTECTED] wrote:
>
> why don't you place your embedded perl that you need in a directory where
> the users on your website can not write and alias those scripts to appear
> as if they were in the webtree .. eg inside your apache conf somewhere you
> would have ..
>
> AliasMatch ^/(.*\.epl) "/web/embperl/$1"
>
> <Files *.epl>
> SetHandler perl-script
> PerlHandler HTML::Embperl
> Options +ExecCGI
> </Files>
>
> this would alias every embedded perl script to a directory that only you
> would have access to .. this would prevent others from having .epl's in
> the webtree as apache would be looking in /web/embperl/ for .epl's but
> that's what you want. Embedded perl in regular .html files would be
> ignored.
>
> or you could even restrict it to one location with
>
> <LocationMatch ^/mywebdir/mypage.html>
> Options ExecCGI
> SetHandler perl-script
> PerlHandler HTML::Embperl
> </LocationMatch>
>
> mike
Thanks Mike! I have done similar things in the past. But in this case it
won't work (I believe) because I actually need the files which are being
uploaded by the users to be part of the EmbperlObject directory search
tree (i.e. under the directories which are handled by Embperl). That is,
I may have a directory such as /www/htdocs/users/neil/subdir/subdir/,
and I have EMBPERL_OBJECT_BASE set to base.html, and base.html is in
/www/htdocs/.
So, every user's .html file will be automatically included by base.html
(using Execute (*)), which is how EmbperlObject is supposed to work (and
I like it a lot). But it seems to me that in order for a file to be
interpreted by Embperl in this way (i.e. Executed from the base.html
using EmbperlObject), then it does need to also be interpreted by
Embperl - and so be in a directory tree which is set as being handled by
Embperl. Thus we have the problem of security, because these files are
supplied by users.
This is why I thought my initial suggestion would be a workable solution
to the security issue, because it doesn't matter so much if the users
have HTML code which is interpreted by EmbperlObject, as long as there
isn't any Perl in there. So removing all Embperl [-, [! etc would
achieve this. At least that's my theory; I was wondering if I was
missing anything subtle (or glaring) that would allow the malicious user
to get around that.
Bear in mind that what I need from EmbperlObject in this particular
situation isn't so much its ability to execute my Perl code, as its
ability to let me build a very elegant website using object-oriented
principles. That is, I have a base.html which is then utilized by all
the users' files automatically (thus giving the website a uniform look
and feel, navigation bar etc).
Now, it's possible I have misinterpreted your suggestions. I am not
expert on the Apache configuration. Given my additional explanation, do
you still think that my goal can be achieved using the methods you
proposed?
Either way, thanks very much once again for taking the time to reply.
Much appreciated.
Another security issue will obviously also be validating filenames to
make sure the users cannot attempt to overwrite files in other
directories than their own. So parsing out "..", "/" and suchlike is
also necessary, but separate from the particular problem of preventing
Perl execution.
Hope this is clear! If not, I can supply a more concrete example.
Just a thought: Gerald, it seems to me that there may be something worth
looking at here. As I am finding, EmbperlObject gives us a lot of help
in the process of building elegant websites, but what it is doing is
really quite separate from the rest of Embperl. That is, EmbperlObject
allows the manipulation of *whole files*, where we may not care to have
any actual Embperl code in these files. Indeed, in my case I actively do
*not* want any Embperl code to be interpreted in these files which are
included via Execute(*). But I do still want them to be processed by the
EmbperlObject engine, so that I can utilize base.html as a template.
So, there appear to be two uses for Embperl: The first is the more
traditional one which everyone is familiar with, where Perl code is
executed within your HTML files. The second is perhaps newer but an
interesting development - where we have Embperl handling *construction*
of a web page, without necessarily caring about the contents of the
files being pulled in by Execute(*). Would it be worth considering a
feature which would allow files to be included in the EmbperlObject
handling, but *without* internal parsing? So, they can simply be
included using the Execute(*) method?
Perhaps a directive which allows certain file extensions to be processed
by EmbperlObject::Execute(*), but not parsed and interpreted internally.
I may be way off here. I'd be interested to know if this makes sense to
anyone else.
All the best
-Neil
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
