[Solved]-Django remote user authentication and security

13👍

Let me turn this around on you: if you think this is a security flaw, then try writing an exploit that sets the REMOTE_USER header in a request to your app and see what happens.

REMOTE_USER dates back to the early days of the web when CGI pages were executed locally as the user you were hitting the web page with. REMOTE_USER is actually the name of a unix environment variable that denotes the active user. As security models for web servers changed, this scheme was preserved for compatibility. Now even IIS supports it to transparently handle Active Directory logins.

All user-passed headers begin with HTTP_. Otherwise, you couldn’t trust on any header information, like SERVER_NAME, which would be an enormous mess.

3👍

Django ‘merrily logs the user in’ because your webserver has checked that the visitor has valid credentials for that username, and set the header accordingly.

If you trust your webserver (e.g. Apache) to set the REMOTE_USER (or other) header correctly, then it’s not a security flaw.

2👍

You can see the documentation here. A user can’t send a request with customer header for REMOTE_USER.

Warning

Be very careful if using a RemoteUserMiddleware subclass with a custom HTTP header. You must be sure that your front-end web server always sets or strips that header based on the appropriate authentication checks, never permitting an end-user to submit a fake (or “spoofed”) header value. Since the HTTP headers X-Auth-User and X-Auth_User (for example) both normalize to the HTTP_X_AUTH_USER key in request.META, you must also check that your web server doesn’t allow a spoofed header using underscores in place of dashes.

This warning doesn’t apply to RemoteUserMiddleware in its default configuration with header = ‘REMOTE_USER’, since a key that doesn’t start with HTTP_ in request.META can only be set by your WSGI server, not directly from an HTTP request header.

👤ramwin

Leave a comment