Based on Session-Cookie authentication

First, authentication and authorization technology

Based on Session-Cookie authentication

I believe everyone is not unfamiliar with Session-Cookie authentication, which is a front-end and back-end communication authentication mode that uses the server's Session (session) and the browser's (client) Cookie. It has been in the mainstream position for a long time.

Since HTTP is stateless, with the help of Cookie, after the client logs in successfully, the server can identify its subsequent requests without needing to log in each time. It is stateful, meaning both the server and the client need to save the generated Session, and the basic process is as follows:

• The client logs in using its credentials (such as username and password)

• If the server verification is successful, then a Session is generated and stored in the Session Storage (such as runtime memory, file, Redis, etc.)

• The server writes the Session Key to the client browser's Cookie through Set-Cookie

• All subsequent requests from the client will automatically carry Cookies

• If the client logs out (Logout), then the server and client will destroy the Session

There are some obvious disadvantages to authentication based on Session-Cookie: during the authentication process, the server needs to save the Session for each user, which is a heavy burden for the server in scenarios with a large number of users. In addition, this authentication method does not solve cross-domain resource sharing well, and using Cookies introduces many unsafe factors, such as CSRF attacks.

Authentication based on Token

The authentication based on Token is actually when the user enters their username and password somewhere, the server will generate a unique encrypted token, which will replace the login credentials to access protected pages and resources. This authentication method is stateless (stateless), after the client logs in successfully, the server generates the Token and returns it to the client, and the server does not save the Token.

When the Token is stolen, it will also cause some security issues, so the server needs to set a reasonable expiration time for the Token, and when the user logs out, the server needs to add the current Token to the blacklist to prevent it from being misused.

JWT authorization

JSON Web Token (JWT) is an open standard based on JSON that is executed to pass claims between network application environments, the most common use of which is to use it as an API authentication mechanism.

The basic operation process of JWT:

• The client sends a login request with a username and password

• Once the server/API successfully passes the authentication, it will create a JWT token that will be signed with a key

• After creating the token, the server/API will return it to the client application.

• After the client application receives the token, it will verify it to ensure its authenticity, and then only use it in each subsequent request to authenticate the user, so that the user does not need to send credentials again.

JWT is mainly composed of three parts, including:

• Header (Header)

• Payload (Body)

• Signature (Signature)

The following is an example of JWT completion as follows:

OAuth 2.0

OAuth is an open network standard related to authorization. OAuth allows users to authorize third-party applications to access their resources stored on other service providers without having to provide their username and password to the third-party application or share all their resources. In simple terms, OAuth is an authorization mechanism. The data owner informs the system that they agree to authorize third-party applications to access the system and obtain these data. The system then generates a short-term access token to replace the password, which is used by the third-party application.

OAuth 2.0 has a total of four authorization modes for different internet scenarios. Here, we will briefly understand the authorization code mode among them.

Authorization code mode

The authorization code mode (Authorization Code) is the most complete and most rigorous authorization mode. Its characteristics are: through the backend server of the 'client', interacting with the authentication server of the 'service provider'.

Authorization code is the most commonly used and most secure process, which is suitable for web applications with backend services. The authorization code is transmitted through the frontend, and the token is stored in the backend, and all communications with the resource server are completed in the backend. This separation of frontend and backend can prevent token leakage. In addition to this, OAuth 2.0 also includes hidden, password, and client credentials as three authorization methods, which will not be introduced in detail here.

The above is a simple introduction to several common identity verification or authorization technologies.

Second, account identification technology

At present, user account login to the business system is mainly divided into two scenarios: users directly log in to each business system and log in through the SSO mode for single sign-on.

Scenario one: Direct login to the business system

This scenario is where users directly log in to various business systems by entering their account and password, or by using login credentials carried in the HTTP request header. By extracting the mapping relationship between sessions and accounts in the traffic, accurate account identification is achieved.

Taking HTTP traffic as an example, the account identification scenarios include: account submitted in the request body, HTTP Basic authentication account in the request header, HTTP Bearer authentication account in the request header, and HTTP Digest authentication account in the request header.

Scenario two: SSO mode login

Another scenario is that the user logs in through the SSO mode. Single Sign-On (SSO) is an authentication method where users can log in to a session with a set of login credentials, and during this session, they do not need to log in again to securely access multiple related applications and services. In other words, in multiple application systems, users only need to log in once to access other mutually trusted application systems.

We take the case of using OAuth 2.0 (authorization code mode) as an example for SSO system authentication and authorization.

The SSO session, business system and user session are obtained through bypass methods, and the corresponding relationship between the temporary ticket and account is obtained, as well as the corresponding relationship between the SSO session and the temporary ticket, and the corresponding relationship between the business session and the temporary ticket. This allows the business session to be associated with the account, ultimately realizing the identification of the business system account under the single sign-on mode. It is worth noting that for OAuth, the SSO session is the same as the business system session; while for CAS processes, the two are different, with the business system session generated by the business system and the SSO session returning user information.

PS: CAS is the abbreviation of Central Authentication Service (Central Authentication Service), aiming to provide reliable authentication in web application systems.Single sign-onMethod.

Recognition effect

Through the coverage of multiple identity authentication mechanisms and multiple account login scenarios, accurate identification of accounts is achieved to monitor API security risks, data risks, and user behavior risks in real-time from the account dimension.

Part three: API user behavior monitoring

The following will introduce some common API user risk scenarios and behavior monitoring solutions.

Scenario one: Large-scale acquisition of sensitive information by accounts

Scenario DescriptionMalicious attackers may use social engineering or other technical means to access a large amount of sensitive data through various internal data interaction APIs after obtaining internal accounts of the enterprise, such as personal privacy data, personal information of corporate employees, corporate financial information, etc.

Monitoring PlanBased on account recognition technology and computational algorithms, the number of times internal accounts successfully access sensitive data through various data interaction API interfaces within a specified time frame is calculated. If the number of accesses exceeds the set threshold, there may be risks of internal accounts obtaining a large amount of sensitive information. Combined with API sensitive data flow monitoring, it can be judged whether the account has risks of sensitive data leakage.

Scenario two: High-frequency access/download of sensitive files

Scenario DescriptionHackers or malicious internal personnel may use social engineering or other technical means to initiate high-frequency requests through the file download API interface after obtaining internal accounts of the enterprise, downloading a large number of internal sensitive files in a short period of time, causing the risk of related data and internal sensitive files being leaked.

Monitoring PlanBased on account recognition technology and computational algorithms, the number of times internal accounts successfully access the file download API interface within a specified time frame is calculated. If the number of downloads exceeds the set threshold, it indicates the possibility of high-frequency internal file download risks by internal accounts.

Scenario three: Invalid/Resigned account login

Scenario DescriptionIn enterprises, the source user account may be an invalid account, which may be an account of a resigned employee, an account that has been disabled/deleted or expired. If the invalid account does not timely revoke related API access login permissions, it may cause data leakage or other security risks.

Monitoring PlanBased on account recognition technology, comprehensive management and monitoring of business system accounts are realized. By updating account status markers, it indicates whether an account is invalid. If an invalid account successfully accesses related APIs, there may be security risks such as unauthorized API access causing data leakage.

Scenario four: Failure to log in to the same important asset with multiple accounts

Scenario DescriptionIf multiple different accounts fail to access the same important target API at the same time within a certain time frame, it may indicate the existence of deliberate batch account guessing attacks.

Monitoring PlanBased on account recognition technology and computational algorithms, the number of times different accounts fail to access the same key API within a specified time frame is calculated. If the number of failed requests exceeds the set threshold, it indicates the possibility of batch account guessing attack security risks.

Scenario 5: Brute-force Attack

Scenario Description: Groups with certain capabilities use their technology to crack the APIs of major websites, steal initial data and package it for upload to servers; secondly, sell the database to specialized cleaning groups, to summarize and organize the data (such as game accounts, real information, financial accounts, etc.); finally, these data will be sold to brute-force groups, who will use these data to perform brute-force attacks on target login APIs.

Monitoring Plan: Based on account recognition technology and statistical algorithms, track the number of failed login attempts of an account within the specified time frame, and calculate the number of IP addresses of multiple failed logins by the same account within a unit of time. If the number of failed login attempts exceeds the set threshold, or if there are multiple IPs for an account after exceeding the set number of failed login attempts, it indicates that there may be a risk of account brute-force attacks.

User Anomaly Behavior Alert

Monitor API-related behavior risks in real-time by account dimension within the predefined time window. If the data meets the related configurable preset conditions, aggregate the data in real-time and issue relevant risk alerts.

Alert Example:

Within the past xxx time frame, account Y has performed sensitive operations Z times, exceeding the preset threshold, and there may be related risks of xxx behaviors.