views:

1275

answers:

4

I'm doing some simple web integration work which I'm accomplishing through use of an iframe. My main window has some javascript which interacts with my server to redirect the iframe to the required URL. One of the target pages sadly has the following piece of code inside:

if (top.location != location) {
    top.location.href = document.location.href ;
}

The script dies because of cross-site-cripting restrictions and prevents that page from rendering properly. I can't modify the source of that page (3rd party I'm integrating with).

How could I work around this?

Thanks

+2  A: 

Instead of denying the wishes of the third party (to not be in a frame) can you open the third party in a new window?

The reason for that code is normally to avoid having content passed off as belong to the "framing" site. Even NoScript for FireFox allows framebusting code to run by default (via a proxy script).

Godeke
Yeah, I didn't want a new window but it looks like I'll have no choice. Thanks.
Mr Grieves
+2  A: 

The 'third-party' that you're 'integrating' with has made it clear that they don't want to be framed. Why not respect their wishes?

apphacker
This project is to their benefit. You'd think I could call them and ask them to allow our frame but I know how long it'll take them to take action and I'd rather find a workaround.
Mr Grieves
For the record, this really is integration. The URLs are being resolved via an api that they're exposing exclusively to us. I'm not evil!
Mr Grieves
+2  A: 

There is a technique to disable the frame busting code, as discussed in a newer SO question:

As it turns out, your frame-busting code can be busted, as shown here:

<script type="text/javascript">
    var prevent_bust = 0  
    window.onbeforeunload = function() { prevent_bust++ }  
    setInterval(function() {  
      if (prevent_bust > 0) {  
        prevent_bust -= 2  
        window.top.location = 'http://server-which-responds-with-204.com'  
      }  
    }, 1)  
</script>

This code does the following:

  • increments a counter every time the browser attempts to navigate away from the current page, via the window.onbeforeonload event handler
  • sets up a timer that fires every millisecond via setInterval(), and if it sees the counter incremented, changes the current location to a server of the attacker's control
  • that server serves up a page with HTTP status code 204, which does not cause the browser to nagivate anywhere
Colin Pickard
Please note that that code was defeated in less than 30 minutes by the users here. So this doesn't achieve the goal. And... down voting an accepted answer because you *think* you have a better solution is pissy (or it was a *coincidence* that I got a -2 on the accepted answer at the same moment you posted this non working answer?)
Godeke
I beg to differ; it does achieve his specific goal! The target page will not trying to defeat this method, as described in the question and comments. This new information will now allow him to achieve his goal
Colin Pickard
Hence the downvote - it was intended to indicate that the accepted answer was no longer a complete/correct answer to the question. With further thought however I have retracted the downvoted and replaced it with an upvote, since your answer did provide a sensible workaround.
Colin Pickard
The new technique is actually better for the purpose since the original design includes a iframe.
Colin Pickard
Also the answers were not accepted by Jeff because they do not address the likely situation of multiple domains. For practical purposes, it remains undefeated.
Colin Pickard
I have upvoted your answer for at least being honest about what happened and in recognition of fact that there may be some situations this might apply. It seems a desperate technique, but it does work. Honestly, I hope that someday something better (like a "NoFrame" attribute) comes into play because *most* suppression of frame busting falls into the "foul" category. If someone doesn't want to be framed, allowing them to have a new window is the "right" thing. Our insurance product was *designed* to be framed, including CSS matching the parent site: no frame busting code there.
Godeke