WKWebsiteDataStore.default().httpCookieStore.getAllCookies returns a different list of cookies from HTTPCookieStorage.shared.cookies. What is the difference between these two methods?
HTTPCookieStorage.shared will be used with URLSession.shared network requests.
WKWebsiteDataStore.default() is used for WKWebView only. And the getAllCookies is asynchronous
Both are persistent.
The accepted answer is not entirely correct. Persistent cookies are shared between HTTPCookieStorage.shared and WKWebsiteDataStore.default(), though the sharing is not always immediate. Session cookies are not shared. This behavior doesn't seem to be documented by Apple anywhere, but is clearly evident if you run some tests. See this long thread for some related discussion:
Getting all cookies from WKWebView
Related
I have an application where a container app loads site <inner-site>.com in an iframe. All the ajax calls in the iframe fails due to bad request. This was due to ajax calls not having _csrf cookie in the request. For some reason, iframe doesn't have the identity cookies at-all.
Problem mentioned here: https://gist.github.com/iansltx/18caf551baaa60b79206 and the proposed solution was to remove the same-site requirement for identity cookies. That didn't sound like a good plan.
Then, I found more elegant way to share cookies between sites here: https://gist.github.com/iansltx/18caf551baaa60b79206
I liked the solution since the client and server work together and I could limit who to trust from <inner-site>.
This solution also worked on localhost which was awesome since we have been trying to fix this issue for weeks by now.
However, after deploying the change to the prod, it no longer worked. Not sure what might be causing this issue or if the limitations were more relaxed in localhost that it worked fine.
I'm looking for help figuring out either
why the solution above didn't work for the real server
or if there's another solution for this problem.
I'm using Yii2 but any solution should be applicable. Mentioned Yii2 to see if it might be enforcing some extra limitation or if it has some utility to fix this issue easier.
I was wondering if the SameSite flag on the session cookie was enough of a protection against CSRF attacks.
I see CSRF token solution everywhere, but I am not sure about the need to use a CSRF token if the cookie used for authentication is already protected by the SameSite flag (in Strict mode).
On top of that, if I understood it well, tho cookie would still be sent along with subdomain URLs like api.myapp.com which would be perfect for my needs.
This is somewhat opinionated, or at least depends on your target audience and risk appetite.
SameSite=strict is supported in almost all fairly recent browsers as seen here, but note the exception of IE11. Not many people use IE11 anymore, but for them it will not be good enough. Only you can answer whether that's good enough for your usecase, as of writing this, a significant amount of users would not be protected.
Also the general consensus seems to be that SameSite should only be used as defense in depth (eg. here or here in a similar question), but most of the concern is around Lax, and less about Strict. However, Strict is very user-unfriendly, in a real-world application you probably can't really use Strict, because that's very bad UX.
The usual arguments are around browser support (as above), GET requests changing state (only relevant to Lax), and some special cases still revolving around GET changing state.
So my take currently is that the reason SameSite=Strict is not good enough in general is the lack of full browser support (IE11), and a strong point against it is bad user experience. I can imagine circumstances where it is good enough. SameSite=Lax I think is only a defense in depth measure, because of the issues above, which probably don't affect your application now, but might in the future, and nobody will remember to think about SameSite settings.
Excellent answer from Gabor which explains the problem well. There is a way to solve this though, if you set up your code like an SPA, to work like this:
Requests for web content (such as navigation) do not require a cookie
The SameSite=strict cookie is only used in Ajax requests to get data
HOW IT WORKS
If your web app runs at https://mywebapp.com
Then issue the secure cookie as the result of calling an API at https://api.mywebapp.com
The cookie has a domain of .mywebapp.com and is SameSite + Cross Origin
OAUTH
For an OAuth back end for front end solution you would do this:
Host the API at https://api.mywebapp.com
When the web app receives an OAuth response, it sends the Authorization Code to the API
The API processes it, then issues a strongly encrypted cookie containing tokens
So, recently I ran a security scan on a webpage. In one suggestion, it said "Caching Https Response" for image/js/font files, which seems counterintuitive. And this suggestion seems to be the consensus among different security products.
https://portswigger.net/kb/issues/00700100_cacheable-https-response
https://www.valencynetworks.com/kb/cacheable-https-response.html
https://support.microfocus.com/kb/doc.php?id=7009057
So, why does caching static files matter in HTTP or HTTPS mode? I thought modern practice is make everything HTTPS to avoid tampering, and browser-caching to avoid extra download.
Lastly, if we WANT to cache static content in HTTPS mode, what is the correct thing to do? Add extra logic to make it call HTTP instead? That seems like a terrible idea.
That is a warning, designed to protect people from unknowingly allowing private responses to be cached. Those descriptions all say some variation of "If sensitive information is stored in the cache...". Note the "If".
If you are knowingly allowing the content to be cached, then there's no problem. I assume the tool is showing this only on secure requests because of a presumption that such information might be sensitive.
I did a small sample test and found that almost all web sites I tested suffer from the vulnerability where I can access restricted pages (ie pages that require logging in) even after I have logged out from the browser if I save the cookies while I am still logged on.
The test was fairly simple. I just replayed a web request in Fiddler after I had logged out from the browser. For example, with outlook.com, after logging out, I could replay the page that shows the address book and still get my contacts' email addresses.
May I know what the industry standard is regarding this as I have one customer who insists on fixing this vulnerability but not wanting to increase the hardware specs.
I'm not sure if there's an industry standard, but there are best practices. And the best practice is to clean the cookies, and cookie management.
You shouldn't have to worry about hardware on this either. It's a simple lookup to see if a value is valid. If it isn't, then the session state shouldn't get resurrected.
Again, I would use HttpOnly and a secure flag on the cookie. That way, it will limit replay attacks more. And when it comes to resurrecting sessions, make sure that session files are destroyed on the server, not just abandoned.
Abandoned sessions mean they can potentially be resurrected.
Hardware will generally not be an issue with this problem. If it is, then look at your solution, as there might be a better way.
We're evaluating ServiceStack and have found that all example hosts only allow a single request to be processed at a time. If you add a Debug.WriteLine and Thread.Sleep to any entry point, this is easy to see.
I'm assuming we're either missing some setting or are missing a pretty big point with how ServiceStack should be used.
Thanks,
Ross
This actually was a mistake in how we were testing ServiceStack. We were using the same browser but separate tabs/windows, which actually blocks itself from making concurrent requests. Once using two different browsers (e.g. IE and Chrome), we were able to witnesse ServiceStack handling two requests at the same time.