I'm using the AFNetworking Framework for iOS. I've subclassed AFHttpClient and are using it as a singleton, i.e. [TestAFClient sharedClient]
I'm consuming an ASP.NET Web Service API that requires the use of the .ASPXAUTH cookie. First I have to authenticate, receive the .ASPXAUTH cookie in response, and then must pass this cookie with each subsequent request.
After a few tests, it appears that, because I'm using a singleton AFHTTPClient, the .ASPXAuth cookie persists and, thus, no explicit storage of the cookie is required.
However, as part of my App, I need to "logout" at some point.
What is the most efficient way to clear this cookie, in order to logout? Set the singleton to nil and re-initialize it? Do something like setValue:forKey:?
Additionally, is it better that I explicitly store the .ASPXAUTH cookie? And does this expire or automatically renew if necessary?
Thanks,
Robby
Cookies are actually handled by the underlying URL-loading system, similar to the way cacheing is handled automatically by NSURLCache. For [NSHTTPCookieStorage sharedHTTPCookieStorage], you'll want to find the cookie at your baseURL, and then delete it. You can explicitly set or modify an existing cookie in the same way.
Related
When using WIF, the client is able to set the persistentCookiesOnPassiveRedirects which by default is false. Here is the provided definition:
persistentCookiesOnPassiveRedirects: Specifies whether persistent
cookies are issued when the module is enabled to initiate
WS-Federation passive protocol redirects. A persistent cookie will
outlast user sessions.
OK that sounds clear, but I still do not get it and changing the value between true/fasle does not seem to make any difference. Does it have anything to do about pulling up another site in a separate browser that trusts the same STS provider and making it so the user does not have to log in again?
I suppose an example of a site and STS working together would be really helpful to explain exactly what this setting does. Thanks!
It means that the FedAuth cookies issued by WIF will be persistent (as opposed to tied to a user session). If you close the browser and open it again, the cookies will still be sent to your site and token negotiation will not happen (you will not be redirected to the STS).
If it is false, each time you close the browser and open it again the negotiation will be triggered, because there's no token anymore. (Cookies is where WIF stores the information of the security token).
Notice that the STS itself will also issue cookies (different from your app) and those might be persistent, so the actual authentication might not happen the second time even if you set the flag to false.
Notice also that WIF can optionally store the information it needs somewhere else (server side).
Last but not least, the token might expire, in that case the negotiation will be triggered regardless of the flag.
In asp.net, I am able to login using forms authentication as usual, copy our auth cookie value, log out, add the cookie artificially to the client using the 'Edit This Cookie' addon for Chrome, refresh the (anonymous) landing page and hey presto i'm logged in again. This seems to be a vulnerability - is there any way of fixing it using the the standard forms auth or will I have to do something like use a custom Authorize attribute which overrides the existing one in asp.net mvc?
I don't think this is a bug per se. The following happens during forms authentication
You provide a username/password to the server
Server validates username/password
If valid, the server then sends an encrypted authentication ticket (cookie) to the client with the expiration time (set in the web.config forms authentication section) and username (all encrypted)
On each request that requires authorization, the cookie is decrypted on the server, expiration time is checked and username is used to see if authorized (or getting that role for the requested resource).
When you logout, the expiration time on the cookie is set in the past, therefore, it is not longer a valid cookie
Now, as to why you are seeing what you are seeing... You are copying the cookie before you logout. Thus your copied cookie never registers the logout (moved expiration time). When you reattach, you still have a valid auth cookie. Now, if your forms authentication timeout is set to...let's say 20 minutes...this method would fail if you copy the cookie and wait 21 minutes as by that time, it has expired.
Cookies are always vulerable and we can't do much about that. What we can do is prevent someone from stealing the cookies.
Regarding ASP.NET MVC it does a good job to avoid stealing cookies. Some of the main things it does by default as part of security are:
Encode the strings that are rendered to the view (if you are using Razor don't know about others) to prevent from XSS attacks.
Request validation (stop potentially dangerous data ever reaching the
application).
Preventing GET access for JSON data.
Preventing CSRF Using the Antiforgery Helpers
Regarding cookies Microsoft provides HttpOnly feature and this helps to hide the cookies from javascript. The Forms authentication that you are talking about is a HttpOnly cookie means someone can't steal that through JavaScript and it's more safe.
You can do that with any cookie/s. You can inspect/copy all the cookies from any given domain, and spoof if you want. You can do that to yourself (only) because its your PC (or user logged in to PC). Obviously if you're on a shared PC, that is a problem (across all your info).
The act of "copying your cookie" is in fact one way malware attempts to steal/hijack your identity (or current session on some web site). That said, unless you have some malware, you can't just "copy cookies" of someone else.
Assuming logout is done, you can ask users to close their browsers so the expired cookie is removed from the (file) system.
Ignore for the moment that not all browsers support LocalStorage.
Would it be possible to roll your own authentication "handler" (for want of a better word) that makes use of LocalStorage rather than a Cookie for FormsAuthentication within an ASP.NET web app?
If it is possible where would I find the best information to start learning how to do it?
Generally, your authentication happens at the server end and cookie contents are passed along with every request. So, by using the information available in request before accessing the resource, server can see if the user is logged in.
But, in case of localStorage the contents are not passed to the server with every request and is accessible only to Javascript. Hence it is not possible to use localStorage for authentication instead of cookie.
I'm using ASP.NET MVC2 and I need to save user login status to indicate if he is logged in and show some private data.
What I did was just add UserID in session Session.Add("UserID", user.ID.ToString()); and then redirected to user page that is getting UserID string userID = Session["UserID"].ToString(); and if it exists pull out data from DB and show it to user.
As far as I know Session data is stored on server-side so my first thought is that it is pretty safe to use this method. However I checked in Chrome and it is creating some kind of cookie which makes me doubt.
Can someone tell me if this method is safe?
The cookie that is being created (a) is encrypted and (b) does not contain the actual data, but rather a session identifier used to retrieve the proper session for the thread handling the request. It's a perfectly reasonable and secure way to save the data. I believe that the cookie is HttpOnly by default (you should verify this) and shouldn't be exposed to scripts in the browser. If it isn't HttpOnly, you should configure it to be so (using the httpCookies directive) - best practice would dictate that cookies should be HttpOnly unless specifically required for use by the client directly.
ASP .NET MVC maintains session state by providing the client with a unique key (session id) when the session begins, that is stored in an HTTP cookie. Session id is sent to the server on each request.
You can set
<system.web>
<sessionState cookieless="true" />
</system.web>
then session id would be passed in url, that is less secure
You can encript cookie. It is perfectly ok by the way. For example when using Federated Authentication your SAML(or other) token is stored in encripted cookie.
Even if someone intercepts your cookie, he cant read it. To prevent data corruption - sign them. Also you can add cookie owner URI to it and validate it.
Quite same as tvanfosson opinion. Just noticed it=) But will post anyway.
For various reasons I am fed up with ASP.NET session state and I'm trying to do it myself (separate question coming soon related to why I'm fed up and whether it's feasible to do it myself, but for now let's assume that it is).
Security concerns aside, it seems like tracking sessions involves little more than storing a cookie with a guid and associating that guid with a small "sessions" table in the database, which is keyed on the guid and contains a small number of fields to track timeout and to link to the primary key in the user's table, for those sessions that are linked to registered users.
But I'm stuck on a detail with the cookie, in the case the user's browser is not set to accept cookies. It seems to me that each time a user accesses any page that has session state enabled, ASP.NET must determine whether the browser supports cookies. If there already is a session cookie sent with the request, obviously it knows cookies are accepted.
If not, it seems like it needs to check, which as I understand it involves trying to write a cookie and redirecting to a page that tries to read the cookie. So it seems, when a user with cookies turned off visits several pages of a site, that ASP.NET
(a) has to do this round-trip test for every page the user visits, or
(b) has to assume the browser accepts cookies and create a record with a (provisional) session id for the user on each page -- and if session state is supposed to be persistent, it seems it has to write that initial session id to the database on each page.
But (a) sounds crazy and (b) sounds crazy also, since we would quickly accumulate session ids for all these single-page sessions. So I'm thinking there must be some other trick/heuristic that is used to know when to do the round-trip test and/or when to actually create a record for the session.
Am I wrong to be perplexed?
(To be clear, I'm not talking about implementing a custom storage solution within ASP.NET's pluggable session state system. I'm talking about skipping ASP.NET's session state system entirely. My question is a more detailed version of this one: Implementing own Session Management in ASP.NET.)
Session behaviour is set through the sessionState element in web.config. In the sessionState element the HttpCookieMode can be set to one of UseUri, UseCookies, AutoDetect, UseDeviceProfile.
UseUri and UseCookies tell ASP.NET explicitly how to handle storing the session identifier. If UseDeviceProfile is used then the behavior is determined by whether the user agent supports cookies (not whether they are enabled or not).
AutoDetect is the interesting case that you are interested in. How ASP.NET is handling the auto detection is explained in Understand How the ASP.NET Cookieless Feature Works. In that article you will see that they have 5 different checks they do. One of the checks is, as you mention, to set a cookie and do a redirect to see if the cookie exists. If the cookie exists, then the browser supports cookies and the sessionID cookie is set. However, this is not done on every request because another check they do before tring to redirect is is check to for the existence of any cookies. Since after the initial set-cookie and redirect the sessionID cookie will be set then the existence of the cookie lets ASP.NET know that cookies are supported and no further set-cookie and redirects are required.
Well, cookies are a standard mechanism of web authentication. Do you have any reason at all why you wouldn't want to use them? Are you sure you're not trying to invent a problem where there isn't any problem?
Most serious websites I know of require the browser to accept cookies in order for the user to be authenticated. It's safe to assume that every modern browser supports them.
There's an interesting article about cookieless ASP.NET that you should read.
EDIT:
#o.k.w: By default the session state is kept by ASP.NET in-process (read: in memory). Unless told explicitly by the configuration to store the session in the database (SQL Server is supported out-of-the-box), this won't result in a database hit. The stale session states will get purged from the in-process storage. Unfortunately, with default ASP.NET settings every cookieless request will result in a new session being created.
Here's a detailed comparison of available session storage options: http://msdn.microsoft.com/en-us/library/ms178586.aspx.