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).
Related
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
I want to store the Referer in a cookie (using GTM) so that I can recall this on my lead form and input the information into a hidden field so the info is stored on my CRM.
I want the referer to provide the Full URL
I want the information to be saved on the first visit and not overwritten as they navigate the website.
I need help with the GTM part and writing this information into the Cookie and not overwriting it with every new page that's loaded on our site.
Lunametrics have created a brilliant way of recreating he utm cookie which will help you store all of this information. Just upload the details in to your GTM
https://www.lunametrics.com/labs/recipes/utmz-cookie-replicator-for-gtm/
Im not attributed to them in any way
You can check document.referrer - if it does not contain the hostname of your own site then you are on a landing page (something like if document.referrer.indexOf('mydomain.com') == -1).
That way you can (reasonably well) determine if this is the first page in the visit, in which case you trigger the tag that sets the cookie.
This is not 100% foolproof, since technically browsers are under no obligation to provide a referrer (also it can be easily spoofed), but AFAIK it works on all major browsers, I don't think there is a better way, and it's quite easy to implement.
I've never experienced this problem before, and it just came to our attention because a client was trying to access our page and couldn't see much of the javascript. He was navigating to http://www.mysite.com, when we've always just gone to http://mysite.com.
There appear to be no problems server-side, as in both url's are pointing to the same place. There are also no errors on the page when it loads.
Has anyone had to deal with this before?
If your absolute urls reference http://mysite.com/js/file.js and there's no redirect in place then the JS files wouldn't get picked up properly, obviously.
Are you aware of Firebug and it's net tab? You can inspect and see if the js files are being retrieved.
It would help if you provided the real link.
Are you sending the JavaScript only to authenticated users?
If that's the case, then a user that authenticated on http://example.com, will not be able to access pages on http://www.example.com assuming you didn't make any other changes. This is because the cookies set on either (www. or roo) will not be sent to the server when the user navigates to the other.
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 wrote a web page that displays images from several servers on my network via simple img tags with appropriate href values. The servers require authentication before they will send the images.
It works alright, except on first load the page presents the user with a series of password prompts (one for each server). The user can select the "Remember my password" checkbox, and then subsequent refreshes of the page work without prompting, with correctly updated images. That is, until someone closes out the browser, after which a new set of prompts awaits anyone who opens the page again.
All of the credentials needed are known beforehand, and I don't care if someone could read them in the page source, since this page is in a protected part of an internal intranet site. Everyone with access to this page knows the passwords anyway.
The only browser we're allowed to use is IE 7, so I don't care about compatibility with other browsers at the moment.
Is there any way I can use JavaScript (or some other client-side code) to automatically answer those prompts so the user never sees them?
Thanks very much, in advance.
You can include the authentication in the URL:
<img src="http://paulfisher:tastybacon#internalwebs/path/to/image.png">
Where, of course, paulfisher is my username and my password is tastybacon.
No, javascript can't do this. Here are a couple of options that I've used before to solve this problem:
Change the authentication on the other servers to be either anonymous or integrated.
Proxy in the images: On the server serving the page, add another page that takes in the URL of the remote server. This new page makes a webrequest to the other server and streams the image back. The webrequest can plug in the correct credentials.
Depending on the servers' DNS names, it might be possible to share an authentication cookie across all of the servers. Then you could set up some kind of module on all of the servers to allow the shared authentication.