I am no longer actively maintaining this project.
This module implements "paranoid sessions" for Django - sessions that work considerably harder at security than the standard version. Designed to make session-stealing attacks as hard as possible, the extra measures that can be employed are:
- HTTP header fingerprinting (e.g. REMOTE_ADDR, HTTP_USER_AGENT)
- per-request nonces (with configurable timeout and duplicate window)
- periodic cycling of session keys
- maintaining a second key for secure connections
- marking session keys as "HttpOnly"
As always, there's a tradeoff here - these security measures involve increased processing per request and more frequent writes to the session store. You also run the risk of terminating valid sessions that happen to look suspicious. But by adjusting the various settings offered by this module, you should be able to find a compromise that's suitable for your project.
To use this module, simply include it in MIDDLEWARE_CLASSES after the standard session middleware:
MIDDLEWARE_CLASSES = ( ... 'django.contrib.sessions.middleware.SessionMiddleware', 'paranoidsessions.ParanoidSessionMiddleware', ... )
In keeping with the name, the default settings of this module are designed to maximise security at the expense of performance and user convenience. You'll probably want to adjust them to a compromise that's more suitable for your application, but you should understand the tradeoffs before doing so.
In particular, the management of per-request nonces must account for the asynchronous nature of the web. Race conditions between multiple requests from the same session mean that the use of nonces cannot be perfectly serial. If a user sends two requests in quick succession, so that the second request is sent before the first response is received, then these requests will validly share a nonce. This scenario is complicated further by the fact that requests may be handled by different server processes.
To manage such overlapping requests, this module permits a small window within which duplicate nonces are treated as valid. To coordinate nonce generation across multiple server processes, they are built from a pseudo-random stream based on a shared random seed value. This should be sufficiently unforgeable for most applications - if your attacker is determined enough to compromise nonces generated in this manner, you should consider serving the entire site over a secure channel!
The following settings are available to tweak the behaviour of this module:
PSESSION_CHECK_HEADERS: List of headers to check on each request. The session will be cleared if any of these headers vary from those sent when the session was initially created.
Default: ["REMOTE_ADDR","HTTP_X_FORWARDED_FOR","HTTP_USER_AGENT"]
PSESSION_NONCE_TIMEOUT: Time (in seconds) after which a new nonce will be generated. The client must return a valid nonce with each request or the session will be cleared. Setting this to a larger value will decrease security but reduce the frequency of writes to the session store. Setting it to zero means a new nonce is generated on every request. Setting it to None will disable the use of nonces entirely.
Default: 0
PSESSION_NONCE_WINDOW: Number of nonces prior to the current nonce that will still be accepted as valid. This corresponds to the number of nonce updates that could be "in flight" between the server and client at any given time. Setting it to zero will break overlapping requests.
If you need to set it to any more than 1, your site has some serious
performance issues. Not that Django's built-in development server
*does* have some serious performance issues; set it to at least 3
for your development environment.
Default: 1
PSESSION_NONCE_WINDOW_TIMEOUT: Time (in seconds) within which old nonces are accepted. This window should be as small as possible, but is necessary if users will perform multiple overlapping requests. Setting it to None means the window never times out.
Default: 0.5
PSESSION_KEY_TIMEOUT: Time (in seconds) after which the session key will be cycled. This should only be needed if nonces are not in use; the difference is that key cycling doesn't require the client to send a separate nonce cookie. Set it to None to disable key cycling.
Default: None
PSESSION_SESSION_KEY: Session key under which the request-tracking and verification data for this module should be stored.
Default: "PARANOID_SESSION_DATA"
PSESSION_COOKIE_NAME: Name of cookie used for the per-request nonce.
Default: "sessionnonce"
PSESSION_SECURE_COOKIE_NAME: Name of cookie used for the additional "secure connections only" session key. This additional information is only passed between the server and client over a secure connection; if a sniffer or man-in-the-middle attack compromises all HTTP traffic, they still cannot forge session requests over HTTPS.
Default: "sessionid_https"
PSESSION_CLEAR_SESSION_FUNCTION: Function called to clear the session if a potential attack is detected. An importable name or callable object may be given, taking a request object as its only argument.
Default: lambda req: req.session.flush()
PSESSION_REQUEST_FILTER_FUNCTION: Function to filter requests to be checked. Any requests for which this function returns False will not be subjected to paranoid validation. This may be helpful for reducing processing overhead on low-risk targets such as media files, but will give an attacker more opportunities to compromise a given nonce.
Default: lambda req: True
If you expect a high density of overlapping requests, the default settings of this module are probably too strict and will result in valid user sessions being terminated. Consider some of the following adjustments:
* increase the NONCE_WINDOW and NONCE_WINDOW_TIMEOUT values
* filter out requests to MEDIA_URL to reduce nonce cycling
* increase NONCE_TIMEOUT to cycle your nonces less often