Preventing Security Provider Hacks via PHPSESSID Cookie

Hi there @Teodor and/or @patrick

I am currently working with a pentration test provider to check the security of my site. The topic has come up of how easily they can break the Security Provider protection on Server Actions.

If a hacker is able to obtain the value of a PHPSESSID cookie, does this allow them to pass through the Security Provider steps and then execute the rest of a server action?

If so, are there steps I can take to be sure the value of PHPSESSID is deleted when a tab running my app is closed without the user actually logging out? Currently it seems that value is retained and visible in the Developer Console if I then open another tab and re-visit the login page of my app but don’t actually log in.

Thanks!
Antony.

1 Like

Have they managed to penetrate it so far…?

They are just trying now… so I’m trying to get as much background as I can while they work away at it!

i believe the cookie is encrypted using the security provider secret key, that is it’s purpose

1 Like

The remember me cookie is encrypted and contains the login details of the user.

The PHPSESSID is generated by your Apache server, how secure it is depends on your server settings. You have settings for the sessions in the PHP.INI file. You can set where it should store the session and all cookie settings like httpOnly and secure. Enabling httpOnly will prevent access to the cookie from JavaScript, the secure flag will server the cookie only over https.

2 Likes

Thanks for that @patrick!

So it seems that they have been able to successfully run a complete server action from knowing the value of PHPSESSID… but all my database queries also include a value taken from the Security Provider, and it appears that value didn’t return anything, so the result of the database queries in that action returned null.

@patrick, can I set something in php.ini so that the value of the PHPSESSID cookie is removed when the browser tab my app has run in is closed?

I belief that it is normally the default for session cookies to be removed when the browser is closed. As long the browser is open the cookie will stay.

Check the php documentation about session security:

PHP: Securing Session INI Settings - Manual

2 Likes

One does not hack PHPSESSID, these sessions are server-sided, they cannot be spoofed client-side

  1. Changing the value of PHPSESSID (changing a client-side cookie) is not a security vulnerability
  2. Changing the value of PHPSESSID to a random one may be equivalent to a new session being started
  3. A new session doesn’t have a logged in user
  4. Security identity will return a falsy value for that case
  5. There’s no point in removing PHPSESSID cookies on browser close, the session will continue to exist server-side if the user didn’t logout

Can you show the steps for this? It’s probably a logic issue, like a missing Security Restrict step

4 Likes

The PHPSESSID is a unique random id which will expire when the user is inactive. When you setup the cookies with the httpOnly and security flags it is impossible to get access to the id unless you have access to the client computer. And even then, the client must have been logged in and active within the session ttl otherwise the session id will be expired and the user is logged out again. When a session is expired or the cookie was removed (when browser was closed) the next visit will generate a new session id.

Some explanation about the cookie flags:

httpOnly flag will make sure that the browser will not allow access to the cookie data using JavaScript, this will protect you against XSS attacks.

security flag will only store and use the cookie when the cookie was served over https, this protects against Man in the Middle attacks. You need to serve your website over https since the sessions will then not work when served over http.

This is true, but depending on the server configuration the session on the server will also expire. I mostly keep session time around 30 minutes.

3 Likes