I have a hidden input on my form, and my JavaScript code writes there dynamically generated string based on the user behavior on the page.
Later, I access to that inpput via server side code.
Many users will be using this page at the same time, so what about thread safety ?
I mean, could it be possible that userA has an access to that string generated by userB ? Or maybe server will read that string from each user's Web Browser ?
This is all happening at the client side, on each individual user's machine - when they post the data from their machine, you'll get the data created there - there will be no cross pollution.
As far as I remember, there won't be any problem regarding thread safety.
Considering the Server side, when a user visits an asp.net website, he/she is given a different application domain in the server, so I guess there won't be much trouble here.
And about the javascript, it is executing inside the client's browser and machine, so why on earth there will be concurrency problem?
Related
I'm building a solution where 2 applications are involved.
One of them handles the login and user management, and and other provides the service itself.
I need a way to send the user from the first app to the second, along with some data that derives from the whole login process.
The data has to be sent in such a way that it can't be tampered with; or a way to check if it's legit has to be available.
Some more details:
The solution consists of 2 ASP.NET (Webforms) websites
Although both websites are sitting on the same server, a solution that doesn't rely on this is prefered
Thanks in advance.
It might not be the best solution.
But this is what immediately comes to my mind.
Serialize the data, (from first website) that you need to pass, into a database accessible from both web sites (can be a third server in worst scenario when your both website might be sitting on different server).
Generate a key for the serialized data in the database. It can be a GUID. Pass it on to the other web site. Other website can delete it immediately after retrieving it by using the give key.
You could set an encrypted token cookie in the login application and pick it up in the management application.
I don't know of any way to transfer state data between applications on the server.
I am not if it is possible to use Server.transfer to the second site. But this would definitely be tamper-proof since it would occur on the server. The landing page on the second side would then persist the transfered info. Context object would be a good location to store the transfered info.
At a minimum it would recquire both apps to be on the same server.
I have a web application that is secured and stores user detail information in a session object. I am building a Silverlight control to view images that are stored in the database and access to those images needs to be secured. I am not trying to prevent copying or anything like that but I need to make sure that the user accessing the image actually has access to view the image which can be achieved by checking the user data in the session.
So my thoughts were to do the following:
Web Application that has hosts the Silverlight control.
A ashx file to handle the serving up of the image from the database.
The ashx file when accessed via the silverlight control will check the session to make sure they do have access to this image. (I am assuming the silverlight control and web app share the same session, this could be a wrong assumption.)
Does this setup sound correct or are there other ways of approaching this? This will be my first time integrating a Silverlight control into a web application.
THe silverlight control lives within the context of the browser. I think that if you're silverlight control callse your ashx page, the ashx page will execute under the same session that your web application is running.
When a user logs into your web application, store something in the session to indicate they are authenticated, and check it in your ashx page.
It is a simple scenario to mockup and test.
Sounds like you want to ensure that nobody is sniffing traffic to determine the URL to your ashx path. Perhaps you don't want that URL being used independently from your page, or for other images that the user/caller shouldn't be seeing.
Have you considered leaving a cookie value for the client? Perhaps a scenario like this:
when your customer visits the page, it sounds like you want to load an image into a Silverlight control. At the time that you're processing the other data on the page, send a cookie value back to the browser.
drop a salted/hashed value in a cookie based on the browser/caller AND the image being requested.
Let's say that the image is someImage.png, and the client's IP address is 10.10.10.10. Use some salt like the image's db identifier to ensure uniqueness between images. Let's pretend it has ID 509.
Run the string "509_someImage.png_10.10.10.10" through a one-way encryption method (i.e. AES) using a strong key that you keep secret on your end. Let's pretend that your result is 'biglongcrazyrandomstring123', but it will obviously be much longer.
on the querystring to the call to the image.ashx page, force the include of that value (i.e. image.ashx?img=someImage.png&key=biglongcrazyrandomstring123).
On the server side, you go to your DB and retrieve the ID for someImage.png. Run the requestor's IP address, the image file name, and the database ID through the same encryption algorithm. Compare THAT value with the value sent in the querystring. If they match, then you know that YOU put the string in their cookie. Rather, you know reasonably that they couldn't have guessed it.
If anyone tries to mess with that querystring value, it'll fail every time because you're comparing two generated values.
I'm porting an ASP.NET application to MVC and need to store two items relating to an authenitcated user: a list of roles and a list of visible item IDs, to determine what the user can or cannot see.
We've used WSE with a web service in the past and this made things unbelievably complex and impossible to debug properly. Now we're ditching the web service I was looking foward to drastically simplifying the solution simply to store these things in the session. A colleague suggested using the roles and membership providers but on looking into this I've found a number of problems:
a) It suffers from similar but different problems to WSE in that it has to be used in a very constrained way maing it tricky even to write tests;
b) The only caching option for the RolesProvider is based on cookies which we've rejected on security grounds;
c) It introduces no end of complications and extra unwanted baggage;
All we want to do, in a nutshell, is store two string variables in a user's session or something equivalent in a secure way and refer to them when we need to. What seems to be a ten minute job has so far taken several days of investigation and to compound the problem we have now discovered that session IDs can apparently be faked, see
http://blogs.sans.org/appsecstreetfighter/2009/06/14/session-attacks-and-aspnet-part-1/
I'm left thinking there is no easy way to do this very simple job, but I find that impossible to believe.
Could anyone:
a) provide simple information on how to make ASP.NET MVC sessions secure as I always believed they were?
b) suggest another simple way to store these two string variables for a logged in user's roles etc. without having to replace one complex nightmare with another as described above?
Thank you.
Storing the user's role information in a server-side session is safe providing a session cannot be hijacked. Restating this more broadly, it does not matter where user role info is stored if an authenticated session is hijacked.
I advise not putting too much faith in the article you linked to, but the 2002 vintage report linked to from your link is of interest. Here are my take-aways:
Don't accept session IDs embedded in URLs.
Focus your time on eliminating cross site scripting dangers i.e. scan all user supplied data and parse out executable java script.
Issue cookies for complete domains (e.g. myapp.mydomain.com)
Host your domain at a high class DNS operator e.g. one that only allows DNS changes from a preset remote IP address.
Don't issue persistent session cookies.
Reissue a session cookie if someone arrives at a login page with a sessionID already associated with an authenticated session.
Better still, always issue a new session cookie on successful authentication and abandon the prior session. (Can this be configured in IIS?)
The only way to make a secure cinnection is to use SSL. Anything less than that, and you simply have to make the evaluation when it's "safe enough".
A session variable works fine for storing a value, with the exception that the web server may be recycled now and then, which will cause the session to be lost. When that happens you would have to re-authenticate the user and set the session variable again.
The session variable itself is completely safe in the sense that it never leaves the server unless you specifically copy it to a response.
Have you considered setting up a custom Authorize tag in MVC. I gave an example of this in another question.
On initial authorization (sign-in screen or session start) you could seed a session value with the IP address also. Then in your custom authorization, you could also verify that IP's still match up as well. This will help make sure that someone isn't 'stealing' the person's session. Everytime you access your session data just make sure to pass the requester's IP and have some check on it.
Are you trying to control the access to functions at the client level? That is the only reason I would expose the roles and items to control client side functions.
Alternatively, you could create a function to obtain the items that the roles of the user are allowed to use, and then even if the function is called outside of the items given back to the web application, you can prevent the user from accessing them.
4Guys seems to show how to control functions with the roles.
The approach I have used in the past is to use symmetric encryption of a cookie alongside SSL. Encrypt the user information in the reponse and decrypt it in the request. I'm not claiming this is foolproof or 100% secure and I wouldn't want to do this on a banking application, but it is good enough for many purposes.
The main issue with session variables is that if you store them inProc rather than persisting them, then you need to apply 'sticky' sessions to your load balancing in a web farm environment. Guffa is correct that without this persistence session variables will occasionally be lost causing a poor user experience.
Sticky sessions can lead to uneven load balancing, perhaps reducing the value of being able to scale out.
If you are going to be be persisting the sessions so they can be accessed by all servers in your web farm, you may be better off using a Guid to identify the user, encrypting this in a cookie and retrieving the user record from your data store each time.
My obvious question is that why do you want to store a users role in session ?
Here is my answer to your query, how this helps. I have attached a small demo application for you to take a look at and understand my points. When you open this project in visual studio, click on the project tab on the top and select asp.net configuration. From the page that will show up you can do the user administration stuff.
You need to store the roles of a user in some secure manner ? The answer to this question is that there is no need for you to worry about storing the role for any user, when we have the asp.net membership, profiles and roles framework to help us out on this. All you need to do is create a role in the aspnet database and assign that role to the user.
Next you want to store two string in some secure manner. I suggest you user profile for storing user specific information. This way you have the information available to you where ever you want from the profilecommon class.
Also please see the attached demo application placed at the end of my blog http://blogs.bootcampedu.com/blog/post/Reply-to-httpstackoverflowcomquestions1672007user-roles-why-not-store-in-session.aspx
Just a suggestion, you might consider using this little library:
http://www.codeproject.com/KB/aspnet/Univar.aspx
It has a server side implementation of the cookie whereby all cookies can be stored on the server while asp.net authentification is used to identify the user. It supports encryption and is also very flexible making it very easy to switch from one storage type to another.
I have been struggling with a following problem. I have an ASP.NET application that has a certain search engine. It is possible to perform the searching by using prepared links. So I have a MS Word document that contains the links. When I click such a link a new IE8 window is opened, an ASP.NET session is spawned, the searching is performed and some results are displayed in the browser and stored in the session. Now when I send a new request by clicking something in the newly opened page a new session is spawned once again, thus the previously stored results are inaccessible.
I would appreciate any suggestions how to handle this.
Best regards,
B.
Maybe you use cookieless sessions?
You can also consider to use Cache instead of Session so different users can share the same search results for better performance.
Borat,
When you click a link in word document, each link opens in a NEW instance ** of IE window which creates a **new session. Because of this you are unable to access the previously searched results.
Inorder to solve this problem, try to create the persistent cookies on client side and store the searched queries in this persistent cookie. These persistent cookies are created locally on the client computer. By doing this all browser windows will be able to access the same persistent cookie.
Hope this will solve the issue....
Thanks
Depends on how you're handling sessions. Most likely, you're using SessionID cookies and the client is rejecting cookies. (Or at least not persisting the cookies between the two requests for whatever reason).
you cannot have same sessions inside multiple browser instances. implement a cookie based approach where you maintain your search result sets based on cookie. also doing anything in sessions is a bad practice in asp.net
I have two web applications and sometimes I need user to jump from one application to another. Since they are two web applications and may reside on different domains/machines, I can not share session between them.
The technical challenge for me is how to pass session information (I only need to pass userID string information in the session) from one source application to another destination application -- so that the user feels Single Sign On and personal information is displayed for him/her in both application (as the userID is passed to the destination application, no re-login is needed).
My current solution is generate all URL strings in both application and append them with user ID after user logins successfully, like http://www.anotherapplication.com/somepage?userID=someuserID, the userID value is retrieved from session. But I think my solution is stupid and I want to find some way to automatically append the query string ?userID=someuserID when the user jumps to another URL in another application -- so that I just need to generate the common unified URL http://www.anotherapplication.com/somepage in both application.
Is there a solution to automatically append the userID query string?
thanks in advance,
George
Rather than doing it via the Querystring, it might be more maintainable in the long run if you use create a FormsAuthenticationTicket with the required values.
I especially recommend reading Michael Morozov's excellent article on the subject of SSO (Single sign ons).
I do not think it is a good idea to have the user id in query string.
A better idea would be to implement a single-sign on solution. In your scenario, you could do the following:
Whenever one of your applications receive an unauthenticated request, redirect the user back to the other application to a special single-sign-on url.
This page checks whether the user is logged in, and if so, redirects back with an authentication token in querystring.
This token is checked by the un-authenticated application; and if it passes, you can login the user.
Of course, this seems like "a lot" of redirecting, but it should be reliable, and it only happens once, and then your user will be authenticated on both applications.
Obviously you would need to implement a security scheme so that you can check that the authentication token you get passed is really valid and originating from your other application. You could do this with a challenge-response algorithm; which could be:
Both applications should know a common key.
First application sends some random data (the "challenge") to the second application.
The second application includes a hash-value of the random data + it's answer + the secret key in its response.
Now the first application can check that the second application knew the secret key by calculating the same hash-value.
Have a look at:
http://en.wikipedia.org/wiki/Challenge-response_authentication
EDIT:
With regards to session state, see http://msdn.microsoft.com/en-us/library/ms178581.aspx for an overview. It is possible to share session state between the applications, but I would not recommend it in general. If your application resides on different domains (URLs) you would have to use cookieless session state; which is not safe. If you decide to go this way, you would either have to use State server or SQL Server for session persistence, depending on your setup.
You can persist the session using something else than InProc (which is short for in process). If you persist the session using a SQL Server backend you'll be able to retrive the session cross domain/machine if they are setup to use the same SQL Server backend for session storage. This is configurable in ASP.NET and support out-of-the-box. I suggest you look it up.