I've turned off { webSecurity: false } from webPreferences
There's a site I'm doing a HTTP request and its returning me some cookies to be set.
But the issue is the cookie has some policies which is preventing to set.
This Set-Cookie header didn't specify a "SameSite" attribute and was defaulted to "SameSite-Lax," and was blocked because it came from a cross-site response which was not the response to a top-level navigation. The Set-Cookie had to have been set with "SameSite=None" to enable cross-site usage.
How do I disable all cookie related security policies on electron (Chromium).
Related
I built a Chrome extension that saves web content to my Rails app. Originally I was able to rely on the existing Rails/Devise user session to ensure content was being saved to the right user, as long as the CORS settings were opened up on my API controller (see code below). As long as the user was logged in, AJAX calls to my site from the Chrome extension were being authenticated correctly, no matter what site the extension was being used on.
However, in early 2020 Chrome introduced changes to how they they handle cross-site requests (see here, here, and here). Specifically, a cookie's SameSite attribute would now default to 'Lax' instead of 'None', and so to use a cross-site cookie, the cookie setting would need to be explicitly set to SameSite=None; Secure.
Rails' own user session cookie does not have the SameSite=None; Secure settings, and so using the Rails session to authenticate my Chrome extension's request was no longer an option.
My fix was to generate my own API authentication cookie whenever the user logged into the app, which did have the necessary SameSite=None; Secure applied. I was able to authenticate API calls from my Chrome extension using this cookie, and all was well.
And then in early September 2020 it suddenly stopped working. Rails no longer reads the cross-site cookie from Chrome extension requests. There's no error or warning, the value is just null.
API Controller:
# This gets called when user logs into app:
def set_cross_site_cookie
# NOTE: Won't work in dev because secure = true
cookies[:foo_cookie] = {
value: 'bar',
expires: 1.year.from_now,
same_site: :none, # Required in order to access from Chrome extension on different site
secure: true # Required in order to access from Chrome extension on different site
}
cookie = cookies[:foo_cookie]
render json: {cookie: cookie}
end
# This SHOULD work when called from our Chrome extension:
def get_cross_site_cookie
# Add headers to allow CORS requests
# SEE: http://stackoverflow.com/questions/298745/how-do-i-send-a-cross-domain-post-request-via-javascript
response.headers['Access-Control-Allow-Origin'] = '*'
response.headers['Access-Control-Request-Method'] = %w{GET POST OPTIONS}.join(",")
cookie = cookies[:foo_cookie]
render json: {cookie: cookie}
end
Rails 5, Rack 2.1
(NOTE: In order to set Rails cookies with option same_site: none you apparently need need to be on a rack version that's higher than 2.1.0 - SEE: https://github.com/rails/rails/pull/28297#issuecomment-600566751)
Anybody know what happened?
I still don't know why the cross-site cookies suddenly stopped working, but here's how I hacked around it:
The workaround was to use the Chrome extension cookie API to read my Rails API authentication cookies into Chrome's local storage. Since we can enable access to cookies of any specific site in the extension manifest, it actually doesn't matter whether they're cross-site cookies or not.
Once the API cookie would get read into storage, we could then pass it along as an auth token with every request, basically using it as a pseudo-cookie.
So the full flow is that the user clicks the extension button, the extension reads in the API authentication cookies based on the explicit cookie permissions it has for that domain, and if the cookie is missing or outdated, it forces the user to log in. If the cookie is valid, it is passed as an auth token in the params or headers of every API call.
SIDENOTE ON PRE-FLIGHT OPTIONS REQUESTS:
You may also have to deal with the OPTIONS pre-flight requests that will be sent with certain cross-site AJAX (I think it's only an issue with content-type JSON POSTS but don't quote me), as they'll trigger an ActionController::RoutingError (No route matches [OPTIONS]) error in Rails. The recommended answer was to use the rack-cors gem, which indeed solved the issue.
SEE:
Why is an OPTIONS request sent and can I disable it - Stack Overflow ***
How to respond to OPTIONS HTTP Method in rails-api - Stack Overflow
Rails Responds with 404 on CORS Preflight Options Request - Stack Overflow
Perform HTTP OPTIONS request from Rails 5 for CORS pre-flight or otherwise - Stack Overflow
We are using a web application developed in ASP.NET MVC (SiteA), which accepts post request from other site call SiteB. But while posting request from SiteB to SiteA, we are getting following error of SameSite Cookie for Aspnet_sessionId. Here both SiteA and SiteB are hosted on different domain.
"A cookie associated with a cross-site resource at http://siteA.com/ was set without the SameSite attribute. It has been blocked, as Chrome now only delivers cookies with cross-site requests if they are set with SameSite=None and Secure."
I can resolve this issue by setting SameSite=None and Secure for SiteA Cookies. But instead of setting these value, Can I do using content security policy from SiteA ?
I'm developing an app that logs into a HTTPS website. After authentication, the website sends a final cookie that is marked as 'Secure'.
The app works when I use defaultSessionConfiguration() for NSURLSession().
When I change one line in the app to use the backgroundSessionConfigurationWithIdentifier() then I can't proceed past the authentication stage. I do get a webpage showing that I am authenticated but subsequent requests return the login page.
It appears that the "authentication successful cookie" is not present in the shared cookie storage.
This cookie is the only cookie that the website marks as "Secure". Note that this HTTPS website does all it transactions via HTTPS.
TL;DR
What does the NSURLSession background session do differently from the default session to lose a Secure cookie??
EDIT: I've done some more work.
When NSURLSession redirects using the backgroundSessionConfiguration it appears to ignore cookies that were sent in the Header of the redirect? (I think the cookie being "Secure" may not be critical.)
The redirect works correctly when the defaultSessionConfiguration is specified.
It turns out that this is a known bug. Apple r. 16,852,027.
The backgroundSession is known to ignore new cookies on redirect. The solution is to use a defaultSession to get the cookies and then continue using backgroundSession.
See Apple Developer Forum post
In the server response, I am adding the "secure" flag to all cookies by placing the following line within the web.config:
<system.web>
<httpCookies requireSSL="true" />
</system.web>
This seems to work since the ASP.NET_SessionId cookie shows the "secure" flag in the response:
However, when I perform an action on the page and check the Dev Tools again, I noticed that the very same cookie no longer has the "secure" flag in the client request:
I am using Internet Explorer 11 developer tools to view the Network.
Should the session cookie contain the "secure" flag in the client's request? If not, are there any security implications of having an "insecure" request cookie?
After spending some time looking into it, I did not find any code in my application that was altering the cookies or the "secure" flag on the cookies. Any information on the matter will be appreciated.
I'm trying to set the session cookie secure flag to true. I added the following to my environments/production.rb
ActionController::Base.session_options[:secure] = true
In the production mode I don't see the set-cookie header in the server response (I'm using the Tamper Data Firefox tool to view the traffic). I tried removing all cookies, manually setting the domain including the child domain(since domain is shared among many applications, the appache server forwards the requests to the right application and thus the request is always received by the application server as if it's coming from localhost).
I also tried to test it in development mode, I assume the server should at least set the cookie even if the request is over http but the browser won't send the cookie over http but again the server does not send the set-cookie header. The session works just fine if I don't set the secure flag. Am I missing something here?
I found out that in my version of actionpack, session cookies are only set over ssl.
Although by definition, the server can set a secure cookie when the request is over http but the browser will not send it with further requests. In my application I don't enforce ssl on the app level but on the appache level instead so the initial request made by rails is over http and the cookie is not set.