Clickjacking – ClickJacking

Scene repeat: After Xiao Li logs in to a website, an “interesting” link pops up soon. Under the trend of curiosity, Xiao Li opens the link… “, followed the prompts point to point, finally nothing to see, nothing accomplished. Depressed after closing the link address, I was surprised to find that I had logged in to the website page more than a few lines of operation records, and the operation records are their own! Explosion of mentality…

Do a bunch of things happen with a user click, but the user doesn't know what's going on?Copy the code

harm

  • Impersonating the user operation
  • Access to sensitive user information (email)
  • Steal users’ funds (transfer, consumption)

Features:

  • User operation
  • The users themselves don’t know

The attack takes advantage of the transparent nature of the

Case analysis

After logging in a website, a pop-up section of “click and beauty chat link “, when the user clicked the” chat with beauty “link, in the blog has been logged in to publish a post…

<! doctype html><html>
	<head>
		<meta charset="utf-8"/>
		<title>clickhijack</title>
	</head>
        <! -- Background is a local interesting image -->
	<body style="background:url(clickjacking.jpeg) no-repeat; background-size: cover;">
            <! SRC is the nodeJS project that I started locally.
		<iframe style="Opacity: 0.3" src="http://localhost:3000/post/1" width="1260" height="600"></iframe>
	</body>
</html>
Copy the code

The page should look like this:

This is what the page actually looks like: the opacity of the iframe has been changed to 0.5

Of course, a real attack page would be rich and engaging. The author does demonstration only here, attack idea is the same.

Attack defense

According to the case analysis, click hijacking is based on IFrame, and our defense should also be based on this.

JavaScript forbids embedding

HTML DOM top attribute

Definitions and Usage

The Top property returns the top-level browser window for the current window.

This property returns a read-only reference to a top-level window. If the window itself is a top-level window, the top property holds a reference to the window itself. If the window is a frame, the top property refers to the top-level window that contains the frame.

The instance

The following example shows whether the window is in a frame, and if so, out of the frame;

<! The following example comes from W3c -->
<html>
<head>
    <script type="text/javascript">
        function breakout() {
            if (window.top ! =window.self) {
                window.top.location = "test.html"}}</script>
</head>
<body>
    <form>
        Click the button to break out of the frame:
        <input type="button" onclick="breakout()" value="Break out!">
    </form>
</body>
</html>
Copy the code

Knowing the top property, we can apply the top property to clickjacking.

Code implementation:

Normal page top vs. Window:

top
>Window {window: Window, self: Window, document: document.name: "".location: the Location,... } top.location >Location {ancestorOrigins: DOMStringList, href: "http://localhost:3000/post/1".origin: "http://localhost:3000".protocol: "http:".host: "localhost:3000",... }window
>Window {window: Window, self: Window, document: document.name: "".location: the Location,... } top===window
>true
Copy the code

Click the hijacked page top attribute and window attribute comparison:

top
>global {0: Window, window: global.self: global.location: {... },closed: false.frames: global,... } top.location >{then: undefined.Symbol(Symbol.toStringTag): undefined.Symbol(Symbol.hasInstance): undefined.Symbol(Symbol.isConcatSpreadable): undefined.replace: ƒ}
window
>Window {window: Window, self: Window, document: document.name: "".location: the Location,... } top===window
//false
Copy the code

Based on the above differences, the sample code is as follows:

<script type="text/javascript">
if(top.location ! = windowlocation) { top.location =window.location
}
</script>
Copy the code

This seems to solve the clickjacking problem, but is it really 100%? The answer is definitely no. As long as you can disable the execution of the script will trigger the attack again! The Sandbox in iframe does just that.

HTML <iframe>The Sandbox property of the tag

Definitions and Usage

If specified as an empty string (sandbox=””), the sandbox property will enable a number of additional restrictions on the contents of the inline frame.

The value of the sandbox attribute can be either an empty string (where all restrictions apply) or a space-delimited list of predefined values (where specific restrictions are removed).

grammar

<iframe sandbox="value">
Copy the code

Attribute values

value describe
“” Apply all of the following restrictions.
allow-same-origin Allows iframe content to be treated as having the same source as the contained document.
allow-top-navigation Allows iframe content to navigate (load) content from the include document.
allow-forms Allow form submission.
allow-scripts Allows script execution.

Once we understand the Sanbox properties, we can set the properties to trigger the attack again! Example:

<iframe style="Opacity: 0.3" src="http://localhost:3000/post/1" width="1260" height="600" sandbox="allow-forms"></iframe>
<! Allow the form to submit the event, the rest is disallowed -->
Copy the code

This is the time to start clicking hijack attacks again!

X-frame_options Disables inline embedding

The X-frame-options HTTP response header is a flag used to indicate to The browser whether to allow a page to be displayed in < Frame >,

Grammar:

X-frame-options has three possible values

X-Frame-Options: deny
X-Frame-Options: sameorigin
X-Frame-Options: allow-from https://example.com/
Copy the code

Attribute values

value describe
deny Indicates that the page cannot be displayed in frame, even if the page is nested with the same domain name
sameorigin The page can be displayed in the frame of the same domain name page.
allow-from uri Indicates that the page can be displayed in a frame from the specified source.

Example:

Note: Setting meta tags is invalid! For example, there is no effect. Don’t use it like that! This works only if the HTTP header X-frame-options is set as in the following example.

Configure the Apache

To set x-frame-options to deny for the Apache configuration, set your site as follows:

Header set X-Frame-Options “deny”

To set x-frame-options to allow-from in the Apache configuration, add:

Header set X-Frame-Options “allow-from example.com/”

Configure nginx

Configure nginx to send the x-frame-options response header and add the following line to the configuration for ‘HTTP ‘, ‘server’ or ‘location’ :

add_header X-Frame-Options sameorigin always;

Configure the NODEJS_KOA framework

Sample code:

// Prohibit embedding of pages that may be attacked directly ->DENY
router.all('/ *'.async function(ctx, next){
	ctx.set('X-Frame-Options'.'DENY')
	await next();
});
Copy the code

Browser compatibility

The X-Frame_options browser is compatible and can be used with confidence. For details on compatibility, please refer to the X-frame_options reference at the end of this article

Other auxiliary means

  • Add check Code
  • Adding verification SMS messages

.

The resources

W3school-

conclusion

Click hijacking is critical to WEB security. This is especially true for iframe nested projects. This paper records the author in the development process encountered problems caused by the thinking and exploration. For the reference of readers with similar problems. Other security aspects of the article I will continue to update, welcome readers to put forward comments and suggestions.