Summary of problem: I am using MKNetworkKit and use Basic Auth to authenticate myself against a REST server. I am no expert on the detail setup on the server side. All I know is that it will take a Basic Auth without SSL.
If I authenticate myself with a valid user/password, and if I do so 2nd time with some bogus input, it will still succeed. I read documentation and tried to do this:
[op setCredentialPersistence:NSURLCredentialPersistenceNone];
it doesnt work. But if i do this:
[op setCredentialPersistence:NSURLCredentialPersistenceNone];
[op addHeader:#"Cookie" withValue:#""]; // a hunch I tried
then it seemed to work. It is as if some cookie is always being passed and the server accepts it without even checking the authorization header. I have done a few test where I will provide things in this order (good, bogus, good), and (bogus, good, bogus), and it seemed to be working as expected.
Now, could someone point out if this is not how things should work, that there must be a bug somewhere, either MKNetworkKit, or the server side? If I set NSURLCredentialPersistenceNone, then why would adding that Cookie header will make it work?? it must have overwritten the thing it would have sent and caused the wrong behavior, and thus "fixed" it.
Due to the stateless nature of the HTTP protocol, clients often use cookies to provide persistent storage of data across URL requests. The URL loading system provides interfaces to create and manage cookies, to send cookies as part of an HTTP request, and to receive cookies when interpreting a web server’s response.
OS X and iOS provide the NSHTTPCookieStorage class, which in turn provides the interface for managing a collection of NSHTTPCookie objects. In OS X, cookie storage is shared across all apps; in iOS, cookie storage is per-app.(check https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/URLLoadingSystem/URLLoadingSystem.html#//apple_ref/doc/uid/10000165-BCICJDHA) As stated by Moxy Try to log [[NSHTTPCookieStorage sharedHTTPCookieStorage] cookies].I was facing the same issue and reason was cookies were used and maintained by the server.As redirection was taking place whenever i logged in using the credentials i checked the request and response in
(NSURLRequest )connection: (NSURLConnection)inConnection
willSendRequest: (NSURLRequest*)inRequest
redirectResponse: (NSURLResponse*)inRedirectResponse
And cookies were maintained in the headers.The only thing you can do is sending a random cookie for a new session
Related
Can we restrict from storing cookies in sharedHTTPCookieStorage by default?
I am using other approach for session authentication and don't want cookies to be sent to server on each server request. Currently I read all cookies from sharedHTTPCookieStorage and delete them manually after Login.
It would be better if they are not set automatically by default at first place.
I'm not an expert on this. But I worked on some apps that need to cache zero to none info for security reasons.
I think that you could go with a combined approach.
Defining a no-caching policy to responses, on NSCachedURLResponse and also intercepting calls with your own NSURLProtocol.
Here's some info on the whole URL Loading system on iOS
I hope it helps a little! Good luck!
Question #1:
Is setAuthCookie any less safe than FormsAuthentication.Encrypt(ticketVariable)?
I mean if anyone tries to modify the cookie created by setAuthCookie, by modifying the username, I suppose that'll violate the authentication on subsequent calls?
Question #2:
for those using iphones and tablets to access the site, I suppose FormsAuthentication will fail? Given that I don't want to use cookieless option, is there another approach to make the site secure on both smart phones web browsers and ummm none-smartphone web browsers?
cheers
SetAuthCookie basically creates a new FormsAuthenticationTicket with the supplied username & persistence options, serializes it, FormsAuthentication.Encrypt()'s it, and sets it in the Response.Cookies collection. SetAuthCookie and GetAuthCookie both call FormsAuthentication.Encrypt indirectly.
On subsequent requests, the FormsAuthentiationModule handles the AuthenticateRequest event. If it sees a cookie (it may have expired), it attempts to decrypt it's value with the machineKey (it may have been tampered with) and deserialize it back into a FormsAuthenticationTicket (it may be corrupt). If none of that (bad stuff) happens, the ticket contains the username, issue date, expiration info, etc.. If the ticket hasn't expired, an IIdentity and IPrincipal are created and assigned to HttpContext.Current.User and Thread.CurrentThread.Principal. In .NET 4.5 and later (I think), this is Claims-based (ClaimsIdentity, ClaimsPrincipal). Prior to that, it was a (GenericPrincipal, FormsIdentity) I think.
Any tampering at all on the user side will cause the request to be treated as anonymous. It will fail to decrypt. The only things that would compromise this validation would be if the machineKey in web.config/machine.config somehow got into the hands of an attacker or if there was a bug in the framework code (search for Padding Oracle for a historical example of this).
Aside from that, the other thing to watch out for would be session hijacking. If someone steals your cookie on a public wifi for example, they can present it to the server and the server will behave as if it's you. This generally involves network traffic sniffing. For these reasons, best practice is to use SSL for your entire site and set the cookie to HTTP only and Secure (only presented over https connections) in web.config/system.web/authorization/forms. HTTP only means that it will not be available to client-side Javascript. HTTP Only and Secure effectively means HTTPS only. This will only work if you use SSL on your entire site.
FormsAuthentication will work fine on mobile web browsers. It simply requires the client to accept cookies. As far as I know, all mobile devices will allow this.
Here's a really simple question. I just ran into an error where I needed to clear a cookie manually.
What happened was, I'm using the GTMOAuth2 library for authentication. This library presents a web-view to collect user credentials. And then all subsequent requests are done via regular HTTP, where we add the received oauth token into the header.
My colleague working on the back-end told me that one of these subsequent non-UIWebView requests asks me to clear the header. Of course for the web-client this would just work, but not on mobile.
For HTTP, I'm using the nice light-weight BBHTTP library - a little objective-C wrapper for cURL. So this got me thinking: Do regular, vanila NSURLRequests have seam-less Cookie integration, or would I have the same behvior where I need to clear the cookie manually there too?
Dart HttpServer.listen returns an HttpRequest. There is also a timeout associated with the server which controls how long the HttpRequest remains active. How does the HttpServer identify what has generated the request (for retrieval), and how does it store the requests, and why does it save them?
In the situation that I encountered, accessing the same server from different tabbed pages of the browser used the same server request. If different browsers were used however, it appears that different requests are created. Is it possible to force the server to create different requests for tabbed pages?
I believe that your question mixes requests and sessions. If I misunderstood it, please ignore.
The timeout associated with the HttpServer (I assume you mean HttpServer.sessionTimeout) controls the lifetime of the session, not the request.
The sessions are based on cookies. The server writes session identifier into a cookie. This cookie is then used in communication between browser and server, so server checks the cookie, an gives you the appropriate session to use. This is a typical implementation, some frameworks allow storing the whole session in the cookie, but that has many drawbacks, I won't go into. Dart's HttpSession is just an in-memory map, which is internally mapped to the session cookie value.
Since browser tabs (at least for most of the browsers, I am not an expert on that) share the cookies, request done from any tab to the same domain will result in the same session being used. Naturally, another browser uses its own cookie store, so you have different session there.
This problem is sometimes solved by encoding the session ID in the URL (google for 'URL encoded session IDs' as implementations are specific for the chosen backend), but I don't see any supported way to plug that approach into HttpServer class. The session creation is implemented in _HttpSessionManager type which is private to dart:io library, and doesn't provide any public extension points, so you would most likely need to wrap your own support.
I'm an old hand at C but a raw newbie at Java/Tomcat.
I'm fine with Tomcat session management in http alone. Its when I've come to look at switching to https that I've had problems.
I gather for Tomcat that you have to start with an http session if you want to maintain a session as you switch from http to https and back to http. This works fine for me when the browser is enabled for cookies.
But when the browser is disabled for cookies (and URL rewriting is being used) then switching http to https or back again causes a fresh session to be started each time. I'm assuming this is a security thing.
Q1 - Is it possible/desirable to maintain a session between http and https using URL rewriting?
Q2 - If it isnt possible then what do e-commerce developers do about non-cookie users?
I dont want to prevent non-cookie people using my site. I do want some flexibility switching between http and https.
thanks for any help,
Steven.
It doesn't seem desirable to maintain session between HTTP and HTTPS using the same cookie or URL token.
Imagine the case where you're user is logged on, with a given cookie (or URL token) passed back and forth for every request/response in an e-commerce website. If someone in the middle is able to read that cookie, he can then log on to the HTTP or HTTPS variant of the site with it. Even if whatever the legitimate user is then doing is over HTTPS, the attacker will still be able to access that session (because he too will have the legitimate cookie). He could see pages like the cart, the payment method, perhaps change the delivery address.
It makes sense to pass some form of token between the HTTP session and the HTTPS session (if you're using sessions), but treating them as one and the same would cause some vulnerability. Creating a one-off token in the query parameter just the transition could be a solution. You should however treat them as two separate authenticated sessions.
This vulnerability can happen sometimes with websites that use mixed HTTP and HTTPS content (certain browsers such as Firefox will give you a warning when that happens, although most people tend to disable it the first time it pops up). You could have your HTTPS session cookie for the main page, but that page contains images for the company logo, over plain HTTP. Unfortunately, the browser would send the cookie for both (so the attacker would be able the cookie then). I've seen it happen, even if the image in question wasn't even there (the browser would send the request with the cookie to the server, even if it returned a 404 not found).