[eluser]Molchy[/eluser]
DELETE
[eluser]WanWizard[/eluser]
Care to explain what it is that makes this secure?
A quick glance of the code shows that you have removed the most secure part of CI's session library, which is the encrypted session cookie.
Instead, you rely on $_SESSION, and I assume PHP's native session cookie as well (although I don't see a sess_start() call anywhere, it needs auto start needs to be configured too?), which is very insecure!
[eluser]Molchy[/eluser]
[quote author="WanWizard" date="1307310538"]Care to explain what it is that makes this secure?
A quick glance of the code shows that you have removed the most secure part of CI's session library, which is the encrypted session cookie.
Instead, you rely on $_SESSION, and I assume PHP's native session cookie as well (although I don't see a sess_start() call anywhere, it needs auto start needs to be configured too?), which is very insecure![/quote]
- session_start(); is in _constructor, it seems bitbucker commented it 
- cookies are not that secure encrypted or not, so no cookies in this class
- in native session is only saved session_id, ... and needet data to database session works, all user data is saved in database and retrived from their
I tryed many session classes publicly add-et in CI and everything had something which didnt work:
- Or IE
- Or using cookies
- Or just native
- Or native + db and session destroy didnt work at it should
- Or db and garbage collector didnt work as it should
- Or is not maintain by authours
Database driven sessions have many advantages:
- More secure if not using cookies
- Easy monitoring from admin side
- How many user online lib. can be writen on it
- ...
So this is my way dooing thins and u can not know how it works if u dont test it yourself or checking all the code.
No one is perfect so if anything doesnt work well i will fix it with glad as myself using this Class 
[eluser]WanWizard[/eluser]
You seem to forget that EVERY session solution, including PHP sessions, create a cookie to track it.
With CI's session library, the cookie contains extra security measures, and it is encrypted so the session id can not be stolen. With PHP's sessions, there's a cookie with a single value: the unencrypted session id.
In all the years I've been reading about so called issues with CI's session class, it's more often then not about a user error when configuring the library. People using 'native' solutions are just lucky that most php.ini files contain a set of defaults that often work.
I don't mind you using this, it's up to you. I do mind you telling other potential users it is secure, when it isn't.
[eluser]Molchy[/eluser]
[quote author="WanWizard" date="1307315248"]You seem to forget that EVERY session solution, including PHP sessions, create a cookie to track it.
With CI's session library, the cookie contains extra security measures, and it is encrypted so the session id can not be stolen. With PHP's sessions, there's a cookie with a single value: the unencrypted session id.
In all the years I've been reading about so called issues with CI's session class, it's more often then not about a user error when configuring the library. People using 'native' solutions are just lucky that most php.ini files contain a set of defaults that often work.
I don't mind you using this, it's up to you. I do mind you telling other potential users it is secure, when it isn't.[/quote]
- This data is only saved into native session which do those extra cookies which are not made by my class:
$_SESSION['session_id'] = $this->userdata['session_id'];
$_SESSION['ip_address'] = $this->userdata['ip_address'];
$_SESSION['user_agent'] = $this->userdata['user_agent'];
$_SESSION['last_activity'] = $this->userdata['last_activity'];
None of this data is big security risk so but good point to encrypt it. All other data which is specifyed by user goes into database which is more secure then cookie or native session.
I have plans to add a option to encrypt data in database and will try to encrypt this risk free cookies.
Any comment is good and helpfull... + no code is totaly secure not my and not CI base.
We can only do it more secure and better.
Modified first post to better explain NO USER DATA IN COOKIES OR NATIVE SESSION
[eluser]WanWizard[/eluser]
You're not getting it.
By default, PHP's native session creates a cookie called PHPSESSID, containing the session id that links the browsers session to the session file on the server. In your solution, this session file contains the session ID you use to lookup the session.
So:
- you use an unencrypted, unsecured cookie that is very easy to steal.
- your library uses "sess_time_to_update" to update the session ID stored in the PHP session, but not the PHP session id itself, rendering this feature useless.
- if on a shared host, every web app can read your session files (which is true for all PHP session files, unless special precautions were taken).
Since your library retains the DB storage backend (which is a good thing), the only thing you replaced is the cookie mechanism. By something that's not secure, and only for the reason that people can't follow the simple rules to configure CI's session cookies properly.
CI's session cookie protection is actually one of the best features of the session library, there's a lot of room for improvement on the rest of the code (like making it multi-request proof, deal with ajax calls properly, etc). Since you're logic is based on CI's, your library suffers from the same shortcommings.
Therefore I don't see the point of swapping CI's class for yours...
[eluser]Molchy[/eluser]
[quote author="WanWizard" date="1307317118"]You're not getting it.
By default, PHP's native session creates a cookie called PHPSESSID, containing the session id that links the browsers session to the session file on the server. In your solution, this session file contains the session ID you use to lookup the session.
So:
- you use an unencrypted, unsecured cookie that is very easy to steal.
- your library uses "sess_time_to_update" to update the session ID stored in the PHP session, but not the PHP session id itself, rendering this feature useless.
- if on a shared host, every web app can read your session files (which is true for all PHP session files, unless special precautions were taken).
Since your library retains the DB storage backend (which is a good thing), the only thing you replaced is the cookie mechanism. By something that's not secure, and only for the reason that people can't follow the simple rules to configure CI's session cookies properly.
CI's session cookie protection is actually one of the best features of the session library, there's a lot of room for improvement on the rest of the code (like making it multi-request proof, deal with ajax calls properly, etc). Since you're logic is based on CI's, your library suffers from the same shortcommings.
Therefore I don't see the point of swapping CI's class for yours...[/quote]
I understand what u meen make it better. But still others can not access other one session because data specifyed by user is in database and not in native session or cookie. Native session just helps to give wright person wright data, by his Session ID, IP address and useragent.
I will update this class with encryption for cookies which are made by native session.
Tnx for advice
[eluser]WanWizard[/eluser]
No, you're not getting it!
If I access an application using this library, it will create a cookie called PHPSESSID. With a PHP session id in it, which is created when sess_start() is called. The session id is a simple MD5 string. This session id links to a session file with the same name on the server, usually in a shared location, and r/w by the webserver.
If I can steal that PHPSESSID cookie, and add it to my browser, it will send the stolen cookie to the server, where it gets matched with the corresponding file, from which the DB session id is read, which gives me access to that user's session data. Stealing a cookie is not that complicated. This the main reason for including the user's IP and user agent string in the cookie, and then encrypt it. If stolen, the cookie is not going to work on the PC of the hacker, unless IP and browser matches. By storing this server side in PHP session storage, all this functionality no longer works, you store it for nothing.
If I run a web service on the same server (mostly an issue in case of a shared host), I can write a PHP script that reads the shared session file storage. A simple directory scan will give me all session id's issues and not cleaned up yet. I can then use those to create a PHPSESSID cookie in my browser, and again I have access to the session.
If that session contains the user's logged-in status, I am now logged in as that user, and can access all the users information. With some luck personal details, email adresses or phone numbers, payment data if I'm very lucky.
[eluser]Molchy[/eluser]
[quote author="WanWizard" date="1307318492"]No, you're not getting it!
If I access an application using this library, it will create a cookie called PHPSESSID. With a PHP session id in it, which is created when sess_start() is called. The session id is a simple MD5 string. This session id links to a session file with the same name on the server, usually in a shared location, and r/w by the webserver.
If I can steal that PHPSESSID cookie, and add it to my browser, it will send the stolen cookie to the server, where it gets matched with the corresponding file, from which the DB session id is read, which gives me access to that user's session data. Stealing a cookie is not that complicated. This the main reason for including the user's IP and user agent string in the cookie, and then encrypt it. If stolen, the cookie is not going to work on the PC of the hacker, unless IP and browser matches. By storing this server side in PHP session storage, all this functionality no longer works, you store it for nothing.
If I run a web service on the same server (mostly an issue in case of a shared host), I can write a PHP script that reads the shared session file storage. A simple directory scan will give me all session id's issues and not cleaned up yet. I can then use those to create a PHPSESSID cookie in my browser, and again I have access to the session.
If that session contains the user's logged-in status, I am now logged in as that user, and can access all the users information. With some luck personal details, email adresses or phone numbers, payment data if I'm very lucky.[/quote]
Took ur advice and check some articels, session libs from other frameworks and independet ... and changed first post regarding this.
Now using CI_Session lib with MY_Session lib which has some fixes ...
[eluser]Asiansexynine[/eluser]
Denis Molan : I also looking for new CI session.. session cookies may not work if web browser were disable cookies.. I want to store session files on local server via session.save_path or database session .. but for database session need to run cronjob to deleted expire session..
did you have idea to store session in database and deleted expire session without run cronjob?
|
