Develop Reference

What happens when I modify a session Id?

I'm exploring cookies and sessions [I'm using them with respect to ASP.NET C# microsoft framework]
Learnt how sessions and cookies work here and here.
My take on it is like,
Once a user logs in and establishes a session, he or she is given a session id to track them further.
Also, this sessionId can be stored on a Server, like SQL Server or a InProc, meaning it is stored on the issuing server or on a cache, Redis Cache.
My question is like,
I can understand that the sessionId is stored in a memory and being sent with every request (since HttpSessions are stateless) as HttpHeaders.
When we talk about storing sessions in a memory, which memory are we talking about ?
If we are storing them in a cookie, what If I go and modify the cookie ?
If I can modify them, what If I change the sessionId and supply in a new sessionId ?

1. When we talk about storing sessions in a memory, which memory are we talking about ?
Ans: InProc mode, which stores session state in memory on the Web server (RAM). This is the default.
2. If we are storing them in a cookie, what If I go and modify the cookie ?
Ans : Only session id is stored in cookie. If you don't want to use cookies for session tracking, asp.net framework also supports it by appending it in the URL. If you change the cookie value, the server will not be able to identify the request with the stored session data. You need to understand the http is a stateless protocol, sessionid is the identifier of a browser for the request during roundtrips. If you change the cookie value, server will not be able to identify the request.
By luck if you supply a valid sessionid, server will serve the content stored in session against that id. This is called session hijacking
https://en.wikipedia.org/wiki/Session_hijacking
3. If I can modify them, what If I change the sessionId and supply in a new sessionId ?
Ans: If you are taking about the SessionId of System.Web.SessionState. It can't be changed as it is readonly. But you are free to change anything at the client side (Cookie or URL)
Namespace: System.Web.SessionState
Assembly: System.Web (in System.Web.dll)
public string SessionID { get; }

The session data is stored on the server, either in memory or in a database. This data is looked up with a sessionId that is stored in a cookie.
2/3. Modifying the sessionId is known as session hijacking, and allows you to "be" that user. This is commonly exploited with attacks like cross-site scripting (XSS).
To protect against hijacking make sure that:
The cookie is encrypted. There are ways for ASP.NET to do this for you, but this way it cannot be tampered with
The cookie is set to HttpOnly. This ensures that the cookie can only be sent over http requests and things like javascript - and thus XSS attacks - don't have access to the cookie.
If you are using something like ASP.NET Session State, change the default name of the cookie so it is not easily recognizable

If HTTP is stateless, how does ASP.NET MVC support sessions?

I get that regular ASP finagles statefullness using viewstate, but MVC doesn't try to perpetuate the bold-faced lie of statefulness. So how is it able to maintain sessions?

By default it stores a randomly generated number in a cookie and stores that in memory. If the browser says it doesn't support cookies, asp.net will then instead add the session key in the url, it will show up like http://myurl.com/(S(rpfa4y3c5oe2c555ljanprek))/Controller/Action

It is using a Session ID to identify a user, stored in Cookies. Spoofing is possible if your know the victim's ID, and if other security measurements won't interfere (e.g IP based authentication).

Basic safe sessions in ASP .Net?

First off, I am not using Forms Authentication.
I found a great tutorial that almost does what I want:
http://www.codeproject.com/Questions/358434/Keep-me-signed-in-until-Loggged-out
The only problem is that it does not seem like a good idea. It stores the username in the cookie. That seems very bad.
How could I do something like this tutorial but in a safe way?
I essentially just want this basic flow:
if user logged in then show page
User can have the option of being logged in for the session (30 mins of inactivity) or until they choose to explicitly logout.
I have a feeling I will need a session table in my db for this, but I am not sure.
It doesn't have to be top of the line security since this is for an intranet, but I do still want it to be somewhat safe.
Thanks

Easiest way is in your Login function, once you have verified them just add:
FormsAuthentication.SetAuthCookie(theUserName, persistCookieBoolean);
Now you have an authentication cookie set. No encrypting or decrypting needed. Get the username like:
HttpContext.Current.User.Identity.Name
And see if they are logged in:
HttpContext.Current.User.Identity.IsAuthenticated
And now you can set authorization easily in the web.config too. Related post: Manual Access control in ASP .Net

Encrypt your data (username, etc) before storing in the cookie.
Read the cookie, decrypt the data & then validate.
Check this:
Encrypting & Decrypting Data in .NET Applications
Encrypt/Decrypt string in .NET

You can use Sessions.
Example Code VB:
On login do:
Session("Username") = "username"
Then each time on page load check if Session("Username") has any data/is not null.
If it's null or empty then the Session has expired and you can kick them out of the page.

mvc custom httpcookie used to authorize

Currently, I'm using the FOrmsAuthentication.SetAuthCookie to store an Id so I can use it on the next page that is "Authorized" (using custom authorizeattribute controller). But I'm currently thinking of making a custom cookie using httpcookie so I can store more data, or easily maintainable data. Was wondering if having the kind of cookie will I be able to authorize the current user to access the "Authorized" controllers? If so how do I go about it.
Hope that made sense.
Please let me know your thoughts.

Just put your extra stuff in a different cookie. And if forms auth says the user isn't authenticated, don't read the other cookies. No need to overload the purpose of the auth cookie (and non trivial to do so securely)

There is a UserData property of the FormsAuthenticationTicket. It is a string so you will have to be able to serialize/deserialize any complex data.

Good security design says dont store this information in a cookie - figure out another way (server side). Recently (octoberish) the ASP.Net POET vulnerability taught us that forms auth tickets could be forged because the machinekey could be determined and hence data encrypted as it would be on the server. I know - not exactly what you asked but I think it's important to not store sensitive data on the client side.

if cookies are disabled, does asp.net store the cookie as a session cookie instead or not?

basically, if cookeis are disabled on the client, im wondering if this...
dim newCookie = New HttpCookie("cookieName", "cookieValue")
newCookie.Expires = DateTime.Now.AddDays(1)
response.cookies.add(newCookie)
notice i set a date, so it should be stored on disk, if cookies are disabled does asp.net automatically store this cookie as a session cookie (which is a cookie that lasts in browser memory until the user closes the browser, if i am not mistaken).... OR does asp.net not add the cookie at all (anywhere) in which case i would have to re-add the cookie to the collection without the date (which stores as a session cookie)... of course, this would require me doing the addition of a cookie twice... perhaps the second time unnecessarily if it is being stored in browsers memory anyway... im just trying not to store it twice as it's just bad code!! any ideas if i need to write another line or not? (which would be)...
response.cookies.add(New HttpCookie("cookieName", "cookieValue") ' session cookie in client browser memory
thanks guys

This MSDN article seems to indicate that there is no built in mechanism for compensating with the user disabling cookies. It also indicates that session state does not work without at least some level of cookies being enabled.
I thought that there was a mechanism for passing a query variable for the session id but skimming the article (quickly) I did not see this.
Hope that helps.
EDIT: It does say that you can use cookieless sessions (I thought you could). They use a separate mechanism to embed session ID in the pages and url links.

To follow up on GrayWizardx's reply, much of what was said is completely accurate.
If you are using a Cookie'd version of Session, and cookies are disabled then you are out of luck. But you have the option to have a cookieless version of the Session, which adds a string to the URL that shows the users session id. This is very ugly looking, and has always concerned me from a security perspective.
So you have three options (that I can think of off the top of my head):
1. Require cookies. This is not a bad thing, especially if your site is one that would have requiring cookies as normal.
2. Use ViewState.
3. Pass information from page to page within the URL. This, again worries me from a security perspective.