Hello I want to set crossdomain cookie using javascript.
So on domain localhost I can easily set cookie. So I load the page on localhost:300 and in the Browser's console I type:
document.cookie = "my_cookie=works; Domain=localhost; path=/;"
This method works - I can see the cookie being set.
But now, I want to set cookie to a different domain
from the same place:
document.cookie = "my_cookie=doesntwork; Domain=.hubspot.com; path=/;"
And this time it doesnt work - I still have the old cookie value and domain:
I know that what I am trying to do is possible because I have seen it on many sites.
For example if check the cookies on this site you will see many cookies with domain google but the domain is stackoverflow.com .
For example:
So, how can I imitate/mimic this? I see some suggest using iframes - I tried without success - the cookies are still blocked. Please provide workable example (I believe 5 lines of code can do )
I want to open localhost page in my browser
and run JS code that would put cookie with domain like .example.com.
This is obviously possible. But I cant do it.
I'm not trying to complete some job here - I just want to understand how the cool kids do it.
You cannot set a "cross-domain" cookie for security reasons. If this was possible, you'd be able to remotely sign people out of their accounts on other websites if they visited yours by overwriting their cookie for their site. The cookies you are seeing on pages like StackOverflow are because that page includes resources from that server. For example, you can see imgur cookies on this page since the image you linked to is hosted there.
SORRY FOR MY BAD ENGLISH!
There is no such thing as a cross-domain cookie that said you can get the same tracking functionality with sharing a cookie.
for example we want to track a user in our ad network across affiliated sites.
our tracking endpoint is : https://tracking.a.com
here we set a deviceid in the cookies.
Our Affiliated Webmaster b.com adds a javascript which adds an iframe to the page. iframe loads somecontent from a.com hence the cookies are shared then you can inside the iframe send the users current location ( b.com/shop ) to a tracking endpoint and attach deviceid cookie which can only be accessed by webpage on a.com. now deviceid or user can be related to the affiliate website and their intrests can be pridicted - but it is illegal - and safari deletes these cookies
Related
I create a script with Node.js and Puppeteer that loads multiple sites like (site A, B, C etc). I want to find all the cookies that site uses.The problem is, that some sites have a Cookie Banner to accept or decline. If you accept the banner the website adds some extra cookies.
So to capture all that cookies is there a general solution to accept all the different banners or to set some initial parameter on header of the initial request to inform the site that I accept all that cookies?
Here is an example of a site with Cookie Bannner initial set 6 cookies and if you accept the banner the total cookies are 48.
https://siteimprove.com/en/gdpr/who-gdpr-affects-and-whose-data-is-protected/
I need a general solution. Because I have a list of websites.
You can use the identifiers of cookies banners : https://www.fanboy.co.nz/fanboy-cookiemonster.txt
Unfortunately, there is no standard way to do this. Because there is no standard for "cookie banners". If your list of websites isn't terribly large, your best bet is to figure out what the cookie is for each site, store them systematically, and use the appropriate cookies based on the domain being navigated.
UPDATE: see the puppeteer docs here on how to add cookies to your request: https://pptr.dev/#?product=Puppeteer&version=v5.4.0&show=api-pagecookiesurls
I have a website developed in PHP and JavaScript language and I am using cookies on my website. Also there are many third party scripts like google analytics, mouseflow, third party chat script etc on my website. These scripts are also storing cookies.
To get my website GDPR compliant, before storing marketing cookies (like analytics) I need to make sure that the visitor has given his/her consent for storing it.
We can show the visitors a pop-up stating the cookie policy and once they accept, we will start storing cookies.
So, How can we prevent any of the cookie to be stored before the consent of the user.
Well what I always do is check if the cookie exists, if not I won't allow access to the features of the website that allow that. If it exists, the user has given consent.
To make it cleanly, you need to check server side that their is a "cookie consent" cookie/session var present. If that's the case, serve the normal website, if not, render a barebone page with just the cookie consent form and 0 tracking scripts.
It's not so easy, but i guess getting rid of the tracking scripts is not an option for you
I'm implementing a plug-in that's embeddable in different sites (a la Meebo, Wibiya), and I want to use Facebook Connect. The plug-in is supposed to be embeddable in sites with different domain names. Problem is, Facebook connect allows only one domain per application you register.
The question is, how can I have multiple domains for a single Facebook application, assuming:
When users "Allow" the application on one site, they won't have to "Allow" it on other sites as well.
Preferably, after the initial log-in, users won't see a pop-up opening on every site they log-in to (i.e. - I'd rather not open a link to my domain and do the log-in process from there).
Is there anyway of doing that?
If not, is my only option is to manage all the log-ins from a single domain and pass the cookies back to the original domains?
And if I pass the cookies between domains, how can I be sure that Facebook won't block this kind of behavior in the future?
I'd appreciate any suggestions, though I'd prefer an official solution over hacks, if at all possible.
Im assuming you are using facebook.php by Naitik Shah? Your widget would need to be on every page of course and include the async script connect-js.
I am currently developing a facebook login based application myself.
I would say the best solution is too login through your own domain and pass the cookie. Your app/widget will be the only one they allow to share information with. Nothing should be different in operation from a single page solution. I envisage a PHP plugin which executes a login from an outside domain and passes through the cookie to the site via the widget. return the cookie securely how you wish (except for something dodgy like storing it in a div and retrieving it..or something a hacker could try to spoof). the site will then use the cookie for account and user id purposes and the widget will control all login actions and session finding using the async script (but routed through a different domain).
Sorry I can't be more help but this is the only solution I can think of, and it seems you have already anyway.
In terms of keeping session control across different domains you only need the 3rd party cookie to be active. Once your page is activated for your domain you will already have the cookie for that domain if you haven't logged out or it hasn't expired. A benefit of using an outside management domain.
It would seem this is also the most reliable way compared to any successful hack for multiple domains, because I would see fb and Oauth2.0 as being ok with an approved party sharing info (cookies) to another party approved by the approved party. But.. It could be problematic if they think the user will have privacy issues, because you could potentially share the cookie on any site without the users permission. So you have to be careful about notifying the user about all the sites they will be auto logged into and treating them with respect.
Good luck with it, hope you let us know how it goes.
There is easy and clean technique -> Single Sign On (SSO). You can search on about it.
Just want to get input from people who know. I was considering CSRF vulnerabilities, and the seemingly the most popular method I know to fight against it. That method is to create a token in the returned html and adding a cookie with the same value. So if a script tries to do a post they would have to guess the token thats embedded in the web page for it to be successful.
But if they're targeting a specific website why can't they just use a script that
Calls a get on the page (the cookie will be returned even though the script can't access it)
Parses the html and gets the token
Calls a post with that token in it (the cookie that came back will be sent back)
They've successfully submitted a form without the users knowledge
The script doesn't need to know the contents of the cookie, it's just using the fact that cookies get sent back and forth all the time.
What am I missing here? Is this not possible? I think this is pretty scary if you think about it.
Below this line is not required reading to answer the question :)
This vulnerability banks on the fact that authentication is done based on cookies, which I think is the main way authentication is currently occurring.
Another solution I can think of is making authentication be on the page level. So
when they log in the returned html will have that token in it. every link that they click contains that token so when the web server gets a request it has a way to identify the user/session. The problem with it is that if they use any navigation other than that they will be 'unauthenticated'(e.g. type in a url) , also it doesn't look nice in the url because it would probably look something like this:
https://www.example.com/SuperSecretPage/1/123j4123jh12pf12g3g4j2h3g4b2k3jh4h5g55j3h3
But I do understand that if safety is more important, then a pretty URL is second place.
I don't know everything about cookies but what if user agents were a little more careful with their cookies?
For example, what if the cookies sent depended on the tab? We all surf using tabs by now, right? so what if the scope of the cookie was the tab? so if i have my banking site open on tab 1 and i'm surfing on tab 2, any scripts calling gets/posts on
tab 2 will only send the cookies accrued in tab 2.
Or what if cookies were stored / domain. So while I'm on example.com any cookies that come back go into the example.com cookie collection. and then when i'm on www.mybankingsite.com all the cookies get put into the mybankingsite.com collection. So if I go to example.com and it runs a script that calls a get/post the user agent will only send example.com cookies. This is different than sending the cookies of the requested domain. E.g. if a script calls a get of mybankingsite.com within a web page of example.com the user agent will not send the mybankingsite.com cookies.
I know i have no control over what user agents do, but I'm just exploring possibilities
So I think the problem here becomes the attacker's attempt to get the page's contents. To get the authenticated user's page, the attacker needs to be able to send a request on their behalf and read the contents. AJAX won't send cross-domain requests, iframes won't let you read the response. I am struggling to think of other ways in which an attacker would get the contents first.
A more likely hack is using clickjacking to have the user just submit the form. This technique doesn't seem too likely. (caveat: it's security, we can always be wrong.)
Does anyone care to share some code on this issue as I just hacked my own site (Not in production) with CSRF. All I had to do was the following
At: www.badguy.com/ write the following html
img src="www.goodguy.com/secure/user/delete/5">
What this does
So the admin goes to to www.badguy.com/ and the the image makes a request to
www.goodguy.com/secure/user/delete/5 from the users browser so the admin unknowingly just deleted a user. If you create a loop your in some trouble. Expect I never delete data just change its status :) but still I don't like the looks of this.
The CSRF token has to be unique per session. If a malicious server requests the same page, they will get a different token. If they try to request the contents of the page via JavaScript on the client's machine, the same-origin policy will prevent them.
I have a Rails app where I set a set a session variable the moment a user lands on my site with the referer and the page they hit. Additionally, I have Google Optimizer sending traffic from my homepage to various landing pages. The problem is that I think Google Optimizer is sending users away before the cookie is set.
Is that even possible? I believe that the cookie is set from the HTTP Header, which must have fully loaded before Google's Javascript has even loaded.
Thanks,
Jason
You're absolutely correct - the explanation you propose isn't possible. Assuming the browser is loading the page from your site that sends the cookie header, it will be set, and JavaScript can't directly interfere with this.
So the problem is elsewhere - the first thing I would test is whether the Cookie header is actually being sent, whether it's being set (look in your browser's security/privacy panel), and then whether your code for checking if it's been set is functioning correctly.
As you suspected, the cookie should be sent in the header when the visitor hits your page, so google optimizer shouldnt be affecting this..
You may want to double check that you are setting the cookie, you can use firebug or similar for this (in the Net tab).