Clickjacking is a type of attack where the attacker sets up a page so that a user's click on the page performs a different action than the one the user intends. It gets it's name because the attacker has "hijacked a click".
There are many techniques that can be used to trick the user. Most of them involve the hacker being able to add HTML, CSS, or JavaScript to a web page. Cross-Site Scripting is the primary way this is accomplished. Often, the hijacking code will be added within an iframe, so that it stays separate from the page code, in an attempt to avoid detection.
The simplest version is to put an invisible link over a regular link. Imagine a web page with an embedded video. The user clicks on the video's "play" button. But the click does not start the video, it never gets to the video player. Instead the user has just clicked on a hidden link on a transparent overlay over the page. Most of the time the user will not even know they have triggered the link because it targets a hidden iframe. The results of the linked page will be hidden from view. The user will simply think the link didn't work on the first click.
The link could trigger many actions. Some common ones are:
Cursorjacking is a variation on clickjacking. Instead of "intercepting" a click, the attacker alters the cursor's actual location from the location the user perceives. For example, a click might register 100 pixels to the left of where the cursor appears to be.
As an example of how this could be useful, imagine a dialog box that pops up with a choice for the user to make: "Enable web cam" and "Cancel". A user thinks the cursor is over "Cancel" and clicks, but the click registers on the "Enable web cam" button.
The best defense if to put good Cross-Site Scripting protections in place. XSS is the primary way an attacker can modify a page.
Another prevention to add is to disallow the frames and iframes that help attackers hide code and the results of their manipulation. There are two easy ways to do that.
Define a Content Security Policy and set the frame-ancestors directive to disallow loading frame and iframe content on the page. If a page must use frames, then whitelist the sources for the frame content.
Configure the webserver (or your application code) to set the response header for "X-Frame-Options" to "Deny" or at least "SameOrigin".
In addition, users can take precautions of their own. They can install browser plugins, such as NoScript, which disable or reveal unexpected JavaScript.
