Criteria for vulnerability classification

3.1. Currently, there are five hazard levels defined in the vulnerability hazard classification standard. The hazard levels are defined according to 3.1.1. An emergency vulnerability that can be exploited directly and is less difficult to exploit. After being attacked, the normal operation of the website or server may be seriously affected, or the property and personal information of users may be severely damaged. 3.1.2. After the high risk is exploited, the impact is great, but the vulnerability with high difficulty is directly exploited. Or a vulnerability that cannot be directly attacked by itself, but can greatly facilitate further attacks. 3.1.3. Vulnerabilities that are extremely difficult to exploit or can only be attacked under strict conditions. Or a vulnerability that cannot be attacked directly, but can be used to facilitate further attacks. 3.1.4. Low-risk attacks cannot be directly implemented, but the information provided may make it easier for attackers to find other security vulnerabilities. 3.1.5. Information itself has no direct impact on website security. The information provided may provide a little help to attackers or be used for attacks by other means, such as social workers.

Classification of vulnerabilities

Classification of XSS vulnerabilities

XSS vulnerability can be divided into the following three types according to different attack utilization methods:

Type A, local exploitation vulnerability, which exists in the client script itself on the page. The attack steps are seen as follows: Alice sends Bob a URL that maliciously constructs the Web. Bob clicks and looks at the URL. JavaScript in a malicious page opens an HTML page with a vulnerability and installs it on Bob’s computer. The HTML page with the bug included JavaScript running on Bob’s computer. Alice’s malicious script is able to run commands on Bob’s computer that Bob has privileges on.

Type B is A reflection vulnerability, which is similar to Type A. The difference is that when Webclient uses server-side scripts to generate pages and provide data for users, it is assumed that the unverified user data is included in the page without HTML entity encoding, and the client code can be injected into the dynamic page. The attack steps are as follows: Alice often visits a site owned by Bob. Bob’s site performs Alice login using username/password and stores sensitive information (such as bank account information).

Charly found that Bob’s site included reflexive XSS vulnerabilities. Charly writes a URL that exploits the vulnerability and sends it to Alice as an email from Bob. After Alice logs in to Bob’s website, she browses the URL provided by Charly. The malicious script embedded in the URL runs in Alice’s browser as if it came directly from Bob’s server. This script steals sensitive information (authorization, credit card, account information, etc.) and sends it to Charly’s Web site without Alice’s knowledge.

Type C is storage vulnerability, which is the most widely used vulnerability and may affect the security of Webserver. The hacker uploads the attack script to Webserver, making all users accessing the page face the possibility of information leakage, including the administrator of Webserver. The attack steps are as follows: Bob has a Web site that allows users to publish/view published information. Charly noticed that Bob’s site had a type C XSS vulnerability. Charly posted a hot message that attracted other users to read it. If Bob or someone else, such as Alice, browses the message, its session cookies or other information will be stolen by Charly.

Type A directly threatens individual users, while type B and type C threaten enterprise-level Web applications.

Currently, there is no authoritative definition and classification method for game bugs. Different people may have different classification methods. For example, some people like to classify bugs into mission system bugs, clan system bugs, battle system bugs, etc. The positioning of game security room still hopes to take the professional route of pure technical communication. Therefore, the classification method mentioned here mainly analyzes the causes of the formation of vulnerabilities from a technical perspective and summarizes the classification method for your reference only.

1. Plug-in function vulnerability

Plugins are bugs that affect the balance of a game’s core gameplay. At the early stage of game development, due to the unreasonable network architecture (network synchronization method), part of the key logic is put in the client side for processing, which will bring the corresponding risk of plug-ins. Because of the large amount of work required to change the network architecture design, it rarely changes once it is in operation. Therefore, plug-in-function vulnerabilities are generally difficult to repair and can only be operated by strengthening verification or relying on game protection schemes.

The characteristics of different types of games determine the corresponding common plug-in feature vulnerabilities are also different. In ACT games, the player must control the character and respond quickly to changes in the environment. ACT games attach great importance to hand feeling and user experience, and the operation instructions need to be reflected immediately after they are issued. Such high real-time requirements lead to high requirements on the server, so many games put the key logic on the client for hand feeling experience. This approach has resulted in common ACT game plugins such as teleportation, full screen, no CD, invincible, second monsters, and so on. In FPS, it is characterized by the ability to attack from a long distance and the large spatial range of the map. Due to the complexity of map scene, move the logic on the server requires server-side processing has full capacity of map information, demand is relatively high, in order to save cost of a service so many game coordinates processing logic on the client, so there will be: common FPS games like flying, dun land, perspective, no recoil, etc.

2. Server verification negligence vulnerability

Server verification negligence vulnerability mainly refers to the logic BUG that the server can obtain enough information and theoretically verify, but the programmer forgets to verify due to negligence during the development process. This kind of vulnerability generally has a great impact on the game and can obtain more virtual property income after utilization. But fixes are relatively simple, and developers can theoretically respond quickly to fix the bug once they find it.

The server is the brain of the entire game, responsible for most of the game logic processing, response and data storage functions. For example, in an ACT game, you normally have to reach level 60 to get into a biorestricted replica, but it turns out that under certain conditions, you can get around that level limit and get into that advanced replica at will.

3. Compatibility vulnerabilities

Compatibility vulnerability mainly refers to the vulnerability that the program crashes when processing the protocol due to the inconsiderate consideration of the boundary value of each field of the protocol. Compatibility vulnerability will generally lead to the crash of the server, so as to realize the denial of service of the server, such as blowing up the room, blowing up the channel and blowing up the server. Or cause nearby players to crash or drop calls. This kind of loophole does not bring much benefit from the user’s point of view, but it is a fatal loophole for the developer. In the process of program development, most of the time, only the normal case is considered and the special boundary value is ignored. Compatibility bugs are one of those bugs that almost every game has at one time or another, and they require a lot of testing before they go live.

The most typical example of compatibility vulnerability is a skill vulnerability that once appeared in an ACT game on the Internet, where cheating players inadvertently modified an illegal skill with a skill level of 0. Humans generally view values from 1, while programs generally process them from 0. The way to get skill attributes is to get them from an array, and the corresponding attributes of level 1 skills are array subscript 0. The plugin builds a level 0 skill (which normally does not exist) so the program accesses the array element with subscript -1 without checking. The subscript is out of bounds and causes the program to crash during processing. Plugins after the use of performance is once the use of this malformation of skills, then with the PK field of other players will receive a skill level of 0 skill package, processing will lead to the same PK field of other players client crash.

4. Performance vulnerabilities

A performance bug is an action that can be exploited by a malicious player to break the game due to its high performance cost. Common performance vulnerabilities exploit server-side or client-side bottlenecks.

A server bottleneck refers to the fact that some operations on the server consume performance. As a result, the server cannot process the operations due to a large number of operations initiated by the client, resulting in service denial. For example, checking the auction house operation may cause the game server to query the database and other behaviors. If the player sends the agreement to refresh the auction house within a short period of time, the server will not be able to deal with it, and other players will not be able to respond when refreshing the auction house, leading to the failure of the auction house function.

A typical example of client screen is the explosion of a car game, switching between different cars is also a performance consuming behavior for the client. Plugins quickly switch racing cars to the server, which synchronizes this behavior to other players around them. Other players load a lot of resources in a short period of time to release resources and consume a lot of CPU, resulting in gridlock.

Upload vulnerability classification

I. Web container resolution vulnerability

IIS Resolution Vulnerability (V6.0) :

1, when creating *. Asa or *. Asp folder, any file in the directory is6.0 will be treated as asp to parse, as shown below:

2, when the file with *.asp; 1. JPG name, IS6.0 will also be interpreted as asp, as shown below:

WebDav loopholes

After WebDav extension is enabled on the server, security risks may arise if the server supports PUT, Move, Copy, and Delete methods. The test steps are as follows: First, use OPTIONS to detect HTTP methods supported by the server.

The second step is to upload the script file using the PUT method.

Third, change the name using Move or Copy methods.

With these three steps, you get the Webshell, as well as the DELETE method.

Apache Parsing Vulnerability

Apache has a rule when parsing files. When it encounters an unknown extension, it will parse the file until it encounters an unknown extension. If the file name is 1.php.rarp.xx. ko, Apache parses the extension ko first and tries to parse xx if the file name is unknown

Example: there is 1.php.rar content as follows

After Apache parses, phpInfo is displayed:

PHP CGI parsing vulnerability:

Access to HTTP:www.xxx.com/1.jpg/1.phpWhere 1.jpg is an image Trojan and 1.php is not a file, you can see that 1.jpg is parsed according to the PHP script

Second, bypass upload vulnerability

It can be divided into: man-in-the-middle renaming, truncating upload, and modifying MIME (Content-Type)

General idea: for file editor specific defects, specify the URL, by intercepting the modification or construction of HTML to achieve upload

For example, FCKeditor 2.4.2 and below can construct the following HTML for uploading:

<html>
<head>
<title>FCKeditor poc </title>
</head>
<body>
<form action="http://www.XXX.com/FCKeditor/editor/filemanager/upload/php/upload.php?Type=Media" method="post" enctype="multipart/form-data">
<input type="file" name="NewFile"/>
<input type="submit" value="Submit"/>
</form>
</body>
</html>
Copy the code