Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CookieSessionHandler proposal #22312

Closed
ossinkine opened this issue Apr 6, 2017 · 8 comments
Closed

CookieSessionHandler proposal #22312

ossinkine opened this issue Apr 6, 2017 · 8 comments

Comments

@ossinkine
Copy link
Contributor

Q A
Bug report? no
Feature request? yes
BC Break report? no
RFC? no
Symfony version 3.3

What do you think about new session handler which stores session data in cookies?
For example, this one already implemented in Laravel.
Also RoR and Django provide it.
Do we need it or not?

@linaori
Copy link
Contributor

linaori commented Apr 6, 2017

From a security perspective, this looks like a terrible, terrible idea, or did I miss something here?

@ossinkine
Copy link
Contributor Author

@iltar Please describe your worrisome thoughts

@ro0NL
Copy link
Contributor

ro0NL commented Apr 6, 2017

See also https://softwareengineering.stackexchange.com/questions/146692/why-do-popular-websites-store-very-complicated-session-related-data-in-cookies why this may work. Cookies are cheap, basically.

also consider encryption and data chunking.

@sstok
Copy link
Contributor

sstok commented Apr 7, 2017

In Symfony the cookie can contain objects (Security, Flashes), which are serialized. Storing php serialized objects on the client-side makes it possible for the client to modify these values and therefor introduce a remote scripting attack!

Unless you use a secure storage format (JSON for example) and make absolutely sure not never store an serialized object it can be safe. No, encryption is possible but unless you use a secure (not mcrypt) system this can still be compromised.

@ghost
Copy link

ghost commented Apr 7, 2017

seems like a good case for libsodium then. Note that the NelmioSecurityBundle does offer cooking signing. It did offer encryption, but is deprecating it due to mcrypt being not so good.

@patrick-mcdougle
Copy link
Contributor

Throwing more information on the heap: http://bigornot.blogspot.com/2008/06/securing-cookies-php-implementation.html

Generally people like using cookies for this since you can have stateless authentication without hitting the database. I don't generally think it's a good idea, but wanted to offer bigornot's blog post into the discussion.

@sstok
Copy link
Contributor

sstok commented Apr 10, 2017

Cipher : MCRYPT_RIJNDAEL_256 (Rijndael 256) option name : mcrypt_algorithm (see mcrypt documentation)

You know a blog post is old when they recommend MCRYPT_RIJNDAEL_256, which is not actually Rijndael 256. https://paragonie.com/blog/2015/05/if-you-re-typing-word-mcrypt-into-your-code-you-re-doing-it-wrong

Surprise! MCRYPT_RIJNDAEL_256 doesn't mean AES-256.
All variants of AES use a 128-bit block size with varying key lengths (128, 192, or 256). This means that MCRYPT_RIJNDAEL_128 is the only correct choice if you want AES.

Libsodium is the only secure standard (for now), you can also use https://github.com/paragonie/halite/blob/master/src/Cookie.php (GPL licensed, commercial licenses available) for a complete Libsodium usage implementation.

@nicolas-grekas
Copy link
Member

I'm closing here as this doesn't need to be in core. A third party library could provide it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

7 participants