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 ?
Related
I'm working on an application using OAuth2.0 for Quickbooks. I'm basing my code on the example provided by intuit. Here I have looked a bit on the "state" parameter of the oauthClient.authorizeUri.
oauthClient = new OAuthClient({
clientId: req.query.json.clientId,
clientSecret: req.query.json.clientSecret,
environment: req.query.json.environment,
redirectUri: req.query.json.redirectUri,
});
OAuthClient;
var authUri = oauthClient.authorizeUri({
scope: [OAuthClient.scopes.Accounting],
state: "userid:1234", //Encoded as a JWT
});
res.send(authUri);
});
I was thinking of encoding an internal user- and projectid in the state through a JWT only for this purpose. I need it for the callback to make sure that I'm connecting the right internal user with the QB token.
I have two questions here:
Is it "safe" to encode an internal userid in the "state" like that? Or is there a better way of doing what I want? I'm working with a distributed service (GCP CloudRun), so it might not be the same instance receiving the callback as the one that created the authUri.
I'm not an expert here, but a read of the spec seems to indicate this should not be a guessable value like user_id would be.
From the spec ( https://datatracker.ietf.org/doc/html/rfc6749#page-26 ):
state
RECOMMENDED. An opaque value used by the client to maintain
state between the request and callback. The authorization
server includes this value when redirecting the user-agent back
to the client. The parameter SHOULD be used for preventing
cross-site request forgery as described in Section 10.12.
and:
10.12. Cross-Site Request Forgery
Cross-site request forgery (CSRF) is an exploit in which an attacker
causes the user-agent of a victim end-user to follow a malicious URI
(e.g., provided to the user-agent as a misleading link, image, or
redirection) to a trusting server (usually established via the
presence of a valid session cookie).
A CSRF attack against the client's redirection URI allows an attacker
to inject its own authorization code or access token, which can
result in the client using an access token associated with the
attacker's protected resources rather than the victim's (e.g., save
the victim's bank account information to a protected resource
controlled by the attacker).
The client MUST implement CSRF protection for its redirection URI.
This is typically accomplished by requiring any request sent to the
redirection URI endpoint to include a value that binds the request to
the user-agent's authenticated state (e.g., a hash of the session
cookie used to authenticate the user-agent). The client SHOULD
utilize the "state" request parameter to deliver this value to the
authorization server when making an authorization request.
Once authorization has been obtained from the end-user, the
authorization server redirects the end-user's user-agent back to the
client with the required binding value contained in the "state"
parameter. The binding value enables the client to verify the
validity of the request by matching the binding value to the
user-agent's authenticated state. The binding value used for CSRF
protection MUST contain a non-guessable value (as described in
Section 10.10), and the user-agent's authenticated state (e.g.,
session cookie, HTML5 local storage) MUST be kept in a location
accessible only to the client and the user-agent (i.e., protected by
same-origin policy).
A CSRF attack against the authorization server's authorization
endpoint can result in an attacker obtaining end-user authorization
for a malicious client without involving or alerting the end-user.
The authorization server MUST implement CSRF protection for its
authorization endpoint and ensure that a malicious client cannot
obtain authorization without the awareness and explicit consent of
the resource owner.
Given that the spec recommends the state parameter be used for CSRF protection, and that the user_id is going to be easily guessable (i.e. the opposite of what you'd want for CSRF protection) it doesn't seem like a good idea to be putting the user_id into the state parameter.
Some other sources seem to confirm this:
https://auth0.com/docs/secure/attack-protection/state-parameters
https://medium.com/keycloak/the-importance-of-the-state-parameter-in-oauth-5419c94bef4c
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
I have a website freshly deployed on the internal network of a client. I can test it only by remote desktop on a Windows Server 2012.
The website performs SAML authentication: the browser first receives a session cookie from the website, then is redirected to the SAML identity provider, and comes back to the website with the SAML response, where it also sends back the session cookie. This works fine with Chrome, but for some reason IE11 won't send back the session cookie, which prevents the server from accepting the SAML authentication.
I have no idea why IE11 fails to send the session cookie. I have checked in the Network pane in debug tools, and I do get the cookie (though I can't confirm IE is actually storing it) :
Set-Cookie ASP.NET_SessionId=yzk4rdznlg534so2xuxqmuv4; path=/; HttpOnly
Then I am redirected to the identity provider, but when coming back to the website, it doesn't send the cookie. The cookie is HTTP only so I can't check in the console if it is stored or not. I have used the instructions posted here to see stored cookies, and I can't see a cookie for my website at any time (though redirections happen fast, so it could possibly be added and then removed before I have a chance to see it).
I also believe I have explored all possible security and privacy settings to allow everything, to no avail.
In case it's important, the site URL has no dot (it's https://mmr-pp_sef/)
Any idea how I could troubleshoot what is (or isn't) happening?
Well, turns out that it IS related to the URL used (should have checked myself sooner instead of just pointing out that the URL was weird in my question).
Apparently, IE will not store cookies if there is an underscore _ in the host name. This can be verified by modifying your "hosts" file:
Open the file C:\Windows\System32\drivers\etc\hosts (you'll need admin rights)
Add this line at the end and save the file:
127.0.0.1 test_site
Enter the URL http://test_site in your browser (this assumes your web server listens on 127.0.0.1)
Observe that IE won't store any cookie.
The only workaround I have at this time is to use another host name, that does not contain an underscore, such as test-site.
I manage a Rails 4.2 application which runs dual stack: SSL and Non-SSL. I'd like to set the Secure flag for cookies when the resource is requested via HTTPS and I want to leave out the flag when the resource is requested via plain HTTP.
Is there a way to achieve this in Rails (session cookie, cookies sent manually in the Code)? And especially when using Devise with rememberable enabled.
I know this is a late response, but I'm currently looking into the same thing and it seems https://github.com/mobalean/devise_ssl_session_verifiable should automate this for you, although it uses a different approach (regular session cookie over http + https, but an additional secure cookie in https, so that someone hijacking your session cannot access your https-only resources.
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.