what is your preferred method to maintain state of an asp.net page, if it is a public website (involving shopping cart, wish-list etc). I am in the process of designing a website that will need to ensure that the user is not able to tamper with the state (such as delete cookies etc).
Both of those pieces of data (shopping cart & wish list) sound like they should be stored in your database, so they can persist beyond cookies being deleted or the session timing out.
To prevent user tampering you will need to store session state on the server side. A good practice is store it either in a database (sql server) or out of process, which can be either on the same server or another server, sometimes called a state server.
I am in the process of designing a
website that will need to ensure that
the user is not able to tamper with
the state (such as delete cookies
etc).
I would use the session state. It's easy and effective.
You can't stop them from tampering with it as far as deleting cookies etc. Maybe altering the cookies, but not deleting them.
You can store the vital information on the server, so no sensitive information is stored on the client in a cookie etc.
The preferred method of maintaining state is using viewstate. However, you want to keep the amount you store in it to a minimum as it will noticeably affect speed.
If you need to store information from page to page, I would recommend using session state. It's easy and very flexible.
The user will always be able to tamper with any method you use to store state. Consider these examples:
Cookies - can alter, delete
Session - can delete, timeout, change session key
ViewState - can mess with the key
I encrypt my data and store the key in a cookie - such as cart id, user id, etc.. The cookie can be loaded at login and can be tampered with, but because the key encrypted, no real harm can be done. Storing in the session can work, but the timeouts have bitten me on many occasions and requires more considerations.
Related
So I am new to the whole datacache thing. I am building an app for a client who has potential to grow substantially so I am using the datacache instead of Session variables so that I can have multiple servers.
I have been in development mode and this has worked just fine, but it has just been me.
Now we are testing and completely new people on a computer that have never been to the site before are being recognized as another user somehow...
I do use cookies to remember a user, but these guys are coming in for the first time so that can't be it. Never had this problem with Session variables so I must be doing something wrong with the datacache.
Why does the datacache confuse the users? How do I prevent this?
Thanks!
David
cache = server level, session = user level. Your server is saving the cache data and passing it along to the users. If you have intentions of having multiple users connected, and storing separate data for each, sessions is actually the correct way to do it.
As for performance, yes there will be a slight performance hit, but it shouldn't be too drastic unless you've got a massive amount of users hitting the site at one time or you're storing huge amounts of data to the session.
You need to use Session to store a logged in users credentials and other session specific information. Datacache is used to store application wide data that can be quickly accessed, things like xml files used on the website or perhaps a dataset used by anyone on the website. Session is a unique id and "thread" for each user for their specific user name and all other information related to their logged in id.
i am using a session cookie (not a permanent one) to save the user id to know if the user is logged in.
basically, user logs in, we check the credentials, then set a session cookie userID = 37 (for this particular user, another user would have 73 or 69, etc...)
Session.Add("UserID", 37);
my question is, is it possible for the logged in user to somehow change this session cookie from 37 to 73 and thus fool the server into thinking he is actually user 73?
if YES, then what am i doing wrong, how to handle this case? it seems insane to put in session user id and password hash and check them EVERY TIME??
we are using this userid value also in queries later to restrict them.
i am sorry if this is not an EXACT code question, but it is very much relevant to my code.
The session cookie contains only the session id. It is used to identify the user. It contains nothing more. The actual information for this session is stored on the server. So this is secure. The user can never change the value that has been stored on the server. The user cannot change his id if you stored this inside the session.
This being said, when dealing with user ids you could consider using forms authentication to track authenticated users instead of reinventing wheels with the Session.
ASP.NET session state provides an important security advantage over client state management techniques in that the actual state is stored on the server side and not exposed on the client and other network entities along the HTTP request path. However, there are several important aspects of session state operation that need to be considered in order to maintain application security. Security best practices fall into three major categories: preventing session ID spoofing and injection, securing the state storage in the back-end, and ensuring session state deployment security in dedicated or shared environments.
Read : Securing Session State
That isn't the cookie, and is perfectly safe as it cannot be changed by the user. The only thing stored on the server side in a cookie is the session ID.
As the other answers have noted, the actual value (37 in the example) is stored on the server, not the client, but that doesn't mean that you're immune to potential attacks. This mechanism is still vulnerable to cross site scripting attacks. Basically, what is stored on the client's cookie is some big long identifier. If someone other than the actual user gets ahold of that identifier they can put that in a cookie of their own and essentially pretend to be that user. You can research cross site scripting more on your own (I'm not an expert on the subject) to see some of the common ways that a malicious user will attempt to look at other users' cookies and to try to set it as their own, along with ways of defending against such attacks (some of which I'm sure will be done for you by browsers and ASP).
I'm having issues with my web-application expiring the session too soon (not unexpected, just too soon for the type of system I am developing). My host doesn't allow changing the session expiration time.
So I was thinking, is there any way that I can (in ASP .NET MVC) for instance save my session variables in a form, so that when that form is somehow submitted or the page has changed, I can reset the session variables?
But with the above theory (if it's even a good theory), then how do I handle such stuff in my controllers? Or is there a better way to reach a session that is theoretically infinite?
What you are describing is the standard use-case for cookies.
If your variables don't need to be secure, then save each in a cookie (or, if you want to do it right, have a "session object" that you serialize in a cookie).
If your variables need to be secure, save them in a database or flat file and save the encrypted row id in the cookie.
You cannot retrieve a session. Once gone, it is gone (and that's good for security reasons).
However, you can keep the session from expiring:
http://weblogs.asp.net/stevewellens/archive/2009/06/09/ah-ah-ah-ah-staying-alive-staying-alive.aspx
I'm re-writing a website from the ground up for azure. Each user has ownership of a number of objects, and has a number of permissions. Together, these determine what they are authorized to do. The question is, how should this information be stored. I want to do the authentication myself, using custom logic.
For performance reasons, I'd like to cache these authorization lists for each user once they're logged in. Can someone give me a sample for how to store & access this session information securely and efficiently.
Edit
I looked into the App Fabric Access Control, but that seemed overkill as I was going to have to create a separate site for authentication, which doesn't seem to make sense. Would the claims based authentication make sense separately though? How would you do that if it does?
Would it make more sense to just keep the username in a cookie in the traditional way and then re-query table storage with each request to get the permissions etc.? How would storing the username work in Azure?
Cost is a big factor here as it's a very small site (by azure standards) but I want high performance for a small number of users.
If you want to run with a reasonable amount of availability you need to run your site with two instances. If you're running with two instances you need to use a session provider that's no the default InProc one. Your choices are:
AppFabric Caching (which you don't want to use because it's too expensive, fair enough)
Azure Storage Session Provider. Don't use this. It's an interesting experiment, but it's only sample code, it's slow and doesn't cope well in production.
SQL Server session provider.
If the permissions for a user weren't going to change while they were logged in, you could just store their permissions in session. This will probably be fast enough. However this information will need to be read from SQL for each request that uses session and it is overhead.
If you wanted to make things faster you could just store the user ID in session and load the permissions into a static dictionary (keyed on user ID) when needed. These items will need to be expired after a certain amount of time or lack of use.
Well, you could use the Azure App Fabric cache to store the session info. ASP.Net can be configured to use it as the backing store for its session state as like a normal custom session state provider.
This article from MSDN shows you how to configure it:
http://msdn.microsoft.com/en-us/library/windowsazure/gg278339.aspx
From your code you just use the normal ASP.Net way to get/set the state.
Be aware though - it could be expensive ($45/month for 128MB of cache).
I am creating a website on ASP.Net in which a user logs on and I need to store the user specific data (plus some extra data) somewhere so that all the pages in my website can readily access the data.
At one time many users could be accessing the website and every user will have his own specific data.
Currently I am using sessions to store the data after login and accessing the data on different pages as and when needed. I am also using session to pass data from one page to another. I also don't want to use cookies as many companies don't allow cookies to be created.
I understand that this is not the best practice. Can you guys suggest what would be the best way to manage the data?
Thanks,
Abhi.
Sessions are not necessarily a bad way to go. Ensure that data kept in the session is as concise as possible, and that your application will support all environments that it may be deployed into.
Also remember that Sessions do not provide data persistance once the session has been expired, so if you require data persistence, then a database would be more suitable.
This is what MS says about it, http://msdn.microsoft.com/en-us/library/ms178581.aspx:
"SessionID values are sent in clear text, whether as a cookie or as part of the URL. A malicious user could get access to the session of another user by obtaining the SessionID value and including it in requests to the server. If you are storing sensitive information in session state, it is recommended that you use SSL to encrypt any communication between the browser and server that includes the SessionID value."
As long as you use a save connection you should be fine
ASP.NET already provides you with information about the user through the IPrincipal interface and the User property.
If you need extra information about each user, you can use these to implement a User Context.