many session files

[Alex]

I've found out that we got around 2 million session files, although I'm regularly running sessions2trash.py to clean up old sessions. We got many users and requests but the number of sessions is still way too much.

When a user (who is not logged in) makes a new request a new session file is created. On the next request the same session file is reused, this seems fine. Which expiration time does this session file get? can I set it somehow? maybe it's all those session files without expiration which are not deleted by sessions2trash.py ...

I've seen in the documentation that it is possible to store sessions in cookies. This seems like a good way to get rid of all those session files and improve performance. Since I don't store much data in the session the small cookie size limit is not a problem for me. I'd like to know how this internally works, is it secure? How does web2py know from this session in the cookie if the user is logged in? Isn't it possible to pretend being someone else and login into another account if there is no login information stored on the server?

thanks,

Alex

[Leonel Câmara]

How are you running sessions2trash is it running for the right application?

[Alex]

> web2py.py --nogui --no-banner -S $3 -M -R scripts/sessions2trash.py -A -o -x 604800

yes, it's running for the right application, the server is slowed down because the script has to traverse so many files

[Kiran Subbaraman]

I guess you have already taken a look at the sessions related documentation here: web2py.com/books/default/chapter/29/13/deployment-recipes

• You could use "sessions.forget()", for cases where you do not want a sessions file to be issued. Maybe the scenario where the user is not logged in.
• You could also use Redis based session caches.
• Or store the sessions in the DB, and run a scheduled process (via scheduler) to cleanup the sessions database.
• Suggest you take a look at this discussion thread too: https://groups.google.com/forum/#!searchin/web2py/session$20expire/web2py/j-GwnDc0G6g/v7SVCyudr6AJ
  

________________________________________
Kiran Subbaraman
http://subbaraman.wordpress.com/about/

--
Resources:
- http://web2py.com
- http://web2py.com/book (Documentation)
- http://github.com/web2py/web2py (Source code)
- https://code.google.com/p/web2py/issues/list (Report Issues)
---
You received this message because you are subscribed to the Google Groups "web2py-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to web2py+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Alex]

Usually I don't want to use session.forget because I store things like selected language for all users. The sessions work fine also for users who are not logged in (there is only one session file created for one user) so I can't explain why there are that many files. Anyone knows about the default expiration and how to set it?

I checked the documentation so my first guess was to use redis for the sessions. But then I saw the cookie sessions which would be even better. Since web2py takes security very seriously I'm sure the cookie sessions are as save as the other methods but I'd still like to know how it works.

[Alex]

Does anyone have more information about sessions stored in cookies? is it really completely safe or is it theoretically possible for an attacker to pretend being logged in as some random user?

It is known (or easy to find out) that an app was made with web2py and the session code is open source. The structure of the session object is at least partially known. Therefor the only secret part is cookie_key I use for session.connect. I guess that's enough to make it impossible to build your own session (and store it in the cookie), right?

[Anthony]

On Tuesday, March 22, 2016 at 7:44:06 AM UTC-4, Alex wrote:

Does anyone have more information about sessions stored in cookies? is it really completely safe or is it theoretically possible for an attacker to pretend being logged in as some random user?

It is known (or easy to find out) that an app was made with web2py and the session code is open source. The structure of the session object is at least partially known. Therefor the only secret part is cookie_key I use for session.connect. I guess that's enough to make it impossible to build your own session (and store it in the cookie), right?

Right. The session data stored in the cookies is both encrypted (so it cannot be read) and signed (so it cannot be changed without detection). Just be sure to keep cookie_key a secret (for example, do not expose response.toolbar() in a publicly available page -- though in the next release, that will no longer include the cookie_key). Of course, when dealing with security issues, it's generally difficult to declare something "completely safe," but I would say at least there are no known vulnerabilities here.

Anthony

[Massimo Di Pierro]

Let's be clear. By default no data is stored in the session cookie. the session cookie is only a uuid. The data is only stored server side in a file. Unless you explicitly change this to store sessions data in a cookie. Is that what you are doing?

[Anthony]

On Tuesday, March 22, 2016 at 6:50:30 PM UTC-4, Massimo Di Pierro wrote:

Let's be clear. By default no data is stored in the session cookie. the session cookie is only a uuid. The data is only stored server side in a file. Unless you explicitly change this to store sessions data in a cookie. Is that what you are doing?

Good point. I assumed he was asking specifically about cookie-based sessions given the mention of cookie_key. The default, of course, is file-based sessions -- so no risk of information leaking via the cookie itself.

Anthony

[Alex]

yes, I'm talking about session data in a cookie. as mentioned in the book with

session.connect(request, response, cookie_key='secret')

As mentioned by Anthony there are no known vulnerabilities - unless proven otherwise. So I assume it is safe to use this method.

Further the session data in a cookie is almost 2KB. If I use compression it is around 1,2KB. The total http header size without session data is around 1KB. So the request header size would be 2-3 times larger for every request. I don't know if this really makes a difference but it is something I have to keep in mind. I'm still deciding between session data in cookie and sessions in redis.

[Massimo Di Pierro]

It is but make sure you do not expose the welcome app. That app exposes (as an example) the state of the system, which includes your secret key. The next we2py version (this week, I promise) will prevent that.

[Anthony]

On Wednesday, March 23, 2016 at 1:22:27 AM UTC-4, Massimo Di Pierro wrote:

It is but make sure you do not expose the welcome app. That app exposes (as an example) the state of the system, which includes your secret key. The next we2py version (this week, I promise) will prevent that.

Do you mean the examples app rather than the welcome app? If so, my understanding is that it exposes the cookie_key of the examples app itself, not the cookie_keys of any other apps -- so the risk is not that the session data of other apps will be compromised but that there is a different vulnerability via the examples app (which is therefore a risk of any installation, regardless of the type of sessions used in other apps), no?

Anthony

[Alex]

I've blocked all the other applications in the apache config. just wondering: wouldn't it be better to move the applications from the web2py git repository to somewhere else? I'm using web2py source from git (with specific tag) for my productive system and therefor also have the examples and welcome app installed. Since they are blocked it's not an issue for me but it's probably not optimal.

Concerning my session handling: I think I will modify my code to only create sessions when the user is logged in. Until now I also used the session for anonymous users to store the selected language but I can move this into a cookie. So I assume the number of sessions will be reduced from ~ 2 millions (for users, monitoring requests, crawlers and whatever) to a few thousands. This alone should solve my performance issues.

Maybe I'll store the sessions in the same db after all and not in an additional redis db. I guess the performance difference is negligible, especially since there will be much fewer sessions.

Alex