On 10/17/06, samuraisam <[EMAIL PROTECTED]> wrote:
> I'm currently implementing a system which will allow users to make
> custom templates based on the Django templating engine. Before I deploy
> or even develop any further, though, I guess I should find out--how
> secure are Django templates are. Do they allow any access to the
> system? Is there something I should bolt-down before allowing users to
> use the templating engine in their templates (this will be
> public--anyone will be allowed to use custom templates)? Is there a way
> to access the database via the templates?
Templates have the following access:
* Any variables defined in the context passed from the view will be available.
* If the view used RequestContext instead of the base Context class,
any variables defined by enabled context processors will be made
available.
* Any installed library of template tags will be available for loading and use.
There are a few things you're going to want to look into carefully as
you work on this.
First off, templates *can* access things from the database under the
right circumstances. If one of the variables supplied to the template
is a QuerySet object, the template could access some methods of it and
retrieve data. Because templates do not have the ability to assign
values to variables, however, it shouldn't be possible to write data
back to the DB using only the built-in abilities of the system.
Second, you'll want to be careful about context processors. The
processors Django enables by default could raise a few problems:
* If you run at all with DEBUG enabled, a malicious user could,
conceivably, take advantage of the 'debug' processor to see the SQL
queries being run and thus gather information about the layout of your
database.
* If you keep the 'auth' processor enabled, attributes of the User
object corresponding to the current user will be available for display
in the template. Passwords will be safe because they're stored as
salted hashes, but other personal information will be available, which
means that an attacker could combine use of the 'auth' processor with
a cross-site scripting attack to gather information about users (email
addresses, usernames, login times, etc.).
Additionally, the 'request' processor is off by default, and you will
want to keep it that way. The HttpRequest object it adds to the
context exposes information about the user's cookies and session, and
that's much too dangerous to ever enable for this sort of use.
The other big place to look for problems is in template tag libraries;
template tags can take advantage of any part of Django's database API,
so be *extremely* careful about which tags you make available. None of
Django's default tags are likely to cause you problems, but if you use
any third-party tag libraries you'll want to vet them carefully to
ensure they couldn't be maliciously used.
Example:
A while back I wrote up a sample template tag, designed for fetching
"latest x", where "x" is any type of object in the database. For a
site administrator this is extremely handy and cuts down on code
duplication, but in a system which allows users to create their own
templates it's a security nightmare. Here's an example exploit:
{% get_latest sessions.Session 5 as latest_sessions %}
{% for session in latest_sessions %}
<div>
{{ session.get_decoded }}
</div>
{% endfor %}
And now a malicious user can see the full details of the last five
user sessions.
You can still implement a "get_latest" tag which takes a model as
argument, but you'll want to implement a list of "allowed models" and
have the tag raise an error (or return nothing) if the requested model
isn't in the list. It'd probably also be a good idea to have the tag
notify administrators of any inappropriate usage.
And that's probably just the tip of the iceberg if you really want to
allow any user to upload templates, but hopefully it's a good start on
identifying the sorts of issues you need to be aware of. If I think of
anything else, I'll post it.
--
"May the forces of evil become confused on the way to your house."
-- George Carlin
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users
-~----------~----~----~----~------~----~------~--~---
