[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Template storage mechanism?

On 4/7/07, Les Richardson <..hidden..> wrote:
Hi Chris,

>> Yes, but also not much use, IMO. It's about the same thing as storing
>> images as BLOB fields in a database as opposed to just dropping the images
>> into a directory as a jpg file and linking to it.
> There are some differences though.  In general, if I put something
> that the web server needs *write* access on the filesystem, then I
> have to assume that it could be compromised, either by a bug in our
> software, or by a bug in other software running on the same web
> server.  If we put it in the db, then the web server itself only has
> permission to access the file based on the credentials of the
> currently logged in user.  I suspect that there may be some serious
> security gains if we can get to the point where the main application
> doesn't need write access to the filesystem at all.

What kind of security/access control does lsmb have now and how granular
is it? (Just a pointer to a document will suffice, thanks).

No real security or access controls.  The Admin.pl access control
section can be used to remove menu items but that does not prevent
access.  1.3 will add database-level enforcement.  But we can only
extend this to the templates if they are stored in the database.
Otherwise, we are limited in our security options.

Is it normally setup to use ssl/tls or just basic authentication?

I would recommend SSL with a trusted certificate authority (whether
in-house or public).

Where are PDF files created using LaTeX? (and associated work files)
Normally the latex 'compiler' needs write access in the filesystem.

/tmp but we are careful about permissions and cleanup.  This location
can be specified in the tempdir directive in ledgersmb.conf.  It
defaults to $ENV{TEMP} on Windows.

> I don't actually think that all templates need to go in the db, just
> the user editable ones.
> One way or another, we have to have strong enforcement for HTML
> templates and these need to be sufficiently strong to prevent other
> web applications in the same server from being able to write to those
> files.  The filesystem really isn't designed to do this,
> unfortunately.

Certainly. Just run a copy of Apache with a different UID/GID than any
others on the box and force the ownership/permissions to match.

On a different port number or IP address.  And that will make it
*very* difficult to set up properly and securely.

>> This would also not be a 'good thing' for performance if there are already
>> conerns over lsmb performance and the use of mod_perl.
> Well, right now, the major performance concerns are in page load.
> This can be an issue if you have to worry about the responsiveness of
> an application for each line of a 100-line invoice you add.  On the
> other hand, waiting an extra half-second for the template isn't the
> same sort of workflow bottleneck.

So the performance issues are in the database pulling up the invoice

I think that this a non-issue for three reasons:
1)  The printing of the template is something that happens less
frequently and is less time-critical than a page update (where my
concern is at the moment) and
2)  Given the fact that this is likely to be a very small table (maybe
a few pages, maximum), I don;t think this is going to be real
performance problem.
3)  Our performance losses are almost entirely due to loading larger
numbers of CPAN modules.  Database load is not an unmanageable problem
at this point even for the largest users.

For example, I see no reason to think at the moment that our use of
stored procedures is going to be problematic for performance reasons.
We are already moving the object model (including methods) largely
into the db, and the question is do we want the templates to be
separate from this?  Especially since the security is likely to be
largely enforced by the RDBMS.

> I am more worried about being able to exploit loadable templates in
> this way.

I don't understand what is exploitable about a template..(?) Sorry.

Any time you have the ability for anyone to edit an HTML document, you
have the potential for XSS attacks.  The current lack of controls are
insufficient for anyone but the smallest customers.

Best Wishes,
Chris Travers