Using JavaScript, is it possible to inject an iframe and have the iframe hold no cookie/session data? Effectively an 'incognito' iframe?
The reason for this is a Chrome extension I was thinking about, where I'd like to display a preview of pre-auth pages of other websites, and so to ensure they're not redirected the iframe would ideally non use existing cookie data.
I know this is similar to this question, but I don't have full control of the pages I'm previewing in the iframe.
If you don't use any HTTP-only cookies, you could save a copy of all cookies in localStorage, remove all cookies, load the iframe, and restore the cookies from localStorage.
Pseudo-code:
localStorage.setItem("cookies", document.cookie);
removeAllCookies();
openIframe();
document.cookie = localStorage.cookies;
localStorage.removeItem("cookies");
Another way is to create a proxy on your server, which wouldn't use cookies. For example request to http://example.com/proxy?url=/preview would make a request to http://example.com/preview without cookies.
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
Recently I'm moving my website to a new domain, and I want to migrate user cookies to the new domain too, so they don't have to log in again.
After some research, I found there are two potential ways to do it:
Land user first on old-domain.com, update all cookies with new-domain.com so they can be accessed from new-domain.com, then do a browser redirect to new-domain.com;
Alternatively, on the new-domain.com, I can inject an iframe from old-domain.com, to let it write cookies to the new website...
I'm not sure if these two can achieve my goal to migrate cookies between domains. Is there a suggestied ways to do it, so that user doesn't have to sign in again to use the new domain?
I think something like #2 can work.
On the new page, check if the cookies are already set. If not, inject an iframe like:
<iframe src="http://old-domain.com/getcookies.html" style="height: 0; width: 0;">
getcookies.html will just contain Javascript that gets the cookies and uses postMessage() to send them to the new page. Javascript on the new page will receive the message and then set the cookies that it receives.
There are some potential issues with this:
Loading the iframe and having it send the cookies is asynchronous. What should the page do while it's waiting?
If you use cookies on the server, the above code doesn't set them until the client receives the page from the server. The server will need to deal with non-migrated users specially, by first sending them the script that copies the cookies, and it then redirects them back to the server script.
You have to deal with users that were never on the old domain. getcookies.html should detect that none of the cookies are set, and send back a message indicating this.
I suggest you add a new cookie migrated=yes that can be used to detect whether the user needs to go through any of this.
I am trying to get session data between different websites, similar to what stackexchange does with all its sister sites, in which I login once and my session is detected on the other sites.
But the difference is I would need to create a session on www.site1.com and access it on www.site2.com, and also would post this code on 3rd party sites to still access the session from their site. The information contained is non sensitive(password/id) and would just let me know who the user is via a publicID.
Im using nodejs and redis for my sessions.
Things I have tried:
1) Iframes, postMessage, localStorage:
-User sends session info from site1.com to iframe on the same page containing "site2.com" via PostMessage. On site2.com, when I receive the message, I am attempting to save to site2.com localstorage, the goal is to access site2.com session from any other websites having the site2.com iframe on their page.
The error I got, was unable to save localStorage on other domain by sending postMessage from site1.com to the site2.com iframe.
On site1.com I have an iframe showing site2.com, where site2.com is my server that will save the session.
2) CORS ajax: was not able to save/remember session
I've heard of browser fingerprinting, like how facebook/google can track users across sites and this may be the type of solution i need.
Can someone please let me know what I can try different? Thanks.
You could maybe use access tokens stored on the cookies or passed on the url, similar to the way RESTful apps work. This might be a helpful read:
http://www.sitepoint.com/using-json-web-tokens-node-js/
I am storing some information into Flash cookies. when anyone hitting a page it first check for m/c cookie and then it checks for flash cookie. If the flash cookie has some extra information it is writing on the m/c cookie but it is refreshing the page again, which in-turn increasing my page count/ view.
I want my m/c cookies to be updated by flash cookies as soon as user gets the response. I don't want to refresh the page again which is causing by flash cookies.
Edit/Update your cookies via javascript.
Check the Actionscript docs and read about the ExternalInterface which will allow you to communicate with Javascript. Practically, whenever you want to access a JS function from AS3 , you could use ExternalInterface to call it.
It's not clear in your description what causes a page refresh, reading a Flash cookie wouldn't cause that. Send us more information if ExternalInterface doesn't solve your issue.
I have this question as well... Flash runs client side, which means, in order to set a PHP session, server-side, you need atleast run the flash application in the client to get the flash cookie value and than pass that value to php. That is what is meant with the refresh.
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.