frame buster problem

[brunomartelli]

i have a question. I have a framed website. Is it possible to stop another site loading one of my content pages without the framebreaker, breaking the frames for a regular visitor to my site?

[jscheuer1]

Should be possible. Say your break out of frames code is something like:

if (location!=top.location)
top.location = location;

Instead of testing for location==top.location, you can test for the top location being a part of your domain:

if(!/http:\/\/(www\.)|()yourdomain\.com/.test(top.location.href))
top.location.href = location.href;

[clueful]

if(!/http:\/\/(www\.)|()yourdomain\.com/.test(top.location.href))
top.location.href = location.href;

That will generate an 'access denied' error which must be caught:

try
{
 if( top.document.domain != document.domain )
 ;
} catch(e)
  {
   top.location.href = 'http://myurl.com';
  }

[jscheuer1]

That's odd, because the other code works without a security problem. But in testing, try/catch doesn't seem to solve the issue. If I'm right about that, it may be because try/catch is only for errors. A security violation isn't an error. To allow try/catch to work around a security violation wouldn't be much security, now would it?

[clueful]

My attitude to try-catch is that anything that doesn't support it doesn't support the today's web, and its users will expect and get constant trouble.
A security violation quite plainly is an error.
I just tried the exact code that I posted, loaded as a foreign iframe. It threw an exception and executed the catch block as expected (Moz,IE,Opera & Safari).

[jscheuer1]

I tried it with my code and it didn't execute the catch block. Well, if your code works, I've no problem with that, and brunomartelli's problem is basically solved, except for older browsers. I question primarily that, if it is a security violation, try catch shouldn't allow you to do what you couldn't otherwise do. If it does, where's the security?

[clueful]

I question primarily that, if it is a security violation, try catch shouldn't allow you to do what you couldn't otherwise do. If it does, where's the security?

It doesn't, it just branches to alternative code that doesn't violate security.

Here's a try-catch free alternative that I tested successfully:

window.onerror=function()
{
 alert('I will not be framed!'); 
 top.location.href='http://myURL.com';
}

if( self.document.domain != top.document.domain )
;

window.onerror=null;

[jscheuer1]

Here's a try-catch free alternative that I tested successfully:

window.onerror=function()
{
 alert('I will not be framed!'); 
 top.location.href='http://myURL.com';
}

if( self.document.domain != top.document.domain )
;

window.onerror=null;

That looks really good, even though I know what mean when you talk about user agents that don't support try/catch, it just still seems prudent to avoid it where possible - or to shield browsers that cannot handle it from it. One of my pet peeves on this are the myriad of AJAX request scripts which routinely use it to determine the request method. Simple if/else if statements will work for that except as regards the two versions of Active X request objects supported by various versions of IE. For those try/catch statements though, cc script comments may be used to assure that only those versions of IE that would even be able to benefit or at least not choke on the code would parse those sections, ex snippet:

/*@cc_on @*/
/*@if(@_jscript_version >= 5)
try {
http_request = new ActiveXObject('Msxml2.XMLHTTP');
} catch(e) {
try {
http_request = new ActiveXObject('Microsoft.XMLHTTP');
} catch(e) {
http_request = null;
}
}
@end @*/

Which would be seen as a script comment to all but IE 5 and above.