GB/T 37931-2019Information security technology—Security technology requirements and testing and evaluation approaches for Web application security detection system (English PDF)

3.1 Web application security detection system

Products that detect the security of web applications can discover URLs of web applications based on policies

Vulnerabilities are detected.

3.2 URL discovery

Starting from a URL, discover other URLs that can be linked to through that URL, including the complete URL that appears in the web page,

URLs obtained through various calculations, URLs for various redirects, etc.

3.3 Deformation detection

A detection mechanism that bypasses the protection filtering through methods such as encoding and request packet changes.

6.1 Basic level safety technical requirements

6.1.1 Safety function requirements

6.1.1.1 Detection capability

6.1.1.1.1 Resource Discovery

Products should be able to find various URLs in web applications, and the proportion of URLs found should be higher than 90%. URL discovery includes but is not limited to.

a) URL obtained by parsing and executing scripts such as JavaScript;

b) The URL contained in the page file;

c) URL embedded in Flash.

6.1.1.1.2 Web application vulnerability detection

The product should be able to detect web application vulnerabilities, and the false negative rate and false positive rate of the same type of vulnerabilities should be less than 20%. Types of vulnerabilities include but are not limited to.

a) SQL injection vulnerabilities, including injection vulnerabilities submitted based on Get and Post methods that should include characters, numbers, and searches;

b) Cookie injection vulnerabilities, including injection vulnerabilities submitted based on cookies that should include characters, numbers, and searches;

c) XSS vulnerabilities, including cross-site attack vulnerabilities based on Get and Post methods;

d) CSRF vulnerability;

e) Directory traversal vulnerability;

f) Information disclosure vulnerabilities, including path disclosure, backup files, source code disclosure, directory browsing and phpinfo and other information disclosure vulnerabilities;

g) The authentication method is weak, such as weak passwords, etc.;

h) Files contain vulnerabilities, including remote and local files contain vulnerabilities.

6.1.1.1.3 Upgrade

The product should have the ability to update the vulnerability signature database.

6.1.1.1.4 Support HTTPS

The product should be able to detect web applications based on the HTTPS protocol.

6.1.1.1.5 Does not affect the target object

The product should avoid affecting the normal operation of the target Web application during the detection process.

6.1.1.2 Inspection task management

6.1.1.2.1 Wizard function

The product should provide a wizard function to guide users to the correct configuration.

6.1.1.2.2 Detection range

The product should be able to configure the detection range according to the following conditions.

a) Specify the domain name and URL;

b) the depth of inspection;

c) URLs that are not checked, such as logout, delete and other related pages.

6.1.1.2.3 Login detection

The product should be able to detect web applications based on login information. Such as based on recording information, Cookie, Session, Token, etc.

Or multiple ways to authorize login and perform detection.

6.1.1.2.4 Strategy selection

The product should be able to select the detection strategy in the following ways.

a) Type of vulnerability;

b) The vulnerability hazard level.

6.1.1.2.5 Detection speed adjustment

The product should be able to adjust the detection speed by configuring the HTTP request speed, the number of detection threads or processes, etc.

6.1.1.2.6 Task customization

Products should be able to realize batch start-up detection according to planned tasks, and automatically generate corresponding results according to the settings.

6.1.1.2.7 Progress control

The product should be able to control the progress of the test as follows.

a) Stop at any time;

b) Resume scanning after a breakpoint.

6.1.1.3 Analysis and processing of test results

6.1.1.3.1 Result verification

The product should have the function of web application vulnerability verification, and be able to provide parameters to further detect XSS vulnerabilities, SQL injection points, directory traversal,

Vulnerabilities such as information leakage and command execution are verified.

6.1.1.3.2 Results save

The test results should be stored in non-clear text in a non-volatile storage medium after power failure.

6.1.1.3.3 Statistical analysis

The product should be able to perform statistical analysis on the number of vulnerabilities, vulnerability types and hazard levels based on the detection results.

6.1.1.3.4 Report generation

The product should be able to analyze the test results and form a report, the report should include.

a) Vulnerability information such as vulnerability location, vulnerability name, vulnerability description and hazard level;

b) Suggestions for bug fixes.

6.1.1.3.5 Report output

The product test report should be output according to the following requirements.

a) Common document formats, such as DOC, PDF and HTML;

b) Display in a way that is easy for users to understand.

6.1.2 Own safety requirements

6.1.2.1 Identification and

6.1.2.1.1 User ID

6.1.2.1.1.1 Security attribute definition

The product should specify the security attributes related to each user, such as user identification, membership group, authority, etc.

6.1.2.1.1.2 Property initialization

The product should be able to initialize the attributes of each user created with default values.

6.1.2.1.1.3 Unique identification

The product should provide a unique identifier for the user, and at the same time associate the user's identity with all auditable events of the user.

6.1.2.1.2 Identity authentication

6.1.2.1.2.1 User authentication

The product should authenticate the user's identity before performing any security function operations.

6.1.2.1.2.2 Authentication information protection

The product shall take technical measures to ensure that user authentication information is not read or modified without authorization.

6.1.2.2 Security Management

6.1.2.2.1 Management capabilities

The product should allow authorized users to manage the following.

a) View security attributes;

b) Modify security attributes;

c) Turn on or turn off all or part of the safety functions;

d) Formulate and modify various security strategies.

6.1.2.2.2 Security role management

The product should have at least two user roles with different permissions, such as operator, auditor, etc.

6.1.2.2.3 Remote secure transmission

If product components communicate through the network, measures should be taken to ensure the security of the transmitted data.

6.1.2.3 Audit log

6.1.2.3.1 Audit log generation

The product should generate an audit log of the following events.

a) The user's login success and failure;

b) The operation of configuring the security policy;

c) Add, delete, and modify security roles.

The product shall record the date, time, user identification, event description and result of the event in each audit log record. If adopted

The remote login method should also record the IP address of the management host.

6.1.2.3.2 Audit log preservation

The audit log should be stored in a non-volatile storage medium after power failure.

6.1.2.3.3 Audit log management

The product should provide the following audit log management functions.

a) Only authorized users are allowed to access audit logs;

b) Query and retrieval functions based on conditions such as operating users, date and time, and operation types;

c) Authorized users should be able to archive and export audit logs.

6.1.3 Safety assurance requirements

6.1.3.1 Development

6.1.3.1.1 Security Architecture

The developer should provide a description of the security architecture of the product's security functions, and the description of the security architecture should meet the following requirements.

a) Consistent with the description scope of the safety function in the product design document;

b) Fully describe the self-protection and non-bypassable safety mechanism adopted by the product.

6.1.3.1.2 Functional specification

The developer shall provide a complete functional specification, which shall meet the following requirements.

a) Fully describe the functions defined in 6.1.1 and 6.1.2;

b) Identify and describe the purpose, usage and related parameters of all safety function interfaces of the product;

c) Describe the safety function implementation behavior related to the safety function interface;

d) Describe the direct error messages caused by the behavioral processing of the security function.

6.1.3.1.3 Product design

Developers should provide product design documents, and product design documents should meet the following requirements.

a) Describe the product structure through the subsystem, identify and describe all the subsystems of the product safety function, and describe the interaction between the subsystems;

b) Provide the correspondence between the subsystem and the safety function interface.

6.1.3.2 Guiding documents

6.1.3.2.1 Operation User Guide

The developer should provide a clear and reasonable operation user guide, and the description of each user role should meet the following requirements.

a) Describe the functions and privileges that the user can access, including appropriate warning information;

b) Describe the user operation methods of product safety functions and interfaces, including the safety values of configuration parameters, etc.;

c) Identify and describe all possible states of product operation, including failures or operational errors caused by operations;

d) Describe the security policies that must be implemented to achieve product security goals.

6.1.3.2.2 Preparation procedures

The developer should provide the product and its preparation procedure, and the preparation procedure description should meet the following requirements.

a) Describe all the steps necessary to safely receive the delivered product consistent with the developer's delivery procedure;

b) Describe all the steps necessary to safely install the product and its operating environment.

6.1.3.3 Life cycle support

6.1.3.3.1 Configuration management capabilities

The developer's configuration management capabilities should meet the following requirements.

a) Provide unique identification for different versions of the product;

b) Use the configuration management system to maintain all the configuration items that make up the product and uniquely identify it;

c) Provide configuration management documents, which describe the methods used to uniquely identify configuration items.

6.1.3.3.2 Configuration management scope

The developer should provide a list of product configuration items and indicate the developer of the configuration items. The list of configuration items includes at least product and security requirements

The evaluation evidence and product components.

6.1.3.3.3 Delivery procedures

Developers should use prescribed delivery procedures to deliver products and document the delivery process. When delivering each version of the product to the user,

The paid documentation should describe all procedures necessary to maintain safety.

6.1.3.4 Test

6.1.3.4.1 Test coverage

The developer should provide a test coverage document, and the test coverage description should indicate the test items identified in the test document and the function specifications.

Describe the compatibility of product safety features.

6.1.3.4.2 Function test

Developers should test product safety features and provide test documentation. The test document should include the following.

a) Test plan, which identifies the tests to be executed and describes the plan for executing each test;

b) The expected test results, indicating the expected output after the test is successful;

c) Comparison of actual evaluation results and expected evaluation results.

6.1.3.4.3 Independent testing

Developers should provide a set of resources equivalent to those used in self-testing safety functions for sampling tests of safety functions.

6.1.3.5 Vulnerability assessment

Based on the identified potential vulnerabilities, the product can resist basic attacks.

6.2 Enhanced safety technical requirements

6.2.1 Safety function requirements

6.2.1.1 Detection capability

6.2.1.1.1 Resource Discovery

Products should be able to find various URLs in web applications, and the proportion of URLs found should be higher than 90%. URL discovery includes but is not limited to.

a) URL obtained by parsing and executing scripts such as JavaScript;

b) URL included in the page file;

c) URL embedded in Flash and Flex.

6.2.1.1.2 Web application vulnerability detection

The product should be able to detect web application vulnerabilities, and the false negative rate and false positive rate of the same type of vulnerabilities should be less than 20%. Types of vulnerabilities include but are not limited to.

a) SQL injection vulnerabilities, including injection vulnerabilities submitted based on Get and Post methods that should include characters, numbers, and searches;

b) Cookie injection vulnerabilities, including injection vulnerabilities submitted based on cookies that should include characters, numbers, and searches;

c) XSS vulnerabilities, including cross-site attack vulnerabilities based on Get, Post, Referrer and Cookie methods;

d) CSRF vulnerability;

e) Directory traversal vulnerability;

f) Information disclosure vulnerabilities, including path disclosure, backup files, source code disclosure, directory browsing and phpinfo and other information disclosure vulnerabilities;

g) Weak authentication methods, such as various login bypasses, weak passwords, etc.;

h) Files contain vulnerabilities, including remote and local files contain vulnerabilities;

i) Command execution vulnerability;

j) Vulnerabilities in third-party components, such as Struts2, FCKeditor editor, etc.;

k) LDAP injection vulnerability;

l) XPath injection vulnerability.

6.2.1.1.3 Deformation detection

The product should support deformation detection of Web application vulnerabilities, such as random conversion of upper and lower case, multiple bypassing of space restrictions, space replacement and URL encoding mechanisms.

6.2.1.1.4 Content detection

The product should be able to detect the following content of the target web application.

a) Does not belong to the external chain of the target system;

b) Bad links in the target system;

c) The dark link in the target system;

d) Sensitive keywords.

6.2.1.1.5 Upgrade

The product should have the following upgrades.

a) Update of vulnerability signature database;

b) At least one security mechanism shall be adopted to ensure the timeliness of the upgrade, such as automatic upgrade, update notification and other means.

6.2.1.1.6 Support HTTPS

The product should be able to detect web applications based on the HTTPS protocol.

6.2.1.1.7 Does not affect the target object

The product should avoid affecting the normal operation of the target Web application during the detection process.

6.2.1.2 Inspection task management

6.2.1.2.1 Wizard function

The product should provide a wizard function to guide users to the correct configuration.

6.2.1.2.2 Detection range

The product should be able to configure the detection range according to the following conditions.

a) Specify the domain name and URL;

b) the depth of inspection;

c) URLs that are not checked, such as logout, delete and other related pages;

d) Route mode reloading;

e) The path mode is case sensitive.

6.2.1.2.3 Login detection

The product should be able to detect web applications based on login information. Such as based on recording information, Cookie, Session, Token, etc.

Or multiple ways to authorize login and perform detection.

6.2.1.2.4 Detection strategy

6.2.1.2.4.1 Strategy selection

The product should be able to select the detection strategy in the following ways.

a) Type of vulnerability;

b) The vulnerability hazard level;

c) Web system fingerprint information.

6.2.1.2.4.2 Strategy Extension

Products should be able to customize detection strategies and expand existing strategies.

6.2.1.2.5 Detection speed adjustment

The product should be able to adjust the detection speed according to the following methods.

a) Configure the HTTP request speed, the number of detection threads or processes, etc.;

b) Distributed deployment detection engine;

c) Multi-engine load balancing.

6.2.1.2.6 Task customization

The product should be able to realize batch, timing, specified time period and periodic start detection according to the planned tasks, and automatically generate corresponding results according to the settings.

6.2.1.2.7 Progress control

The product should be able to control the progress of the test as follows.

a) Stop at any time;

b) Resume scanning at breakpoints;

c) If the test is not over, the tested part can be displayed and a report can be exported.

6.2.1.3 Analysis and processing of test results

6.2.1.3.1 Result verification

The product should have the function of web application vulnerability verification, including.

a) Provide parameters to further verify vulnerabilities such as XSS vulnerabilities, SQL injection points, directory traversal, information disclosure and command execution;

b) Provide automated tools to verify vulnerabilities.

6.2.1.3.2 Results save

The test results should be stored in non-clear text in a non-volatile storage medium after power failure.

6.2.1.3.3 Statistical analysis

The product should be able to perform statistical analysis on the number of vulnerabilities, vulnerability types and hazard levels based on the detection results.

6.2.1.3.4 Report generation

The product should be able to analyze the test results and form a report, the report should include.

a) Vulnerability information such as vulnerability location, vulnerability name, vulnerability description and hazard level;

b) Vulnerability repair suggestions;

c) Support exporting industry compliance reports;

d) Edit and customize design reports, support adding custom notes or detailed information;

e) Support batch export of reports;

f) Support trend analysis report based on horizontal and vertical comparison.

6.2.1.3.5 Report output

The product test report should be output according to the following requirements.

a) Common document formats, such as DOC, PDF and HTML;

b) Display in a way that is easy for users to understand.

6.2.1.4 Interactivity requirements

The product should provide or adopt a standard, open interface. Comply with this interface specification, you can write corresponding

The program module achieves the purpose of interacting with the product.

6.2.2 Own safety requirements

6.2.2.1 Identification and

6.2.2.1.1 User ID

6.2.2.1.1.1 Security attribut...