Detailed explanation of front-end security: JavaScript anti-http hijacking and XSS

HTTP hijacking, DNS hijacking and XSS

Let me first briefly explain what HTTP hijacking and DNS hijacking are.

HTTP Hijacking

What is HTTP hijacking? In most cases, it is operator HTTP hijacking. When we use HTTP request to request a website page, the network operator will insert carefully designed network data packets into the normal data stream to make the client (usually a browser) display "wrong" data, usually some pop-ups, promotional ads or directly display the content of a certain website. Everyone should have encountered it.

DNS Hijacking

DNS hijacking is to hijack the DNS server, gain control of the resolution record of a domain name through certain means, and then modify the resolution result of this domain name, causing the access to the domain name to be transferred from the original IP address to the modified specified IP address. As a result, the specific URL cannot be accessed or the URL accessed is a fake URL, thereby achieving the purpose of stealing data or destroying the original normal service.

DNS hijacking is more extreme than HTTP hijacking. Simply put, our request is http://www.a.com/index.html, but it is directly redirected to http://www.b.com/index.html. This article will not discuss this situation in detail.

XSS Cross-site scripting

XSS refers to an attacker exploiting a vulnerability to inject malicious code into a web page. When a user browses the page, the injected code will be executed, thereby achieving the specific purpose of the attack.

This article does not discuss how these attacks are generated or how attackers inject malicious code into the page. It is sufficient to know that HTTP hijacking and XSS are ultimately malicious codes executed on the client side, usually the user's browser. This article will discuss how to use Javascript for effective front-end protection, assuming that the injection already exists.

The page is embedded in an iframe, redirecting the iframe

Let's first talk about the situation where our page is embedded in an iframe. That is, in order to minimize the impact of embedded advertisements on the original website pages, network operators usually place the original website pages in an iframe of the same size as the original page, so that the iframe can be used to isolate the impact of the advertisement code on the original page.

This situation is relatively easy to handle. We just need to know whether our page is nested in an iframe. If so, redirect the outer page to our normal page.

So is there any way to know that our page currently exists in an iframe? Yes, they are window.self and window.top.

window.self

Returns a reference to the current window object.

window.top

Returns a reference to the topmost window in the window hierarchy.

For non-same-origin domain names, the iframe child page cannot obtain the specific page address through parent.location or top.location, but can write to top.location, which means that it can control the jump of the parent page.

The two attributes can be abbreviated as self and top respectively, so when we find that our page is nested in an iframe, we can redirect the parent page:

if (self != top) {
  // Our normal page var url = location.href;
  // Parent page redirection top.location = url;
}

Use whitelist to allow normal iframe nesting

Of course, many times, perhaps due to operational needs, our pages will be promoted in various ways, or they may be nested in iframes for normal business needs. At this time, we need a whitelist or blacklist. When our page is nested in an iframe and the parent page domain name is in the whitelist, no redirection operation will be performed.

As mentioned above, you cannot get the URL of the parent page by using top.location.href. In this case, you need to use document.referrer.

The URL of the cross-domain iframe parent page can be obtained through document.referrer.

// Create a whitelist var whiteList = [
  'www.aaa.com',
  'res.bbb.com'
];
 
if (self != top) {
  var
    // Use document.referrer to get the URL of the parent page of the cross-domain iframe
    parentUrl = document.referrer,
    length = whiteList.length,
    i = 0;
 
  for(; i<length; i++){
    // Create a whitelist regular expression var reg = new RegExp(whiteList[i],'i');
 
    // Exists in the whitelist, release if(reg.test(parentUrl)){
      return;
    }
  }
 
  // Our normal page var url = location.href;
  // Parent page redirection top.location = url;
}

Change URL parameters to bypass operator tags

Is that all? No, although we redirected the parent page, during the redirection process, since it was nested the first time, the page may be nested by iframe again during this redirection process, which is really annoying.

Of course, this kind of hijacking by operators usually leaves traces. The most common method is to set a parameter in the page URL, such as http://www.example.com/index.html?iframe_hijack_redirected=1, where iframe_hijack_redirected=1 means that the page has been hijacked and the iframe is no longer nested. So based on this feature, we can rewrite our URL to make it look like it has been hijacked:

var flag = 'iframe_hijack_redirected';
// The current page exists in an iframe // A whitelist matching rule needs to be established here, and the whitelist is released by default if (self != top) {
  var
    // Use document.referrer to get the URL of the parent page of the cross-domain iframe
    parentUrl = document.referrer,
    length = whiteList.length,
    i = 0;
 
  for(; i<length; i++){
    // Create a whitelist regular expression var reg = new RegExp(whiteList[i],'i');
 
    // Exists in the whitelist, release if(reg.test(parentUrl)){
      return;
    }
  }
 
  var url = location.href;
  var parts = url.split('#');
  if (location.search) {
    parts[0] += '&' + flag + '=1';
  } else {
    parts[0] += '?' + flag + '=1';
  }
  try {
    console.log('The page is embedded in an iframe:', url);
    top.location.href = parts.join('#');
  } catch (e) {}
}

Of course, if this parameter is changed, the anti-nesting code will become invalid. Therefore, we also need to establish a reporting system. When we find that a page is nested, we will send an interception report. Even if the redirection fails, we can know the URL of the page embedded in the iframe. By analyzing these URLs, we can continuously enhance our protection measures, which will be mentioned later.

Inline events and inline script interception

In XSS, there are actually many ways to inject scripts, especially after the release of HTML5. If you are not careful, many new tags can be used to inject executable scripts.

List some common injection methods:

1. <a href="javascript:alert(1)" rel="external nofollow" _fcksavedurl="javascript:alert(1)" ></a>

2. <iframe src="javascript:alert(1)" />

3. <img src='x' onerror="alert(1)" />

4. <video src='x' onerror="alert(1)" ></video>

5. <div onmouseover="alert(2)" ><div>

Except for some very rare and obscure injection methods that are not listed here, most of them are javascript:... and inline events on*.

Assuming that the injection has already occurred, is there any way to intercept the execution of these inline events and inline scripts?

For the scripts (1) and (5) listed above that require the user to click or perform some event before they are executed, we have ways to defend against them.

Browser event model

The ability to intercept mentioned here involves the principles related to the event model.

We all know that the standard browser event model has three stages:

• Capture Phase
• Target Phase
• Bubbling stage

For an a tag like <a href="javascript:alert(222)" rel="external nofollow" rel="external nofollow" _fcksavedurl="javascript:alert(222)" ></a>, the element alert(222) that actually triggers is in the target phase of the click event.

<a href="javascript:alert(222)" rel="external nofollow" rel="external nofollow" >Click Me</a>

<script>
  document.addEventListener('click', function(e) {
    alert(111);
  }, true);
</script>

Click click me above, 111 will pop up first, then 222.

Then, we only need to create a keyword blacklist for the javascript:... content in the tag during the capture phase of the click event model, and filter and review it to achieve the interception effect we want.

The same is true for on* type inline events, but there are too many such events and we cannot enumerate them manually. We can use code to automatically enumerate and intercept inline events and inline scripts.

Taking the interception of href="javascript:... in the a tag as an example, we can write it like this:

// Create a keyword blacklist var keywordBlackList = [
  'xss',
  'BAIDU_SSP__wrapper',
  'BAIDU_DSPUI_FLOWBAR'
];
   
document.addEventListener('click', function(e) {
  var code = "";
 
  // Scan for scripts for <a href="javascript:" rel="external nofollow" > if (elem.tagName == 'A' && elem.protocol == 'javascript:') {
    var code = elem.href.substr(11);
 
    if (blackListMatch(keywordBlackList, code)) {
      // Logout code elem.href = 'javascript:void(0)';
      console.log('Intercept suspicious events:' + code);
    }
  }
}, true);
 
/**
 * [Blacklist Match]
 * @param {[Array]} blackList [blacklist]
 * @param {[String]} value [String to be verified]
 * @return {[Boolean]} [false -- verification failed, true -- verification passed]
 */
function blackListMatch(blackList, value) {
  var length = blackList.length,
    i = 0;
 
  for (; i < length; i++) {
    // Create a blacklist regular expression var reg = new RegExp(whiteList[i], 'i');
 
    // Exists in blacklist, intercept if (reg.test(value)) {
      return true;
    }
  }
  return false;
}

Click on the buttons in the picture to see the following:

Here we use blacklist matching, which will be explained in detail below.

Static script blocking

The essence of XSS cross-site scripting is not "cross-site", but "scripting".

Generally speaking, attackers or operators will inject a <script> script into the page, and all specific operations are implemented in the script. This hijacking method only needs to be injected once, and if there are changes, there is no need to re-inject it every time.

We assume that a <script src="http://attack.com/xss.js"> script is injected into the page, and our goal is to intercept the execution of this script.

It sounds difficult. What does it mean? The purpose is to detect the suspicious script before it is executed and destroy it so that it cannot execute the internal code.

So we need to use some advanced APIs to detect the generated nodes when the page is loaded.

MutationObserver

MutationObserver is a powerful new API added in HTML5. It provides developers with the ability to respond appropriately when a DOM tree within a certain range changes.

It sounds very mysterious, but it roughly means that it can monitor the changes of the page DOM tree and respond accordingly.

MutationObserver()This constructor is used to instantiate a new Mutation observer object.

MutationObserver
  function callback
);

I was stunned. What was this long paragraph about? This means that when MutationObserver observes, it does not call back immediately when it finds a new element, but instead passes all the elements that appear in a time segment together. So we need to do batch processing in the callback. Moreover, the callback will be called when the specified DOM node (target node) changes. When called, the observer object will pass two parameters to the function. The first parameter is an array containing several MutationRecord objects, and the second parameter is the observer object itself.

Therefore, using MutationObserver, we can monitor each static script file loaded by the page:

// Different compatibility writing methods of MutationObserver var MutationObserver = window.MutationObserver || window.WebKitMutationObserver ||
window.MozMutationObserver;
// This constructor is used to instantiate a new Mutation observer object // Mutation observer objects can monitor DOM tree changes within a certain range var observer = new MutationObserver(function(mutations) {
  mutations.forEach(function(mutation) {
    // Returns the added node, or null.
    var nodes = mutation.addedNodes;
 
    for (var i = 0; i < nodes.length; i++) {
      var node = nodes[i];
      if (/xss/i.test(node.src))) {
        try {
          node.parentNode.removeChild(node);
          console.log('Intercept suspicious static scripts:', node.src);
        } catch (e) {}
      }
    }
  });
});
 
// Pass in the target node and observation options // If target is document or document.documentElement
// All node addition and deletion operations in the current document will be observed observer.observe(document, {
  subtree: true,
  childList: true
});

<script type="text/javascript" src="./xss/a.js"></script> is a static script that exists at the beginning of page loading (see page structure). We use MutationObserver to perform regular expression matching on its content during the period between script loading and execution. If malicious code is found, removeChild() is used to make it impossible to execute.

Use whitelist to match src

In the above code, we use this sentence to determine whether a js script is malicious:

if (/xss/i.test(node.src)) {}

Of course, in reality, the person who injects malicious code will not be so stupid as to change the name to XSS. Therefore, it is necessary for us to use a whitelist for filtering and establish an interception and reporting system.

// Create a whitelist var whiteList = [
  'www.aaa.com',
  'res.bbb.com'
];
 
/**
 * [Whitelist matching]
 * @param {[Array]} whileList [whitelist]
 * @param {[String]} value [String to be verified]
 * @return {[Boolean]} [false -- verification failed, true -- verification passed]
 */
function whileListMatch(whileList, value) {
  var length = whileList.length,
    i = 0;
 
  for (; i < length; i++) {
    // Create a whitelist regular expression var reg = new RegExp(whiteList[i], 'i');
 
    // Exists in the whitelist, release if (reg.test(value)) {
      return true;
    }
  }
  return false;
}
 
// Only release whitelist if (!whileListMatch(blackList, node.src)) {
  node.parentNode.removeChild(node);
}

We have mentioned whitelist matching several times here, and it will be used again below, so we can simply encapsulate it into a method call here.

Dynamic script blocking

MutationObserver is used above to intercept static scripts. In addition to static scripts, the corresponding ones are dynamically generated scripts.

var script = document.createElement('script');
script.type = 'text/javascript';
script.src = 'http://www.example.com/xss/b.js';
 
document.getElementsByTagName('body')[0].appendChild(script);

To intercept this type of dynamically generated script, and the interception time should be when it is inserted into the DOM tree and before execution, you can listen to the DOMNodeInserted event in Mutation Events.

Mutation Events and DOMNodeInserted

Open MDN, the first sentence is:

This feature has been removed from the Web standard. Although some browsers still support it, they may stop supporting it at some point in the future. Please try not to use this feature.

Although it is not available, you can still understand:

document.addEventListener('DOMNodeInserted', function(e) {
  var node = e.target;
  if (/xss/i.test(node.src) || ​​/xss/i.test(node.innerHTML)) {
    node.parentNode.removeChild(node);
    console.log('Intercept suspicious dynamic scripts:', node);
  }
}, true);

Unfortunately, the above code can intercept dynamically generated scripts, but the code is also executed: DOMNodeInserted, as the name implies, can monitor structural changes within a DOM range. Compared with MutationObserver, it is executed earlier.

However, DOMNodeInserted is no longer recommended, so the task of monitoring dynamic scripts should also be handed over to MutationObserver.

Unfortunately, in actual practice, the result of using MutationObserver is the same as DOMNodeInserted. It can monitor and intercept the generation of dynamic scripts, but it cannot be removed using removeChild before the script is executed, so we need to think of other ways.

Override setAttribute and document.write

Override the native Element.prototype.setAttribute method

Before the dynamic script is inserted and executed, it is not possible to intercept it by monitoring the changes in the DOM tree, and the script will still be executed.

Then we need to look up and capture the script before it is inserted into the DOM tree, which is when the script is created.

Suppose now there is a dynamic script created like this:

var script = document.createElement('script');
script.setAttribute('type', 'text/javascript');
script.setAttribute('src', 'http://www.example.com/xss/c.js');
 
document.getElementsByTagName('body')[0].appendChild(script);

It is also possible to rewrite Element.prototype.setAttribute: we find that the setAttribute method is used here. If we can rewrite this native method, listen to the value when setting the src attribute, and judge it through the blacklist or whitelist, we can determine the legitimacy of the tag.

// Save the original interface var old_setAttribute = Element.prototype.setAttribute;
 
// Rewrite setAttribute interface Element.prototype.setAttribute = function(name, value) {
 
  // Match to <script src='xxx' > type if (this.tagName == 'SCRIPT' && /^src$/i.test(name)) {
    // Whitelist matchingif (!whileListMatch(whiteList, value)) {
      console.log('Intercept suspicious modules:', value);
      return;
    }
  }
   
  //Call the original interface old_setAttribute.apply(this, arguments);
};
 
// Create a whitelist var whiteList = [
'www.yy.com',
'res.cont.yy.com'
];
 
/**
 * [Whitelist matching]
 * @param {[Array]} whileList [whitelist]
 * @param {[String]} value [String to be verified]
 * @return {[Boolean]} [false -- verification failed, true -- verification passed]
 */
function whileListMatch(whileList, value) {
  var length = whileList.length,
    i = 0;
 
  for (; i < length; i++) {
    // Create a whitelist regular expression var reg = new RegExp(whiteList[i], 'i');
 
    // Exists in the whitelist, release if (reg.test(value)) {
      return true;
    }
  }
  return false;
}

Rewrite Element.prototype.setAttribute, that is, first save the original interface, and then when an element calls setAttribute, check whether the passed src exists in the whitelist. If it exists, it will be released. If not, it will be regarded as a suspicious element, reported and not executed. Finally, the native setAttribute is executed on the released elements, that is, old_setAttribute.apply(this, arguments);.

The above whitelist matching can also be replaced by blacklist matching.

Override Element.prototype.setAttribute inside a nested iframe

Of course, if old_setAttribute = Element.prototype.setAttribute is exposed to an attacker, using old_setAttribute directly can bypass our overridden method, so this code must be wrapped in a closure.

Of course, this is not safe, although Element.prototype.setAttribute in the current window has been overridden. But there is still a way to get the native Element.prototype.setAttribute, all it takes is a new iframe.

var newIframe = document.createElement('iframe');
document.body.appendChild(newIframe);
 
Element.prototype.setAttribute = newIframe.contentWindow.Element.prototype.setAttribute;

Through this method, you can get the native Element.prototype.setAttribute again, because the environment inside the iframe and the outer window are completely isolated. wtf?

what to do? We see that createElement is used to create an iframe, so is it possible to rewrite the native createElement? But in addition to createElement, there is also createElementNS, and it is possible that an iframe already exists on the page, so it is not appropriate.

Then whenever a new iframe is created, setAttribute is protected and rewritten, and MutationObserver is used again here:

/**
 * Use MutationObserver to monitor the generated iframe page,
 * Prevent calling internal native setAttribute and document.write
 * @return {[type]} [description]
 */
function defenseIframe() {
  // Protect the current page first installHook(window);
}
 
/**
 * Implement setAttribute protection for a single window* @param {[BOM]} window [browser window object]
 * @return {[type]} [description]
 */
function installHook(window) {
  // Rewrite the setAttribute property of a single window resetSetAttribute(window);
 
  // Different compatibility writing methods of MutationObserver var MutationObserver = window.MutationObserver || window.WebKitMutationObserver || window.MozMutationObserver;
 
  // This constructor is used to instantiate a new Mutation observer object // Mutation observer objects can monitor DOM tree changes within a certain range var observer = new MutationObserver(function(mutations) {
    mutations.forEach(function(mutation) {
      // Returns the added node, or null.
      var nodes = mutation.addedNodes;
 
      // Traverse one by one for (var i = 0; i < nodes.length; i++) {
        var node = nodes[i];
 
        // Install the rewrite hook in the generated iframe environment if (node.tagName == 'IFRAME') {
          installHook(node.contentWindow);
        }
      }
    });
  });
 
  observer.observe(document, {
    subtree: true,
    childList: true
  });
}
 
/**
 * Override the setAttribute property of a single window * @param {[BOM]} window [browser window object]
 * @return {[type]} [description]
 */
function resetSetAttribute(window) {
  //Save the original interface var old_setAttribute = window.Element.prototype.setAttribute;
 
  // Rewrite the setAttribute interface window.Element.prototype.setAttribute = function(name, value) {
    ...
  };
}

We define an installHook method with a window as a parameter. In this method, we will override the setAttribute of the passed window, install a MutationObserver, and monitor the iframes that may be created in this window in the future. If an iframe is created in this window in the future, the installHook method will also be installed on the new iframe to provide layer-by-layer protection.

Override document.write

Based on the above methods, we can continue to explore what other methods can be rewritten to better protect the page.

Document.write is a very good choice. Injection attackers usually use this method to inject some pop-up ads into the page.

We can rewrite document.write and use a keyword blacklist to match the content.

What keywords are more suitable for blacklisting? Let’s take a look at some pages with lots of ads:

Here, an iframe is embedded at the bottom of the page, which contains the ad code. The outermost id name here, id="BAIDU_SSP__wrapper_u2444091_0", is a good indicator for us to judge whether it is malicious code. Assume that we have collected a batch of blacklists based on interception reports:

// Create regular interception keywords var keywordBlackList = [
'xss',
'BAIDU_SSP__wrapper',
'BAIDU_DSPUI_FLOWBAR'
];

Next, we only need to use these keywords to perform regular expression judgment on the content passed in by document.write to determine whether to intercept the document.write code.

// Create a keyword blacklist var keywordBlackList = [
  'xss',
  'BAIDU_SSP__wrapper',
  'BAIDU_DSPUI_FLOWBAR'
];
 
/**
 * Override the document.write property of a single window * @param {[BOM]} window [browser window object]
 * @return {[type]} [description]
 */
function resetDocumentWrite(window) {
  var old_write = window.document.write;
 
  window.document.write = function(string) {
    if (blackListMatch(keywordBlackList, string)) {
      console.log('Intercept suspicious modules:', string);
      return;
    }
 
    //Call the original interface old_write.apply(document, arguments);
  }
}
 
/**
 * [Blacklist Match]
 * @param {[Array]} blackList [blacklist]
 * @param {[String]} value [String to be verified]
 * @return {[Boolean]} [false -- verification failed, true -- verification passed]
 */
function blackListMatch(blackList, value) {
  var length = blackList.length,
    i = 0;
 
  for (; i < length; i++) {
    // Create a blacklist regular expression var reg = new RegExp(whiteList[i], 'i');
 
    // Exists in blacklist, intercept if (reg.test(value)) {
      return true;
    }
  }
  return false;
}

We can put resetDocumentWrite into the installHook method above, and then we can rewrite document.write in the current window and all generated iframe environments.

Lock apply and call

The next thing I'm going to introduce is locking the native Function.prototype.apply and Function.prototype.call methods. Locking means making them unable to be overridden.

Object.defineProperty is used here to lock apply and call.

Object.defineProperty

The Object.defineProperty() method defines a new property directly on an object, or modifies an existing property, and returns the object.

Object.defineProperty(obj, prop, descriptor)

in:

• obj – the object whose properties need to be defined
• prop – the name of the property to be defined or modified
• descriptor – the descriptor of the property to be defined or modified

We can use the following code to prevent call and apply from being rewritten.

// Lock call
Object.defineProperty(Function.prototype, 'call', {
  value: Function.prototype.call,
  // This property can be changed by the assignment operator if and only if the writable of this property is true writable: false,
  // This property can be changed and deleted only when configurable is true. configurable: false,
  enumerable: true
});
// Lock apply
Object.defineProperty(Function.prototype, 'apply', {
  value: Function.prototype.apply,
  writable: false,
  configurable: false,
  enumerable: true
});

Why write like this? In fact, it is still related to the rewrite of setAttribute above.

Although we saved the original Element.prototype.setAttribute in a closure, there are still some tricks to "steal" it out of the closure.

Try this:

(function() {})(
    // Save the original interface var old_setAttribute = Element.prototype.setAttribute;
    // Rewrite setAttribute interface Element.prototype.setAttribute = function(name, value) {
        // Details if (this.tagName == 'SCRIPT' && /^src$/i.test(name)) {}
        //Call the original interface old_setAttribute.apply(this, arguments);
    };
)();
// Rewrite apply
Function.prototype.apply = function(){
    console.log(this);
}
// Call setAttribute
document.getElementsByTagName('body')[0].setAttribute('data-test','123');

Guess what the above paragraph will output? have a look:

It actually returned the native setAttribute method!

This is because when we rewrite Element.prototype.setAttribute, we have old_setAttribute.apply(this, arguments); at the end, which uses the apply method. So we rewrite apply and output this. When calling the rewritten setAttribute, we can get the original saved old_setAttribute from it.

In this way, the nested iframe rewriting setAttribute we did above is meaningless.

Using Object.defineProperty above can block apply and similar calls. Make it impossible to be rewritten, so that our native interface cannot be stolen from the closure. Only then can we say that we have successfully rewritten the properties we want to rewrite.

Establish interception report

Now we have some defensive measures. Next, we need to build a reporting system to replace the console.log() log in the above text.

What is the use of the reporting system? Because we use whitelists and keyword blacklists, these data need to be constantly enriched, relying on the reporting system to transmit each intercepted information to the server, which not only allows our programmers to know the occurrence of attacks in the first place, but also allows us to continuously collect such relevant information for better response.

In the example here, I use nodejs to build a very simple server to accept http report requests.

First define a reporting function:

/**
 * Custom reporting - replace console.log() in the page
 * @param {[String]} name [interception type]
 * @param {[String]} value [intercept value]
 */
function hijackReport(name, value) {
  var img = document.createElement('img'),
    hijackName = name,
    hijackValue = value.toString(),
    curDate = new Date().getTime();
 
  // Report img.src = 'http://www.reportServer.com/report/?msg=' + hijackName + '&value=' + hijackValue + '&time=' + curDate;
}

Assuming that our server address is www.reportServer.com, we use img.src to send an http request to the server http://www.reportServer.com/report/, each time with our custom interception type, interception content and reporting time.

Use Express to build a nodejs server and write a simple receiving route:

var express = require('express');
var app = express();
 
app.get('/report/', function(req, res) {
    var queryMsg = req.query.msg,
        queryValue = req.query.value,
        queryTime = new Date(parseInt(req.query.time));
 
    if (queryMsg) {
        console.log('Interception type: ' + queryMsg);
    }
 
    if (queryValue) {
        console.log('intercept value: ' + queryValue);
    }
 
    if (queryTime) {
        console.log('Intercept time: ' + req.query.time);
    }
});
 
app.listen(3002, function() {
    console.log('HttpHijack Server listening on port 3002!');
});

Run the server, and when a report occurs, we will receive the following data:

Well, the next step is to store data, analyze it, add to the blacklist, use nodejs and of course send emails to notify programmers when interception occurs, etc. I will not expand on these.

HTTPS and CSP

Finally, let’s briefly talk about HTTPS and CSP. In fact, the best way to defend against hijacking is to start from the back end, as there is really very little that the front end can do. And because the source code is exposed, attackers can easily bypass our defense measures.

CSP

CSP stands for Content Security Policy, which is translated as content security policy. This specification is related to content security and is mainly used to define which resources a page can load to reduce the occurrence of XSS.

MDN – CSP

HTTPS

The fundamental reason why HTTP hijacking can be implemented is that the HTTP protocol has no way to verify the identity of the communicating party and the integrity of the data. If this problem can be solved, hijacking will not be able to happen easily.

HTTPS means HTTP over SSL. The SSL protocol is a network protocol first proposed by Netscape in 1995 to solve the security problem of the transport layer. Its core is based on the theory of public key cryptography to implement functions such as server identity authentication, data privacy protection, and data integrity verification.

Because it is not closely related to the main content of this article, you can Google for more information about CSP and HTTPS.

The above is a detailed explanation of front-end security JavaScript anti-http hijacking and XSS. For more information about front-end security JavaScript anti-http hijacking and XSS, please pay attention to other related articles on 123WORDPRESS.COM!