Reputation: 46853
I'm new to PHP and trying to get my head around security.
I have an admin page that gives access to certain administrative tasks. Right now, it lets you repopulate database tables with some seed data.
To access the admin page, you first need to login. Currently the login is not over https (it will be soon).
If you authenticate, a token is written into $_SESSION. In every admin page, the token is checked. If invalid, the page is redirected to the login page.
My question:
Is this the proper way to "lock" down sensitive administrative tasks in PHP? Checking a value inside the $_SESSION variable? What more should I be doing?
Upvotes: 2
Views: 132
Reputation: 77420
Session IDs are stored client-side usually as a cookie. If someone steals the cookie, they can hijack the session. Even if you use a secure connection for the login, later, unsecured requests will send it over the wire, and any XSS vulnerabilities can be used to capture the session cookie regardless of encrypted communication. Use session_set_cookie_params
to limit the subdomain and path of the pages the cookie is sent to.
You can try to use non-spoofable client data to detect hijacking. Since you don't have control over the protocol, about the only such data is the remote IP, though an attacker can make a blind attack while spoofing their IP. However, this doesn't protect against hijackers behind the same NAT as the valid user and has problems with proxied requests.
You might be able to work out something with HTTP digest access authentication. It's a challenge-response authentication protocol and thus designed to work without protocol-level encryption. However, it's based on MD5, which has known weaknesses. Considering the life of the challenge, this may not be an issue. Digest auth is vulnerable to a man-in-the-middle attack.
Upvotes: 1
Reputation: 317119
You could look into role based Access Control Lists if you need a more fine grained level of control. This way, authenticated users are granted or denied access to certain parts of your application based on the role you have given them. This is an additional security measure on top of regular password authentication.
If you only got one user, e.g. the admin, ACL is overkill though.
Upvotes: 1
Reputation: 12323
That's pretty much the standard way to do it. Authenticate the user against your user database / password file / some other authentication data, store the state of authentication in a session variable and finally check whether the session variable is properly set every time the user attempts to make an action that requires authorization.
Upvotes: 3