Session Variables - Doc Request

Question

Session Variables

In all web applications you can get / set session variables

PHP:

$foo = $_SESSION['myVar']; 

.NET (MVC, in the controller):

 using System.Web.Mvc; // ... var foo = Session["myVar"]; 

I am looking for detailed information about session variables:

• Their original purpose (what problems did they handle?)
• Common use cases

---

storage

• Where is it stored in the system?

Hard disk, RAM, ...

• Who is keeping it ?

Client / Server

• I assume this is server-side, so what drives it ?

Web Server (Apache, IIS, ...) / Web Application

• What is the lifespan of a session variable?

Session, right. So, when does a session begin, when does it end, and how does the system know when to get rid of these variables (GC mechanism)?

---

Security

• Known security flaws?

---

PS: I would like people here to create good documentation about this concept. Feel free to edit the question if you think some questions should be added or edited.

Answer 1

goal

Session variables were created primarily to combat stateless HTTP protocol behavior. Since each page request was processed completely completely separately from the request for another page, the developers wanted ways to link the sequence of requests together. A canonical example of this is the login page, which authenticates the user, and then changes the behavior of the pages requested after login.

To deal with this problem, many languages ​​and / or frameworks have provided the concept of a session variable, which would allow the developer to store data that will be associated with a specific browser and will be saved through separate requests from the same browser.

So, to take logins as an example, the first time a new browser is requested, the Session variable will be empty. Then the user will fill in the authentication information and believing that this is correct, on the server side, the code will set a session variable for this browser to contain some kind of identifier to say that its browser has been authenticated. Then, during subsequent requests, the code could check this identifier in the session variable to execute certain code requiring login.

Another common use case would be a wizard workflow. You may have a multi-page form that you want the user to fill out several separate requests. When a user fills out a form, you can add values ​​to the session until the user reaches the end of the form, after which you can save it in another persistent storage.

Storage and management

There are many ways to store session variables. Any permanent storage will work, which will be permanent for all requests. Probably the easiest way is to create a separate file for each session. PHP does this by taking the session identifier, which it saved as a cookie in the browser, and then searches for the file with the name obtained from the session identifier.

You can also store session variables in databases, shared memory, or even in the cookie itself. Ruby on Rails stores session variables by encrypting the data and then setting a cookie for the encrypted data. Thus, the session is stored in the user's browser itself.

Typically, the Session Variable is associated with a cookie, which is somehow stored in a web browser. This cookie is usually controlled automatically by the language or framework in which the web server application is written. The language or structure detects a new session and creates a new session variable that it provides to the web server application through some kind of API. The web server application can then use the API to store information in a session variable, to delete it, create a new one, etc. Typically, the framework has a specific default value for the session lifetime, but this is usually configured using the API. I think that the most typical default lifetime is the lifetime of the browser process through a cookie, the lifetime of which is associated with the user browser process.

Security

There are many security issues in session variables, as they are commonly used to control authorization and authentication in web applications.

For example, many applications set the session lifetime using the cookie lifetime. Many login systems want to force the user to re-login after a certain time, but you cannot trust the browser to expire the cookie when you tell it. The browser may be a mistake, it may be written by an attacker or manipulated by the user himself in order to set the cookie lifetime. Therefore, if your Session Variable API uses the cookie lifetime, you may need a secondary mechanism that causes the Session Expire variable to expire even if the cookie does not work.

Some other security issues are related to storage. If you store the session identifier in a cookie, and then use this session identifier as the file name to store the session variable, the malicious browser may change the session identifier in the cookie to a different identifier, and then requests from this browser will begin to use some other browser session file.

Another issue is stolen session information. By using an XSS or package check, session information can be stolen from a user browser session and then used by an attacker to access other user accounts. This issue is usually mitigated using SSL to secure the session on the go.

This page explains many security concerns when using PHP session variable variables. Ruby on Rails has a similar page that describes security issues with session variables for this platform.

Answer 2

So, I will consider this issue for two reasons: 1. I answer in accordance with the recommendations of PHP. 2. I assume that a shared hosting service is being used.

storage Using shared hosting in the php.ini file contains this answer. The file is physically created along the path specified in the line "session.save_path" in the php.ini file.

Source: php.net Guide

Who stores the session The TECHNICALLY session is stored by SERVER, but on request, obviously, by the client. So the answer is: SERVER. Source: session_start

Who controls it If your session.save_path is configured to go somewhere on a shared hosting server, then they control a GC that destroys it or ignores it until a later time. In fact, for me, there have been cases when other clients on the shared hosting server had session_gc.maxlifetime in MUCH shorter than me, so I force the session files to be destroyed in the time set by THEY (by other users), to get around this, edit your "session.save_path" within your OWN file tree.

Lifetime As stated earlier, "session.gc_maxlifetime" manages this "expiration" file. Along with this, you should take into account "session.gc_probability" and "session.gc_divisor" and set respectively "1" and "100". Google is looking for this for further explanation.

Source: session.gc_maxlifetime

Security I'm going to let php.net handle this, but here is the link!

Source: Security

Answer 3

As an example, I am using an ASP.NET application script.

ASP.NET/MVC HttpContext.Current.Session provides access to RAM, which is managed by the server (WebServer / AppServer, IIS). In the case of the Internet Information Server, the RAM used is located inside the so-called application pool and is used by one or more Applications running inside the Web / AppServer. The structure from the programmer’s point of view is a dictionary that means for access through C # that you can use this operator [] to write and read from the Session object.

 // write access var CurrentArticle = 123456; Session["CurrentArticle"] = CurrentArticle; //... // read access var CurrentArticle = 0; CurrentArticle = (int)Session[nameof(CurrentArticle)]; 

The Session object provided by .NET will be created in the Session_Start method and deleted in Session_End . However, you do not need to use the System default session store and you can implement your own, for example:

 using System; using System.Collections.Concurrent; using System.Collections.Generic; using System.Linq; using System.Runtime.Caching; using System.Web; // using MyOtherStuff; namespace MyStuff.Server.Context { public class HttpSessionState : HttpSessionStateBase { Dictionary<string, object> _sessionStorage = new System.Collections.Generic.Dictionary<string, object>(); public override object this[string name] { get { if (HttpContext.Current == null || HttpContext.Current.Session == null) if (!_sessionStorage.ContainsKey(name)) return null; else return _sessionStorage[name]; return HttpContext.Current.Session[name]; } set { if (HttpContext.Current == null || HttpContext.Current.Session == null) _sessionStorage[name] = value; else HttpContext.Current.Session[name] = value; } } } public class Current { /// <summary> /// Objects stored in Cache expire after some time; compare Application /// </summary> public static ExpiringCache Cache = new ExpiringCache(); /// <summary> /// Objects stored in Application don't expire /// </summary> public static Application Application = new Application(); public static HttpSessionState Session = new HttpSessionState(); private static System.Web.HttpServerUtility server; public static System.Web.HttpServerUtility Server { get { if (System.Web.HttpContext.Current != null) return Context.Current.Server; if (server != null) return server; server = new System.Web.HttpApplication().Server; if (server != null) return server; throw new NotSupportedException("HDitem.ApplicationServices.Current was not initialized (server)"); } set { server = value; } } } //.. } 

Each new browser connecting to your server creates a new session. If you don’t need data from recent sessions of the same user (if your application has users) than you are probably doing here.

If you want to reconnect a new session to one or more previous sessions, that is, to identify using some combination of data that you have about this user (for example, through a request, cookie or similar) or in the easiest form of user authentication than you may want to save the session data in Session_End rather than deleting it and restoring it to Session_start or at any time after that (as soon as you have enough user data for this session to identify it. if you need to some form of session containment (presumably it comes down to a hard drive or SSD to refer to your question), which in this case can be in any form for each user, sometimes stored in the user profile in a database or in any file format, such as XML or JSON based.

So, in other words: I don't want to generalize too much here, but Storage Storage is ideally fast. A memory storage that can be stored in any external storage if implemented by Session Persistence.

The above session store is server side. Modern browsers have a built-in local store, which can be accessed through JavaScript. This local storage can also be used to create session memory, which can be used differently from a server-side session, but, of course, can be synchronized in the form of explicit requests or cookie attachments.