Thanks for the responses and insight everyone (special thanks to Russel to clarifying what type of attack this is). I will point this discussion out to the Mezzanine users group and hopefully it will generate some more thought into the matter.
@Nikolas, you summed up what I was thinking well. I am wondering if the those two goals of not trusting user content and allowing admins to post rich content are mutually exclusive. @John, I like that idea the only problem is that it wouldn't necessarily have to be a superuser, I think anyone with permission to change users who viewed the code could cause the privilege elevation. @jim, I like the idea of putting the admin on a different subdomain although that is not always feasible. I don't know if the Django admin uses ajax internally but I wonder if it would be appropriate for there to be a Django setting which would disable posting via ajax to the admin, rendering obsolete this sort of injection, and still allowing admin users to post javascripts? I'm not sure if it's always possible to reliably differentiate between an ajax vs non-ajax request. On May 12, 7:31 pm, jim <jim.whit...@gmail.com> wrote: > On Fri, May 11, 2012 at 10:11 PM, Josh Cartmell <joshcar...@gmail.com>wrote: > > > > > > > > > > > I work a lot with Mezzanine which is a CMS that uses Django. A > > security issue was recently revealed where an admin user, lets call > > him A, (they can post rich content) could put a cleverly constructed > > javascript on a page such that if a superuser, let's call her B, then > > visited the page it would elevate A to superuser status (a more > > thorough explanation is here: > > >http://groups.google.com/group/mezzanine-users/browse_thread/thread/1... > > ). > > Apparently any django app which allowed admin users to post arbitrary > > html would be vulnerable. > > > My first thought was that csrf protection should prevent this but alas > > that is not the case. The only real solution found is to restrict > > admin users from posting any javascript in their content, unless you > > completely trust the admin users. > > > My question is are there any other solutions to these sorts of > > problems? It seems like allowing an admin user to post javascript is > > reasonable, what is unreasonable is for that javascript to be able to > > elevate a user's privilege. Could improvements be made to the csrf > > mechanism to prevent this sort of user privilege elevation? > > One way to do this would be to have the admin interface on a different > subdomain to any user-generated content. Then JS in user-generated content > that tries to access the admin interface will be foiled by the same-origin > policy. > > > > > > > > > -- > > 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.
