mattrobenolt / django-sudo

Extra security for your sensitive pages

django-sudo

Sudo mode is an extra layer of security for your most sensitive pages.
This is an implementation of GitHub's Sudo Mode for Django.

What is this for?

django-sudo provides an extra layer of security for after a user is already logged in. Views can be decorated with @sudo_required, and then a user must re-enter their password to view that page. After verifying their password, that user has elevated permissions for the duration of SUDO_COOKIE_AGE. This duration is independent of the normal session duration allowing short elevated permission durations, but retain long user sessions.

Installation

$ pip install django-sudo

Compatibility

• Django 1.9-1.11
• Python 2.7, 3.6-3.7

Resources

• Documentation
• Security
• Changelog

django-sudo's Issues

[Feature] Make optional if the sudo cookie should be reset on login

Maybe it would be an idea to tell people that they have to remove the sudo cookie themselves on logout. Otherwise it will come back on login.

Release django-sudo version 2.2

This issue is intended to track the packaged release of a new version of django-sudo. The proposed 2.2 version number is completely arbitrary and can of course be changed to whatever number is deemed most appropriate.

The primary rationale for creating this issue:

By subscribing to this issue, folks can be notified when the next release is available — i.e., when this issue is closed.

Sudo expiration is purely advisory

Sudo sessions are ended solely through a cookie expiring. This means that the user [or an attacker] can reuse the token for as long as they like.

A better approach would be to use a signed cookie, which can have a limited lifetime, controlled entirely by the server.

Support for AJAX requests?

I have a case where I would like to use sudo access for a REST API, but it doesn't appear that this will work nicely with this framework currently.

What I would propose is basically an addition to the sudo_required decorator:

if request.is_ajax():
    return HttpResponseForbidden(json.dumps({'message': 'Forbidden', 'sudo_required': True}), content_type='application/json')

There would also need to be a view which could receive an AJAX payload for authentication and return the appropriate cookie.

Is this something which would be in the scope of this project, or would it be more suited to something like a django-rest-framework-sudo package?

Django 1.11 LTS support

Django 1.8 LTS security-support is going to expire on 1st April 2018 - in just a couple of weeks. This means there that shortly there will be no supported version of Django that is compatible with this (really useful) library.

Fortunately, it looks like PR #18 adds support for Django 1.11!

Redirect to requested page on successful sudo login

I'd like to use django-sudo in a project I'm working on where a user can access update-email and update-password views. I'd like to wrap them both with sudo_required(), but I find it counterintuitive that the user gets redirected to the same page upon confirming their password. I realise the url parameter SUDO_REDIRECT_FIELD_NAME is missing from the post - but it should be possible to achieve that behaviour using session parameters, right? Or am I missing something?

Thanks for your work on this module!

Handle POST requests differently (ie don't "forget" them during sudo-auth step)

One slightly unfortunate feature of the current implementation is that POST requests just get swallowed/ignored by the interposition of the sudo authentication page.

Use case: a user can load a copy of a "secure" page, and keep it open in a browser tab for long enough that their sudo cookie expires (maybe they loaded it 2hrs59 mins after login, or maybe they just left the tab open for a long time). By the time they submit the form on that page, they are asked to re-authenticate, and on success they are redirected back to where they were, but the post request is forgotten.

Ideally there would be some magic for "saving" the post request, and then re-submitting it on successful auth. That might be a little tricky to implement mind you. A second-best / fallback would be to at least be able to display a message to the user saying they'll have to re-submit the request...

Explicitly pass 'request'

The variable doesnt exist by default in template contexts.