Jsliang Job Search Series – 26 – Network Security

Browser security can be broken down into three main pieces:

• Web Page Security
• Browser Network Security
• Browser System Security

The Web world is open, and any resource can access it. Our website can load and execute scripts, pictures, audio, video and other resources of other websites, and even download executable files of other websites.

But the Web world cannot be completely free, such as opening a bank site and accidentally opening a malicious site:

• Modify DOM, CSSOM and other information of the bank site;
• Insert JavaScript scripts inside the bank site;
• Hijack user login username and password;
• Read the bank siteCookie,IndexDBSuch data;
• You can even upload the information to your own server, so you can fake money transfer requests and so on without your knowledge.

So, in the world of the Web without security, we have no privacy and therefore need security policies to ensure our privacy and data security.

This brings us to the most basic and core security policy on the page: the Same-Origin policy.

By source, you can mean URL.

Let’s look briefly at a URL composition;

• Github.com/LiangJunron…

Here:

If no port is specified in the URL, HTTP defaults to port 80 and HTTPS to port 443.

The so-called homology refers to the same protocol, domain name, and port.

By default, browsers can access resources and manipulate the DOM between two identical sources. If two different sources want to access each other’s resources or manipulate the DOM, they are constrained by a basic set of security policies, which we call the same-origin policy.

For the above URL, we determine the homology case:

• Github.com/LiangJunron…

The same origin policy is mainly manifested in DOM, Web data, and network.

• First, the DOM layer

The same origin policy restricts how JavaScript scripts from different sources can read and write to the current DOM object.

< A href=” XXX “target=”_blank”> < A href=” XXX” target=”_blank”>

let pdom = opener.document;
pdom.body.style.display = "none";
Copy the code

So this is an operation of DOM in homology.

You can’t operate with a different source.

• Second, data level

The same-origin policy prevents sites from accessing data such as cookies, IndexDB, and LocalStorage of the current site.

Due to the same origin policy, we still cannot access the contents such as Cookie, IndexDB or LocalStorage in page A through opener of page B.

• Third, the network level

The same origin policy restricts the sending of a site’s data to a site from a different source through, for example, XMLHttpRequest.

Objective: The following overview provides an overview of XSS attacks, types of XSS attacks, and XSS defense measures.

• XSS attack type

1. Storage type
2. reflective
3. The document type

• XSS precautions

1. Input inspection
2. Using the CSP
3. Using the HttpOnly

XSS (Cross Site Script) cross-site scripting attacks. It refers to an attack in which an attacker injects malicious client code into the web page and tampers the client’s web page with malicious scripts so as to control the user’s browser or obtain the user’s private data when the user browses the web page.

Such as:

• You can stealCookieInformation. Malicious JavaScript can pass throughdocument.cookieTo obtainCookieInformation, and then throughXMLHttpRequestorFetchaddCORSFunction to send data to a malicious server. The malicious server got the user’sCookieWith that information, the user’s login can be simulated on other computers and operations such as money transfers can be performed.
• You can listen for user behavior. Malicious JavaScript can be usedaddEventListenerInterface to listen for keyboard events, such as credit card information entered by the user, and send it to a malicious server. With that information, hackers can do a lot of illegal things.
• You can modify itDOMForge a fake login window to trick users into entering information such as user name and password.
• Floating window ads can be generated within a page, and these ads can seriously affect the user experience.

There are three ways to inject malicious script:

• Storage type: Indicates that attacks are stored on the server. It is common to insert attack scripts in the comments area. If the attack scripts are stored on the server, all users who see the corresponding comments will be attacked. For example, the 2015 Album title of Ximalaya allows users to write<script>The label.
• Reflection type: The attacker mixes the script in the URL. The server receives the URL and takes out the malicious code as a parameter, splices it into HTML and returns it. The browser parses the HTML and executes the malicious code. For example, malicious links are sent in Q groups or emails. Users click malicious links and then parse urls to execute malicious codes.
• DOM: Attackers inject malicious scripts into users’ pages by various means. For example, network hijacking (WiFi router hijacking, local malware hijacking, etc.) modifies HTML page contents during page transmission.

Defending against XSS attacks:

• Input inspection: For the inputscript 和 <iframe>Such labels are escaped or filtered
• Set the httpOnly: Sets this property to prevent JavaScript from getting itCookieCan only be used during HTTP requestsCookie
• Enable THE CSP whitelist: Enables the CSP whitelist to prevent the loading and running of resources that are not on the whitelist

Objective: The following overview provides an overview of CSRF attacks, CSRF attack modes, and CSRF defense measures.

• CSRF attack mode

1. Taking advantage of a user’s login status and using a third party’s site to do something bad
2. Automatically send GET requests
3. Automatically sends POST requests
4. Induced clicks send GET requests

• CSRF precautions

1. Authentication Token
2. Verify the Referer
3. Verify Samesite

CSRF attack (Cross-site Request Forgery) is a cross-site request forgery.

It is an attack that hijacks trusted users to send unexpected requests to the server. Under normal circumstances, the attacker uses the Cookie of the victim to cheat the server into trust, but it cannot get the Cookie or see the content of the Cookie. What it can do is to send requests to the server. The commands described in the request are then executed to alter the data in the server so that the data in the server is not stolen.

A CSRF attack is when a hacker takes advantage of a user’s login status and uses a third party’s site to do something bad.

After opening the page provided by the attacker, the attacker can perform CSRF attacks in three ways:

• Method 1: Automatically initiate a Get request

<! DOCTYPEhtml>
<html>
  <body>
    <h1>Hacker's Site: CSRF attack demo</h1>
    <img src="https://jsliang.top/index.html? user=hacker&number=100">
  </body>
</html>
Copy the code

The hacker hides the transfer request interface in the IMG tag, fooling the browser that it is an image resource.

When the page is loaded, the browser automatically initiates an IMG resource request. If the server does not make a judgment on the request, the server will assume that the request is a transfer request, and the $100 from the user’s account will be transferred to the hacker’s account.

• Method 2: Automatically send a POST request

<! DOCTYPEhtml>
<html>
<body>
  <h1>Hacker's Site: CSRF attack demo</h1>
  <form id='hacker-form' action="https://jsliang.top" method=POST>
    <input type="hidden" name="user" value="hacker" />
    <input type="hidden" name="number" value="100" />
  </form>
  <script>
    document.getElementById('hacker-form').submit();
  </script>
</body>
</html>
Copy the code

A hidden form is built in the page, and the content of this form is the geek Time transfer interface.

When the user opens the site, the form is automatically submitted; When the form is submitted, the server performs the transfer.

So by building an auto-submit form, you can automatically POST data across sites.

• Method 3: Entice users to click the link

<div>
  <img width=150 src=http://images.xuejuzi.cn/1612/1_161230185104_1.jpg>
  </div>
<div>
  <a href="https://jsliang.top? user=hacker&number=100" taget="_blank">Click to download photos of beautiful women</a>
</div>
Copy the code

Legendary seduction, or “click and get $100 million” or something like that.

Defending against CSRF attacks:

• Authentication Token: The server returns one when the browser requests ittokenAfter that, each request needs to be accompaniedtoken 和 CookieBefore it is considered a legitimate request
• Verify the Referer: passes the validation request headerRefererTo verify the source site, but the request header is easy to forge
• Set the SameSiteSet:Cookie 的 SameSite, can letCookieNot issued with cross-site requests, but browser compatibility varies

Existing code:

<form action="/login" method="POST">
  <p>Username: <input type="text" name="username" /></p>
  <p>Password: <input type="password" name="password" /></p>
  <p><input type="submit" value="Login" /></p>
</form>
Copy the code

Back end login statement:

let querySQL = `
  SELECT *
  FROM user
  WHERE username='${username}'
  AND psw='${password}'`;
// Execute the SQL statement...
Copy the code

The attacker enters the following message:

• User name:jsliang' OR 1 = 1 --
• Password: optional, for example123456

The expected input and the present input become:

SELECT * FROM user WHERE username='jsliang' AND psw='123456'
SELECT * FROM user WHERE username='jsliang' OR 1 = 1 --' AND psw='xxxx'
Copy the code

SQL > alter TABLE SQL > alter table SQL > alter table SQL

• SELECT: look for
• *: All information
• FROM: comes from a table (From xxx)
• user: the user table
• username='xxx': The user name is yesxxx
• ANDAnd:
• OROr:
• --: comments, with our JS//The same

So the code above means:

• # 1 FinduserTable ofusername 为 jsliangAnd the password is123456
• No.2: FinduserTable ofusername 为 jsliangOr,1 = 1

Then, the second SQL query must be true, and we can log in to the account.

This is SQL injection.

How to prevent it? We’re not going to care about this, but it’s a category of back-end concerns.

For example, the user name cannot contain hyphens (-) or underscores (_)

There are basically two types of traffic hijacking: DNS hijacking and HTTP hijacking. The purpose of traffic hijacking is the same: when a user visits Github.com, he or she will not show you the “content” provided by Github.com.

DNS hijacking, also known as domain name hijacking.

When a user accesses a site through a domain name, the tampered DNS server returns the IP address of a malicious phishing site, and the user is hijacked to the phishing site. Then, the user will be phished to input various account and password information to leak privacy.

This type of hijacking:

• Otherwise it is the ghost that network operator makes, general small network operator and black produce collude can hijack DNS
• Or the computer is infected, maliciously tampered with the router’s DNS configuration, basically as a developer or webmaster is very difficult to detect, unless there is user feedback.

HTTP hijacking is mainly when users visit a site will pass through the operator’s network, and illegal operators and black collusion can intercept HTTP request returned content, and can tamper with the content, and then returned to the user, so as to achieve page hijacking.

Light insertion of small ads, heavy directly tampered into a phishing site page to cheat users privacy, just like Jsliang visit a XXDN site, there will be Google ads, in fact, asked others is not this.

The fundamental reason for traffic hijacking is that HTTP cannot verify the identity and data integrity of the communicating party. If this problem can be solved, traffic hijacking will not happen easily.

So the only way to prevent HTTP hijacking is to encrypt the content so that the hostage-taker can’t crack the tampering, thus preventing HTTP hijacking.

HTTPS is a secure and encrypted network application layer protocol based on SSL. It is equivalent to HTTP + SSL and can prevent HTTP hijacking.

At every point in the HTTP process, data can be stolen or tampered with, which means you may have a middleman between you and the server who controls everything during the communication.

Content transmitted using HTTP can be easily stolen, forged and tampered with by middlemen. This attack is usually called man-in-the-middle attack.

Specifically, after submitting HTTP data to the TCP layer, the data passes through the user’s computer, WiFi router, carrier, and target server, and at every point in between, the data can be stolen or tampered with.

For example, if a hacker installs malware on a user’s computer, the malware can crawl and tamper with the content of HTTP requests made.

Or if a user accidentally connects to a WiFi phishing router, the data can be grabbed or tampered with.

Bugs in the browser itself are a major problem in single-process browsers, and if bugs are revealed, hackers can inject malicious programs into the browser through malicious pages if they are not fixed in time.

One of the most common attacks is using buffer overflows, although it is important to note that this type of attack is not the same as XSS injected scripts.

• XSSThe attacks simply inject malicious JavaScript scripts into the page, although some can be stolenCookieRelevant data, butXSSThe operating system cannot be attacked.
• Attacks through browser vulnerabilities can penetrate into the browser process, read and modify any content inside the browser process, but also penetrate the browser, quietly install malicious software on the user’s operating system, listen to the user’s keyboard input information and read the user’s hard disk file content.

The renderer process needs to perform DOM parsing, CSS parsing, network image decoding and other operations. If there are system-level vulnerabilities in the renderer process, the above operations may allow malicious sites to obtain the control rights of the renderer process, and then obtain the control rights of the operating system.

In this way, a wall is built between the renderer process and the operating system. Even if the renderer process is hacked due to a vulnerability, the hacker cannot obtain any operation rights outside of the renderer process because of this wall.

The wall that separates the renderer process from the operating system is the security sandbox.

• Summary of common Web security attacks and defenses[Reading Suggestions: 1H]
• Front-end Security Series 1: How do I Prevent XSS attacks?【 Reading Suggestions: 20min】
• Front-end Security Series ii: How to Prevent CSRF Attacks?【 Reading Suggestions: 20min】
• The front end also needs to understand JSONP security【 Reading Suggestions: 10min】
• What you need to know about Web security【 Reading Suggestions: 20min】
• Talk about your understanding of Web security【 Reading Suggestions: 10min】
• Web security is a must for programmers【 Reading Suggestions: 10min】
• The trusted front end road: code protection【 Reading Suggestions: 10min】
• How does the front end encrypt (not obfuscate) JavaScript?【 Reading Suggestions: 10min】

Jsliang’s document library is licensed by Junrong Liang under the Creative Commons Attribution – Non-commercial – Share alike 4.0 International License. Based on the github.com/LiangJunron… On the creation of works. Outside of this license agreement authorized access can be from creativecommons.org/licenses/by… Obtained.