Hi Isaac,
I've thought about this but never implemented it...
I don't think DB routers will really do what you want; you are making
the assumption that your Django project is compromised and you need
separation at the DB level, which means that every route is also
compromised as all the access credentials need to be available to your
Django project.
As far as I can see, the only way to do this and to avoid the potential
for code vulnerabilities, privilege escalation, etc, is to split the
whole project into separate sub-projects (matching separate use cases),
each with its own DB access credentials with matching (minimum) database
privileges, but all sharing the same database. You then separate the
sub-projects according to your risk appetite:
* Separate URL spaces within the same FQDN that are handed off by
different web handlers to different django sub-projects on the same
server.
* Separate FQDNs within the same web server, each with its own virtual
host and web handler.
* Separate FQDNs on separate VMs on the same physical host, with the
DB on a different VM. Implement IP tables and/or virtual firewall to
limit DB access to the web VMs.
* Separate FQDNs on separate physical hosts in the same datacentre...
* Separate hosts in different datacentres with DB replication (over
VPN?), allowing only the replication of a 'write' database to write
into a corresponding 'read' database. This is not quite 'sharing the
same database' as above, but the replication cluster can be treated
as a single database.
* etc.
Once you have separated the apps in this way, you can apply whatever
additional layers (eg IP address filtering for VPN-only access, SSL
client cert authentication) to mitigate against attacks to the more
sensitive aspects. Note: if you don't protect the more sensitive parts
by other means, then there is little point in separating the project in
the first place, unless you think that 'security by obscurity' is a
valid defence mechanism.
I cannot think of another way to deal with the threat that I think you
are trying to mitigate, but it would be interesting to see if anyone has
any other ideas.
John
On 14/01/13 14:41, Isaac Perez wrote:
> Hi Tom,
>
> my main goal is to avoid that the access to the users table by
> anything else other than the authentication module.
> I understand that writing the app correctly and filtering the input,
> etc... will do the same, but it's just another layer of security.
>
> I'll take a look to the DB routers and how this can be implemented.
>
> Thanks for your reply.
>
> Cheers,
> Isaac
>
> 2013/1/14 Tom Evans <tevans...@googlemail.com
> <mailto:tevans...@googlemail.com>>
>
> On Sun, Jan 13, 2013 at 5:05 PM, Isaac Perez
> <isaac.perez.mon...@gmail.com
> <mailto:isaac.perez.mon...@gmail.com>> wrote:
> > Hi guys,
> >
> > I'm creating a new app and I'd like to know how would be the
> best way to
> > implement the principle of least privilege.
> > At the moment the DB has 5 users:
> >
> > 1 is the root user for the DB (which I don't want it to be used
> by the
> > webapp)
> > 1 has read access to the data fields
> > 1 has write access to the data fields
> > 1 has read access to the users table
> > 1 has write access to the users table
> >
> > What I intend to achieve is that if in any occasion we've got a sql
> > injection for whatever the reason, the access to the DB from the
> app form
> > will be as limited as possible.
> >
> > If using python directly I would create a DB connection for each
> > functionality so they use the right DB user and have the right
> permissions.
> >
> > In Django, though, as you have to configure the default DB
> access in the
> > settings and it has to sync, etc... I'm not sure what will be
> the best way
> > to implement that splitting of privileges.
> >
> > I've configured the 5 connections in the settings but not sure
> how to best
> > use them for the different functions of authenticate, read and
> write from
> > the DB.
> >
> > Any ideas?
> >
>
> Hi Isaac
>
> Personally I think this is overkill, but you can achieve exactly what
> you want by using DB routers to allow Django to select the right DB
> connection to use at the right time.
>
> However, what's the point? If your DB router correctly tells Django to
> use the "data write" DB handle when saving data fields on an object
> loaded from the "data read" DB handle, then it would do so whenever
> asked to save an object. So saving objects would always use the write
> handle.
>
> In effect, by separating out read and write handles, all you are
> protecting against is Django accidentally generating a query to modify
> your DB when it is attempting to generate a query to read from your
> DB.
>
> Cheers
>
> Tom
>
> --
> You received this message because you are subscribed to the Google
> Groups "Django users" group.
> To post to this group, send email to django-users@googlegroups.com
> <mailto:django-users@googlegroups.com>.
> To unsubscribe from this group, send email to
> django-users+unsubscr...@googlegroups.com
> <mailto:django-users%2bunsubscr...@googlegroups.com>.
> For more options, visit this group at
> http://groups.google.com/group/django-users?hl=en.
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Django users" group.
> To post to this group, send email to django-users@googlegroups.com.
> To unsubscribe from this group, send email to
> django-users+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-users?hl=en.
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
