Hi John, I think you are going one step further of what I intended to protect from. That makes me think about what you are saying but I think it's going to be too complicated, I'll have to see the risk of that happening.
In a few words what I want to protect from is that an sql query could be passed in the main input text box and it could access other users passwords or information. Also don't feel comfortable with the app having root access to all the DB if it doesn't need it for it's main function, just in case. It may be unlikely that this happens and we are implementing other input controls, etc... But I thought it would have been easy enough to just have different connections and use each one for a different function inside the app. If routing does that, I think it's enough. If the whole app gets compromised, we are in trouble :-) Thanks for your reply Isaac 2013/1/14 John <john-dja...@martinhome.org.uk> > 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> > >> On Sun, Jan 13, 2013 at 5:05 PM, Isaac Perez >> <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. >> 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. > > > -- > 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.
