We Keep Coding

Checking Third-Party iFrame Content [duplicate]

Let's say you don't want other sites to "frame" your site in an <iframe>:
<iframe src="http://example.org"></iframe>
So you insert anti-framing, frame busting JavaScript into all your pages:
/* break us out of any containing iframes */
if (top != self) { top.location.replace(self.location.href); }
Excellent! Now you "bust" or break out of any containing iframe automatically. Except for one small problem.
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://example.org/page-which-responds-with-204'
}
}, 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.onbeforeunload 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 navigate anywhere
My question is -- and this is more of a JavaScript puzzle than an actual problem -- how can you defeat the frame-busting buster?
I had a few thoughts, but nothing worked in my testing:
attempting to clear the onbeforeunload event via onbeforeunload = null had no effect
adding an alert() stopped the process let the user know it was happening, but did not interfere with the code in any way; clicking OK lets the busting continue as normal
I can't think of any way to clear the setInterval() timer
I'm not much of a JavaScript programmer, so here's my challenge to you: hey buster, can you bust the frame-busting buster?

FWIW, most current browsers support the X-Frame-Options: deny directive, which works even when script is disabled.
IE8:
http://blogs.msdn.com/ie/archive/2009/01/27/ie8-security-part-vii-clickjacking-defenses.aspx
Firefox (3.6.9)
https://bugzilla.mozilla.org/show_bug.cgi?id=475530
https://developer.mozilla.org/en/The_X-FRAME-OPTIONS_response_header
Chrome/Webkit
http://blog.chromium.org/2010/01/security-in-depth-new-security-features.html
http://trac.webkit.org/changeset/42333

I'm not sure if this is viable or not - but if you can't break the frame, why not just display a warning. For example, If your page isn't the "top page" create a setInterval method that tries to break the frame. If after 3 or 4 tries your page still isn't the top page - create a div element that covers the whole page (modal box) with a message and a link like...
You are viewing this page in a unauthorized frame window - (Blah blah... potential security issue)
click this link to fix this problem
Not the best, but I don't see any way they could script their way out of that.

We have used the following approach in one of our websites from http://seclab.stanford.edu/websec/framebusting/framebust.pdf
<style>
body {
display : none
}
</style>
<script>
if(self == top) {
document.getElementsByTagName("body")[0].style.display = 'block';
}
else{
top.location = self.location;
}
</script>

Came up with this, and it seems to work at least in Firefox and the Opera browser.
if(top != self) {
top.onbeforeunload = function() {};
top.location.replace(self.location.href);
}

Considering current HTML5 standard that introduced sandbox for iframe, all frame busting codes that provided in this page can be disabled when attacker uses sandbox because it restricts the iframe from following:
allow-forms: Allow form submissions.
allow-popups: Allow opening popup windows.
allow-pointer-lock: Allow access to pointer movement and pointer lock.
allow-same-origin: Allow access to DOM objects when the iframe loaded form same origin
allow-scripts: Allow executing scripts inside iframe
allow-top-navigation: Allow navigation to top level window
Please see: http://www.whatwg.org/specs/web-apps/current-work/multipage/the-iframe-element.html#attr-iframe-sandbox
Now, consider attacker used the following code to host your site in iframe:
<iframe src="URI" sandbox></iframe>
Then, all JavaScript frame busting code will fail.
After checking all frame busing code, only this defense works in all cases:
<style id="antiClickjack">body{display:none !important;}</style>
<script type="text/javascript">
if (self === top) {
var antiClickjack = document.getElementById("antiClickjack");
antiClickjack.parentNode.removeChild(antiClickjack);
} else {
top.location = self.location;
}
</script>
that originally proposed by Gustav Rydstedt, Elie Bursztein, Dan Boneh, and Collin Jackson (2010)

After pondering this for a little while, I believe this will show them who's boss...
if(top != self) {
window.open(location.href, '_top');
}
Using _top as the target parameter for window.open() will launch it in the same window.

As of 2015, you should use CSP2's frame-ancestors directive for this. This is implemented via an HTTP response header.
e.g.
Content-Security-Policy: frame-ancestors 'none'
Of course, not many browsers support CSP2 yet so it is wise to include the old X-Frame-Options header:
X-Frame-Options: DENY
I would advise to include both anyway, otherwise your site would continue to be vulnerable to Clickjacking attacks in old browsers, and of course you would get undesirable framing even without malicious intent. Most browsers do update automatically these days, however you still tend to get corporate users being stuck on old versions of Internet Explorer for legacy application compatibility reasons.

All the proposed solutions directly force a change in the location of the top window. What if a user wants the frame to be there? For example the top frame in the image results of search engines.
I wrote a prototype where by default all inputs (links, forms and input elements) are disabled and/or do nothing when activated.
If a containing frame is detected, the inputs are left disabled and a warning message is shown at the top of the page. The warning message contains a link that will open a safe version of the page in a new window. This prevents the page from being used for clickjacking, while still allowing the user to view the contents in other situations.
If no containing frame is detected, the inputs are enabled.
Here is the code. You need to set the standard HTML attributes to safe values and add additonal attributes that contain the actual values. It probably is incomplete and for full safety additional attributes (I am thinking about event handlers) will probably have to be treated in the same way:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<html>
<head>
<title></title>
<script><!--
function replaceAttributeValuesWithActualOnes( array, attributeName, actualValueAttributeName, additionalProcessor ) {
for ( var elementIndex = 0; elementIndex < array.length; elementIndex += 1 ) {
var element = array[ elementIndex ];
var actualValue = element.getAttribute( actualValueAttributeName );
if ( actualValue != null ) {
element[ attributeName ] = actualValue;
}
if ( additionalProcessor != null ) {
additionalProcessor( element );
}
}
}
function detectFraming() {
if ( top != self ) {
document.getElementById( "framingWarning" ).style.display = "block";
} else {
replaceAttributeValuesWithActualOnes( document.links, "href", "acme:href" );
replaceAttributeValuesWithActualOnes( document.forms, "action", "acme:action", function ( form ) {
replaceAttributeValuesWithActualOnes( form.elements, "disabled", "acme:disabled" );
});
}
}
// -->
</script>
</head>
<body onload="detectFraming()">
<div id="framingWarning" style="display: none; border-style: solid; border-width: 4px; border-color: #F00; padding: 6px; background-color: #FFF; color: #F00;">
<div>
<b>SECURITY WARNING</b>: Acme App is displayed inside another page.
To make sure your data is safe this page has been disabled.<br>
Continue working safely in a new tab/window
</div>
</div>
<p>
Content. Do something
</p>
<form name="acmeForm" action="#" acme:action="real-action.html">
<p>Name: <input type="text" name="name" value="" disabled="disabled" acme:disabled=""></p>
<p><input type="submit" name="save" value="Save" disabled="disabled" acme:disabled=""></p>
</form>
</body>
</html>

if (top != self) {
top.location.replace(location);
location.replace("about:blank"); // want me framed? no way!
}

I'm going to be brave and throw my hat into the ring on this one (ancient as it is), see how many downvotes I can collect.
Here is my attempt, which does seem to work everywhere I have tested it (Chrome20, IE8 and FF14):
(function() {
if (top == self) {
return;
}
setInterval(function() {
top.location.replace(document.location);
setTimeout(function() {
var xhr = new XMLHttpRequest();
xhr.open(
'get',
'http://mysite.tld/page-that-takes-a-while-to-load',
false
);
xhr.send(null);
}, 0);
}, 1);
}());
I placed this code in the <head> and called it from the end of the <body> to ensure my page is rendered before it starts arguing with the malicious code, don't know if this is the best approach, YMMV.
How does it work?
...I hear you ask - well the honest answer is, I don't really know. It took a lot of fudging about to make it work everywhere I was testing, and the exact effect that it has varies slightly depending on where you run it.
Here is the thinking behind it:
Set a function to run at the lowest possible interval. The basic concept behind any of the realistic solutions I have seen is to fill up the scheduler with more events than the frame buster-buster has.
Every time the function fires, try and change the location of the top frame. Fairly obvious requirement.
Also schedule a function to run immediately which will take a long time to complete (thereby blocking the frame buster-buster from interfering with the location change). I chose a synchronous XMLHttpRequest because it's the only mechanism I can think of that doesn't require (or at least ask for) user interaction and doesn't chew up the user's CPU time.
For my http://mysite.tld/page-that-takes-a-while-to-load (the target of the XHR) I used a PHP script that looks like this:
<?php sleep(5);
What happens?
Chrome and Firefox wait the 5 seconds while the XHR completes, then successfully redirect to the framed page's URL.
IE redirects pretty much immediately
Can't you avoid the wait time in Chrome and Firefox?
Apparently not. At first I pointed the XHR to a URL that would return a 404 - this didn't work in Firefox. Then I tried the sleep(5); approach that I eventually landed on for this answer, then I started playing around with the sleep length in various ways. I could find no real pattern to the behaviour, but I did find that if it is too short, specifically Firefox will not play ball (Chrome and IE seem to be fairly well behaved). I don't know what the definition of "too short" is in real terms, but 5 seconds seems to work every time.
If any passing Javascript ninjas want to explain a little better what's going on, why this is (probably) wrong, unreliable, the worst code they've ever seen etc I'll happily listen.

Ok, so we know that were in a frame. So we location.href to another special page with the path as a GET variable. We now explain to the user what is going on and provide a link with a target="_TOP" option. It's simple and would probably work (haven't tested it), but it requires some user interaction. Maybe you could point out the offending site to the user and make a hall of shame of click jackers to your site somewhere.. Just an idea, but it night work..

Well, you can modify the value of the counter, but that is obviously a brittle solution. You can load your content via AJAX after you have determined the site is not within a frame - also not a great solution, but it hopefully avoids firing the on beforeunload event (I am assuming).
Edit: Another idea. If you detect you are in a frame, ask the user to disable javascript, before clicking on a link that takes you to the desired URL (passing a querystring that lets your page know to tell the user that they can re-enable javascript once they are there).
Edit 2: Go nuclear - if you detect you are in a frame, just delete your document body content and print some nasty message.
Edit 3: Can you enumerate the top document and set all functions to null (even anonymous ones)?

If you add an alert right after the buster code, then the alert will stall the javascript thread, and it will let the page load. This is what StackOverflow does, and it busts out of my iframes, even when I use the frame busting buster. It also worked with my simple test page. This has only been tested in Firefox 3.5 and IE7 on windows.
Code:
<script type="text/javascript">
if (top != self){
top.location.replace(self.location.href);
alert("for security reasons bla bla bla");
}
</script>

I think you were almost there. Have you tried:
window.parent.onbeforeunload = null;
window.parent.location.replace(self.location.href);
or, alternatively:
window.parent.prevent_bust = 0;
Note: I didn't actually test this.

If you look at the values returned by setInterval() they are usually single digits, so you can usually disable all such interrupts with a single line of code:
for (var j = 0 ; j < 256 ; ++j) clearInterval(j)

What about calling the buster repeatedly as well? This'll create a race condition, but one may hope that the buster comes out on top:
(function() {
if(top !== self) {
top.location.href = self.location.href;
setTimeout(arguments.callee, 0);
}
})();

I might just have just gotten a way to bust the frame buster buster javascript. Using the getElementsByName in my javascript function, i've set a loop between the frame buster and the actual frame buster buster script.
check this post out. http://www.phcityonweb.com/frame-buster-buster-buster-2426

setInterval and setTimeout create an automatically incrementing interval. Each time setTimeout or setInterval is called, this number goes up by one, so that if you call setTimeout, you'll get the current, highest value.
var currentInterval = 10000;
currentInterval += setTimeout( gotoHREF, 100 );
for( var i = 0; i < currentInterval; i++ ) top.clearInterval( i );
// Include setTimeout to avoid recursive functions.
for( i = 0; i < currentInterval; i++ ) top.clearTimeout( i );
function gotoHREF(){
top.location.href = "http://your.url.here";
}
Since it is almost unheard of for there to be 10000 simultaneous setIntervals and setTimeouts working, and since setTimeout returns "last interval or timeout created + 1", and since top.clearInterval is still accessible, this will defeat the black-hat attacks to frame websites which are described above.

Use htaccess to avoid high-jacking frameset, iframe and any content like images.
RewriteEngine on
RewriteCond %{HTTP_REFERER} !^http://www\.yoursite\.com/ [NC]
RewriteCond %{HTTP_REFERER} !^$
RewriteRule ^(.*)$ /copyrights.html [L]
This will show a copyright page instead of the expected.

You could improve the whole idea by using the postMessage() method to allow some domains to access and display your content while blocking all the others. First, the container-parent must introduce itself by posting a message to the contentWindow of the iframe that is trying to display your page. And your page must be ready to accept messages,
window.addEventListener("message", receiveMessage, false);
function receiveMessage(event) {
// Use event.origin here like
if(event.origin == "https://perhapsyoucantrustthisdomain.com"){
// code here to block/unblock access ... a method like the one in user1646111's post can be good.
}
else{
// code here to block/unblock access ... a method like the one in user1646111's post can be good.
}
}
Finally don't forget to wrap things inside functions that will wait for load events.

How do i detect served ad dimensions

I am currently using google publisher tags with DFP to serve up ads to a site that will very soon be responsive. We have one particular ad slot which can potentially serve up 2 potential widths, 728 or 960 and depending on which width gets served up I want to either render the ad above or below the nav.
So the obvious first question is whether or not this is even remotely sane and furthermore is it possible? I suspect i should probably define two distinct ad slots.
The primary question though which is probably more of an academic one is how can I detect the dimensions of an ad that has been served? I suspect the solution to this is agnostic to the ad platform since I am basically detected node insertion and then inspecting the dimensions of the container element.
I've been experimenting with the DOMNodeInserted javascript event however it seems to trigger for everything "BUT" the ads. I am confused by this unless gpt inserts the ads in a way that does not trigger this event.

There's been an update to GPT which allows this to be done in a more elegant manner.
The event will tell you if a creative was returned and if so the dimensions, as well as additional information.
googletag.pubads().addEventListener('slotRenderEnded', function(event) {
console.log('Creative with id: ' + event.creativeId +
' is rendered to slot of size: ' + event.size[0] + 'x' + event.size[1]);
});
There is also event.isEmpty which will tell you if an actual creative was returned or not.

I have done something like this before... and the method I settled upon was overriding an internal DFP function (renderEnded) so that I could see what the ad was at the point it had rendered on screen...
For example to get the dimensions of the ad you could do something like the following (I've only tested this in chrome but it shouldn't be too far from being fully cross browser):
<html>
<head>
<title>DFP test</title>
<script type='text/javascript'>
var googletag = googletag || {};
googletag.cmd = googletag.cmd || [];
(function() {
var gads = document.createElement('script');
gads.async = true;
gads.type = 'text/javascript';
var useSSL = 'https:' == document.location.protocol;
gads.src = (useSSL ? 'https:' : 'http:') +
'//www.googletagservices.com/tag/js/gpt.js';
var node = document.getElementsByTagName('script')[0];
node.parentNode.insertBefore(gads, node);
})();
</script>
<script type="text/javascript">
googletag.cmd.push(function() {
var slot1 = googletag.defineSlot('/12345678/TEST', [266, 115], 'div-gpt-ad-1340819095858-0').addService(googletag.pubads());
slot1.oldRenderEnded = slot1.renderEnded;
slot1.renderEnded = function(){
window.console.log('width: '+document.getElementById('div-gpt-ad-1340819095858-0').getElementsByTagName('iframe')[0].contentWindow.document.width);
window.console.log('height: '+document.getElementById('div-gpt-ad-1340819095858-0').getElementsByTagName('iframe')[0].contentWindow.document.height);
slot1.oldRenderEnded();
};
googletag.pubads().enableSingleRequest();
googletag.enableServices();
});
</script>
</head>
<body>
<div id='div-gpt-ad-1340819095858-0' style='width:266px; height:115px;'>
<script type='text/javascript'>
googletag.cmd.push(function() {
googletag.display('div-gpt-ad-1340819095858-0');
});
</script>
</div>
</body>
</html>
That might not be quite what you are after but overriding that function should let you get to where you need to be... let me know if you have any questions.

I had a similar problem over on WiiMusic.net with Google AdSense. What I ended up doing was detecting the size of the div containing the ad with JavaScript and then loaded the ad. In this situation, it wasn't possible to change resolution or size of my page once loaded, so this worked.
In your situation, your page can certainly change size and what not. I think you will have to re-load the ads at that point, if you want different ad versions to be visible depending on your responsive design. If you are using the asynchronous ad code, this should be possible.
To sum it up, yes, this is sane and possible with JavaScript. Your ads require JavaScript to work anyway, so this shouldn't be too much of a barrier.

So as usual I was way over thinking this. The reason I wasn't detecting a DOM change is because the ad had already been inserted by the time i was assigning event handlers. WHen loading ads synchronously I can immediately measure the dimensions of the container div and get the ad dimensions. When loading asynchronously I'm able to poll for inner html changes by storing the original html using and polling for changes and making the measurement of the container div when the change occurs. Thanks Brad for your time.

Trying to remove ads in Gmail with Chrome Extension

I'm experimenting with a Chrome extension that will remove the ads displayed in the right-hand pane in Gmail and instead put the information I want there. (I haven't decided exactly what to put there yet; vacillating between several ideas, including external content and/or attachments.)
The ads are (usually) contained in a <div class="oM"></div> element. But I can't seem to select that either in my extension or in the console.
I've tested my manifest.json settings by writing an extension that added a superfluous div to the top of the page, and that worked fine -- I just created a new element and
document.body.parentElement.insertBefore(new_el, document.body);
However, what I'm trying to do now is just rip out the ads and put in some dummy text, or just put the text above the ads. This is the main function called in my content_script.js file.
function modifyPage(txt) {
var container = document.getElementsByClassName('oM')[0];
container.innerHTML = txt;
}
function modifyPage(txt) {
var insert = document.createElement('div');
insert.innerText = txt;
var container = document.getElementsByClassName('oM')[0];
document.body.parentElement.insertBefore(insert, container);
}
I've even tried to jQuery:
function modifyPage(txt) {
$('.oM').html(txt);
}
Also, trying to retrieve the <div class="oM"> using the Chrome console returns nothing -- even though I can see it right there in the source.

Set a delay on the execution of your jquery selector. The Google Tubes are a bit more complicated than using static div classes on page load.

Rather than remove the ads with JS, just hide them with CSS:
.oM {
display: none;
}

I'm using AdBlock + Chrome add-in(or extension).
It works very well it's a donation-ware, I'm guessing the author use jquery {display:none } to hide or remove the ads with a custom filter lists.

Disabling Copy/Paste in a Web Page

How Do I disable the copy paste feature in my webpage. To be precise, I don't want my users to copy any information from my website and use them for personal purposes. The previous question on the same topic doesn't give enough explanation. The onselect and ondrag aren't working. Please help.

I don't want my users to copy any
information from my website and use
them for personal purposes
There is no way to do this. If someone really wants your information, they can get it.
You might be able to give them a litte bit of trouble with disabling certain functions using javascript or whatever...but you'll only give the people who don't know much about technology that trouble. And usually those people aren't even trying to copy your data. The one's who are, will figure out a way.

If you publish information online, you should clearly indicate your copyright claim on the page (or indicate the type of license you issue the content under). Please find and read the copyright law of your territory to understand what this does and doesn't allow - for example, in the UK there are provisions for making personal copies of copyrighted material and for using parts of copyrighted work for critical review or parody.
You can't stop people from copying the content on your page. You can make it more difficult for them to do - but this will have a negative impact on your page. Techniques such as preventing the left-click of the mouse, intercepting keyboard events or converting your entire article into images just make your website less usable.
If you have textual information on your website, I can re-type it even if you've stopped every other method of me copying the image. If you have an image and you've managed to lock out everything else, I can still do a screen-grab (not to mention the fact that my browser caches all the images in a temporary folder on my machine).
Your content-paranoia affects many people who set up a website - but the idea behind the Internet is that it is used for sharing information.

Just add the following code to the HEAD tag of your web page:
<script type="text/JavaScript">
//courtesy of BoogieJack.com
function killCopy(e){
return false
}
function reEnable(){
return true
}
document.onselectstart=new Function ("return false")
if (window.sidebar){
document.onmousedown=killCopy
document.onclick=reEnable
}
</script>

By default, Chrome and Firefox block disabling the right click menu. You have to manually edit an entry in about:config in Firefox to prevent it being blocked, which is not something you can force your visitors to do.
Regarding IE, you can modify your BODY tag like so:
<body onContextMenu="return false">
Which will prevent the right click context menu.
Other than that, the next best step is to create an image of your text, place it in a .swf (flash) document, and point the page to load the .swf as the page. This will cause all browsers to display the flash context menu on right click, and will prevent simple copy/paste efforts.
I do agree with previous replies, regardless of method used, any user can simply use their Print Screen key, paste the image in Paint (or other program), save it, and use OCR to grab your text.

You need to rethink your strategy if you're resorting to these measures on the front end. What you are trying to do is inherently wrong.
As a visitor to your web page, pulling something like this is just going to annoy me - I will eventually figure out what you've done and get around it. That said, I've recently found this particular method can be quite effective if you're aiming to restrict impatient or non-technical users. Proceed with caution...
<div class="text">
<p>Hello, world! Sadly, I won't work.</p>
<img alt="I can't be dragged or saved either :(" src="tree.png">
<div class="preventSelect"></div>
</div>
...and the CSS:
.text {
position: relative;
width: auto; /* can be fixed as well (ie 400px) */
width: auto; /* can be fixed as well (ie 400px) */
z-index: 0;
}
.preventSelect {
position: absolute;
top: 0;
right: 0;
bottom: 0;
left: 0;
z-index: 1;
}
The obvious drawback for this method is that the user cannot interact with anything inside the div we're preventSelecting. That includes links, buttons, images etc.
Please don't use this unless you absolutely have to. Frankly, it's a pain in the ass for everyone.

To be honest, if you don't want people to use any information on your site, then you can't put it up there. If you stop them from being able to copy and paste the information, they'll still be able to take a screenshot of it, type it out and save the data that way. I know it's not the answer you're looking for, but that's just something to think about.
(I did this because i can't comment yet).

Forget it. It is not possible to block these functions in a browser. The "best" you can do is to present your data in an image or Flash movie - inconceivable, slow, impractical, horrible to implement and also circumventable using OCR software.
If all else fails, users will simply make screen shots or key in the data manually.
If you present data to your users, you will have to live with the possibility that they can copy it. End of story.
Use legal threats to prevent your contents, not technical means.

You can't ever disable it.. users can view the source of your page so the text is always available. If you put click handlers to disable right-click, they can turn javascript off..
The best you can try to do is make it inconvenient for people to deter them, but never can you prevent them.

It is impossible to secure a website against copying. There are some technices to make it more difficult, but as soon as the user has the information on his screen its already too late. He could for example take a picture with a camera if the screenshot function could be disabled somehow.
Disabling of javascript functionality (f.e. shortcuts) is not working in all browsers and the user may disable javascript.
Using programs like curl all the information on the webpage can be grabbed.
Best thing you could do is to put all the information you present into an image.

What the developers of lyrics.com have done is attach events to document.body.oncontextmenu, document.onselectstart, and document.body.onkeydown to disable the actions browsers would take.
It can be done as simply as
<body oncontextmenu="return false" onselectstart="return false"
onkeydown="if ((arguments[0] || window.event).ctrlKey) return false">
You'd need all three; oncontextmenu basically governs right clicks, onselectstart covers drag-selecting with the mouse, and onkeydown Ctrl-key events (like someone who'd hit Ctrl+A, Ctrl+C to copy the whole page).
But I highly recommend that you NOT DO THIS. It kills usability and frustrates even legitimate users (for example people that have certain key mappings set up, or the ones who use "back" and "reload" from the context menu), and the ones you'd have to worry about would not be hindered even the slightest bit. And frankly, your content is not as special as you think it is, or you wouldn't be serving it up to any loser with a web browser. Information that valuable is not put online.
As has been noted before, all that return false stuff is not enforceable. And because i found the page particularly infuriating, that prompted me to pop up a console and dissect what they did, and detach event handlers so i could copy whatever i like and they don't even get their precious click-tracking data. Really, though, all anyone has to do is disable JavaScript.
The only way to keep people from copying text from the internet, is to keep it off the internet. Any other way is doomed to fail, as you yourself are handing them a copy as part of the very act of serving it to them.

You can stop from copy paste using below code
<body ondragstart="return false" onselectstart="return false">

<script type="text/javascript">
function md(e)
{
try { if (event.button==2||event.button==3) return false; }
catch (e) { if (e.which == 3) return false; }
}
document.oncontextmenu = function() { return false; }
document.ondragstart = function() { return false; }
document.onmousedown = md;
</script>
<br />

Try adding this css:
#content {
pointer-events: none;
}
This will deactivate mouse actions, thus copy-paste too.

Disable cut, copy, and paste options.
<script language="text/javascript">
// disable portal cut copy and paste options.
$('body').bind('cut copy paste', function (e) {
e.preventDefault();
});
</script>
But I prefer to enable this option on localhost.
<script language="text/javascript">
// disable portal cut copy and paste options.
$('body').bind('cut copy paste', function (e) {
// enable only localhost
if (location.hostname === "localhost" || location.hostname === "127.0.0.1")
{
return;
}
e.preventDefault();
});
</script>

please try this one its working for me...
$('body').bind('cut copy paste',function(e) {
e.preventDefault(); return false;
});

With Javascript you can disable copy/cut/drag for average users who don't know how to use inspect element feature, for that just add this simple javascript code:
document.addEventListener("copy", disable);
document.addEventListener("cut", disable);
document.addEventListener("drag", disable);
document.addEventListener("dragstart", disable);
document.addEventListener("dragover", disable);
document.addEventListener("dragend", disable);
document.addEventListener("drop", disable);
function disable(e) {
if (e) e.preventDefault();
return false;
}
If the user however tries to access the source code then you can't stop him, the best is to wrap each sentence in its own span to make it difficult for him to copy.

<script type="text/JavaScript">
function killCopy(e){
return false
}
function reEnable(){
return true
}
document.onselectstart=new Function ("return false")
if (window.sidebar){
document.onmousedown=killCopy
document.onclick=reEnable
}
</script>

I would suggest disabling right click.
<script language="text/javascript">
var message = "Not allowed.";
function rtclickcheck(keyp){
if (navigator.appName == "Netscape" && keyp.which == 3){
alert(message); return false;
}
if (navigator.appVersion.indexOf("MSIE") != -1 && event.button == 2) {
alert(message);
return false;
}
}
document.onmousedown = rtclickcheck;
</script>

Frame Buster Buster ... buster code needed

Let's say you don't want other sites to "frame" your site in an <iframe>:
<iframe src="http://example.org"></iframe>
So you insert anti-framing, frame busting JavaScript into all your pages:
/* break us out of any containing iframes */
if (top != self) { top.location.replace(self.location.href); }
Excellent! Now you "bust" or break out of any containing iframe automatically. Except for one small problem.
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://example.org/page-which-responds-with-204'
}
}, 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.onbeforeunload 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 navigate anywhere
My question is -- and this is more of a JavaScript puzzle than an actual problem -- how can you defeat the frame-busting buster?
I had a few thoughts, but nothing worked in my testing:
attempting to clear the onbeforeunload event via onbeforeunload = null had no effect
adding an alert() stopped the process let the user know it was happening, but did not interfere with the code in any way; clicking OK lets the busting continue as normal
I can't think of any way to clear the setInterval() timer
I'm not much of a JavaScript programmer, so here's my challenge to you: hey buster, can you bust the frame-busting buster?

FWIW, most current browsers support the X-Frame-Options: deny directive, which works even when script is disabled.
IE8:
http://blogs.msdn.com/ie/archive/2009/01/27/ie8-security-part-vii-clickjacking-defenses.aspx
Firefox (3.6.9)
https://bugzilla.mozilla.org/show_bug.cgi?id=475530
https://developer.mozilla.org/en/The_X-FRAME-OPTIONS_response_header
Chrome/Webkit
http://blog.chromium.org/2010/01/security-in-depth-new-security-features.html
http://trac.webkit.org/changeset/42333

I'm not sure if this is viable or not - but if you can't break the frame, why not just display a warning. For example, If your page isn't the "top page" create a setInterval method that tries to break the frame. If after 3 or 4 tries your page still isn't the top page - create a div element that covers the whole page (modal box) with a message and a link like...
You are viewing this page in a unauthorized frame window - (Blah blah... potential security issue)
click this link to fix this problem
Not the best, but I don't see any way they could script their way out of that.

We have used the following approach in one of our websites from http://seclab.stanford.edu/websec/framebusting/framebust.pdf
<style>
body {
display : none
}
</style>
<script>
if(self == top) {
document.getElementsByTagName("body")[0].style.display = 'block';
}
else{
top.location = self.location;
}
</script>

Came up with this, and it seems to work at least in Firefox and the Opera browser.
if(top != self) {
top.onbeforeunload = function() {};
top.location.replace(self.location.href);
}

Considering current HTML5 standard that introduced sandbox for iframe, all frame busting codes that provided in this page can be disabled when attacker uses sandbox because it restricts the iframe from following:
allow-forms: Allow form submissions.
allow-popups: Allow opening popup windows.
allow-pointer-lock: Allow access to pointer movement and pointer lock.
allow-same-origin: Allow access to DOM objects when the iframe loaded form same origin
allow-scripts: Allow executing scripts inside iframe
allow-top-navigation: Allow navigation to top level window
Please see: http://www.whatwg.org/specs/web-apps/current-work/multipage/the-iframe-element.html#attr-iframe-sandbox
Now, consider attacker used the following code to host your site in iframe:
<iframe src="URI" sandbox></iframe>
Then, all JavaScript frame busting code will fail.
After checking all frame busing code, only this defense works in all cases:
<style id="antiClickjack">body{display:none !important;}</style>
<script type="text/javascript">
if (self === top) {
var antiClickjack = document.getElementById("antiClickjack");
antiClickjack.parentNode.removeChild(antiClickjack);
} else {
top.location = self.location;
}
</script>
that originally proposed by Gustav Rydstedt, Elie Bursztein, Dan Boneh, and Collin Jackson (2010)

After pondering this for a little while, I believe this will show them who's boss...
if(top != self) {
window.open(location.href, '_top');
}
Using _top as the target parameter for window.open() will launch it in the same window.

As of 2015, you should use CSP2's frame-ancestors directive for this. This is implemented via an HTTP response header.
e.g.
Content-Security-Policy: frame-ancestors 'none'
Of course, not many browsers support CSP2 yet so it is wise to include the old X-Frame-Options header:
X-Frame-Options: DENY
I would advise to include both anyway, otherwise your site would continue to be vulnerable to Clickjacking attacks in old browsers, and of course you would get undesirable framing even without malicious intent. Most browsers do update automatically these days, however you still tend to get corporate users being stuck on old versions of Internet Explorer for legacy application compatibility reasons.

All the proposed solutions directly force a change in the location of the top window. What if a user wants the frame to be there? For example the top frame in the image results of search engines.
I wrote a prototype where by default all inputs (links, forms and input elements) are disabled and/or do nothing when activated.
If a containing frame is detected, the inputs are left disabled and a warning message is shown at the top of the page. The warning message contains a link that will open a safe version of the page in a new window. This prevents the page from being used for clickjacking, while still allowing the user to view the contents in other situations.
If no containing frame is detected, the inputs are enabled.
Here is the code. You need to set the standard HTML attributes to safe values and add additonal attributes that contain the actual values. It probably is incomplete and for full safety additional attributes (I am thinking about event handlers) will probably have to be treated in the same way:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<html>
<head>
<title></title>
<script><!--
function replaceAttributeValuesWithActualOnes( array, attributeName, actualValueAttributeName, additionalProcessor ) {
for ( var elementIndex = 0; elementIndex < array.length; elementIndex += 1 ) {
var element = array[ elementIndex ];
var actualValue = element.getAttribute( actualValueAttributeName );
if ( actualValue != null ) {
element[ attributeName ] = actualValue;
}
if ( additionalProcessor != null ) {
additionalProcessor( element );
}
}
}
function detectFraming() {
if ( top != self ) {
document.getElementById( "framingWarning" ).style.display = "block";
} else {
replaceAttributeValuesWithActualOnes( document.links, "href", "acme:href" );
replaceAttributeValuesWithActualOnes( document.forms, "action", "acme:action", function ( form ) {
replaceAttributeValuesWithActualOnes( form.elements, "disabled", "acme:disabled" );
});
}
}
// -->
</script>
</head>
<body onload="detectFraming()">
<div id="framingWarning" style="display: none; border-style: solid; border-width: 4px; border-color: #F00; padding: 6px; background-color: #FFF; color: #F00;">
<div>
<b>SECURITY WARNING</b>: Acme App is displayed inside another page.
To make sure your data is safe this page has been disabled.<br>
Continue working safely in a new tab/window
</div>
</div>
<p>
Content. Do something
</p>
<form name="acmeForm" action="#" acme:action="real-action.html">
<p>Name: <input type="text" name="name" value="" disabled="disabled" acme:disabled=""></p>
<p><input type="submit" name="save" value="Save" disabled="disabled" acme:disabled=""></p>
</form>
</body>
</html>

if (top != self) {
top.location.replace(location);
location.replace("about:blank"); // want me framed? no way!
}

I'm going to be brave and throw my hat into the ring on this one (ancient as it is), see how many downvotes I can collect.
Here is my attempt, which does seem to work everywhere I have tested it (Chrome20, IE8 and FF14):
(function() {
if (top == self) {
return;
}
setInterval(function() {
top.location.replace(document.location);
setTimeout(function() {
var xhr = new XMLHttpRequest();
xhr.open(
'get',
'http://mysite.tld/page-that-takes-a-while-to-load',
false
);
xhr.send(null);
}, 0);
}, 1);
}());
I placed this code in the <head> and called it from the end of the <body> to ensure my page is rendered before it starts arguing with the malicious code, don't know if this is the best approach, YMMV.
How does it work?
...I hear you ask - well the honest answer is, I don't really know. It took a lot of fudging about to make it work everywhere I was testing, and the exact effect that it has varies slightly depending on where you run it.
Here is the thinking behind it:
Set a function to run at the lowest possible interval. The basic concept behind any of the realistic solutions I have seen is to fill up the scheduler with more events than the frame buster-buster has.
Every time the function fires, try and change the location of the top frame. Fairly obvious requirement.
Also schedule a function to run immediately which will take a long time to complete (thereby blocking the frame buster-buster from interfering with the location change). I chose a synchronous XMLHttpRequest because it's the only mechanism I can think of that doesn't require (or at least ask for) user interaction and doesn't chew up the user's CPU time.
For my http://mysite.tld/page-that-takes-a-while-to-load (the target of the XHR) I used a PHP script that looks like this:
<?php sleep(5);
What happens?
Chrome and Firefox wait the 5 seconds while the XHR completes, then successfully redirect to the framed page's URL.
IE redirects pretty much immediately
Can't you avoid the wait time in Chrome and Firefox?
Apparently not. At first I pointed the XHR to a URL that would return a 404 - this didn't work in Firefox. Then I tried the sleep(5); approach that I eventually landed on for this answer, then I started playing around with the sleep length in various ways. I could find no real pattern to the behaviour, but I did find that if it is too short, specifically Firefox will not play ball (Chrome and IE seem to be fairly well behaved). I don't know what the definition of "too short" is in real terms, but 5 seconds seems to work every time.
If any passing Javascript ninjas want to explain a little better what's going on, why this is (probably) wrong, unreliable, the worst code they've ever seen etc I'll happily listen.

Ok, so we know that were in a frame. So we location.href to another special page with the path as a GET variable. We now explain to the user what is going on and provide a link with a target="_TOP" option. It's simple and would probably work (haven't tested it), but it requires some user interaction. Maybe you could point out the offending site to the user and make a hall of shame of click jackers to your site somewhere.. Just an idea, but it night work..

Well, you can modify the value of the counter, but that is obviously a brittle solution. You can load your content via AJAX after you have determined the site is not within a frame - also not a great solution, but it hopefully avoids firing the on beforeunload event (I am assuming).
Edit: Another idea. If you detect you are in a frame, ask the user to disable javascript, before clicking on a link that takes you to the desired URL (passing a querystring that lets your page know to tell the user that they can re-enable javascript once they are there).
Edit 2: Go nuclear - if you detect you are in a frame, just delete your document body content and print some nasty message.
Edit 3: Can you enumerate the top document and set all functions to null (even anonymous ones)?

If you add an alert right after the buster code, then the alert will stall the javascript thread, and it will let the page load. This is what StackOverflow does, and it busts out of my iframes, even when I use the frame busting buster. It also worked with my simple test page. This has only been tested in Firefox 3.5 and IE7 on windows.
Code:
<script type="text/javascript">
if (top != self){
top.location.replace(self.location.href);
alert("for security reasons bla bla bla");
}
</script>

I think you were almost there. Have you tried:
window.parent.onbeforeunload = null;
window.parent.location.replace(self.location.href);
or, alternatively:
window.parent.prevent_bust = 0;
Note: I didn't actually test this.

If you look at the values returned by setInterval() they are usually single digits, so you can usually disable all such interrupts with a single line of code:
for (var j = 0 ; j < 256 ; ++j) clearInterval(j)

What about calling the buster repeatedly as well? This'll create a race condition, but one may hope that the buster comes out on top:
(function() {
if(top !== self) {
top.location.href = self.location.href;
setTimeout(arguments.callee, 0);
}
})();

I might just have just gotten a way to bust the frame buster buster javascript. Using the getElementsByName in my javascript function, i've set a loop between the frame buster and the actual frame buster buster script.
check this post out. http://www.phcityonweb.com/frame-buster-buster-buster-2426

setInterval and setTimeout create an automatically incrementing interval. Each time setTimeout or setInterval is called, this number goes up by one, so that if you call setTimeout, you'll get the current, highest value.
var currentInterval = 10000;
currentInterval += setTimeout( gotoHREF, 100 );
for( var i = 0; i < currentInterval; i++ ) top.clearInterval( i );
// Include setTimeout to avoid recursive functions.
for( i = 0; i < currentInterval; i++ ) top.clearTimeout( i );
function gotoHREF(){
top.location.href = "http://your.url.here";
}
Since it is almost unheard of for there to be 10000 simultaneous setIntervals and setTimeouts working, and since setTimeout returns "last interval or timeout created + 1", and since top.clearInterval is still accessible, this will defeat the black-hat attacks to frame websites which are described above.

Use htaccess to avoid high-jacking frameset, iframe and any content like images.
RewriteEngine on
RewriteCond %{HTTP_REFERER} !^http://www\.yoursite\.com/ [NC]
RewriteCond %{HTTP_REFERER} !^$
RewriteRule ^(.*)$ /copyrights.html [L]
This will show a copyright page instead of the expected.

You could improve the whole idea by using the postMessage() method to allow some domains to access and display your content while blocking all the others. First, the container-parent must introduce itself by posting a message to the contentWindow of the iframe that is trying to display your page. And your page must be ready to accept messages,
window.addEventListener("message", receiveMessage, false);
function receiveMessage(event) {
// Use event.origin here like
if(event.origin == "https://perhapsyoucantrustthisdomain.com"){
// code here to block/unblock access ... a method like the one in user1646111's post can be good.
}
else{
// code here to block/unblock access ... a method like the one in user1646111's post can be good.
}
}
Finally don't forget to wrap things inside functions that will wait for load events.