Seven response analysis methods in WEB Fuzz

Seven response analysis methods in WEB Fuzz

WEB application fuzzy testing (WEB Fuzz) is a special form of network protocol fuzzy testing, which focuses on network data packets that follow HTTP specifications.
WEB Fuzz is not a new concept. At present, there are a variety of WEB application fuzzy testers (WEB Fuzzer), such as SPIKE Proxy, SPI Fuzzer, besTORM, and Burp Suite.
After the Fuzz request is completed, the response sent from the target application provides various clues about the impact of the Fuzz request. If an exception is found, the request related to the exception can be identified. Some response information is summarized below, which may indicate the existence of vulnerability conditions:
HTML status code
Error message in response
User input contained in the response
Performance decline
Request timeout
WEB Fuzzer error message
Handled or unprocessed exceptions
We will discuss it in detail below:
HTML status code
The HTML status code is an important piece of information. It provides instructions to quickly determine whether the corresponding request is successful or failed. Therefore, the WEB Fuzzer parses the original response to obtain the status code, and then separately displays it in a list showing the Response Details. With the THML status code, you can quickly determine the Response Section for further detailed checks.
Error message in response
In terms of design, WEB servers generally contain error messages in dynamically generated webpages. If a WEB server is improperly started during production and the debugging function is enabled, this situation occurs. The following is a typical example of disclosing too much information: When a verification error occurs, the error message provided by the WEB application is "Incorrect password" instead of "incorrect user or password ". If an attacker attempts to crack the login password page of a WEB application by brute force, the "Incorrect password" error message will tell the attacker that the user name entered exists, but the password is incorrect. This reduces two unknown parameters (username and password) to one, greatly increasing the possibility of attackers entering the system. Application error messages are also useful when identifying SQL injection attacks.
User input contained in the response
If a dynamically generated WEB page contains user input data, an XSS vulnerability may occur. WEB Application designers should filter user input to prevent such attacks. However, filtering that is not verified by WEB applications is a common problem. Therefore, if the data provided by WEB Fuzzer is found in the HTML response, the XSS vulnerability in the application should be tested on the surface.
Performance decline
Though its representation (direct application crash) makes it easy to identify DoS attacks, DoS Vulnerabilities are much more subtle. Performance Degradation usually indicates that the application may be vulnerable to Dos attacks. Request timeout is a way to detect performance degradation. However, in the Fuzz process, you should also use the blood energy monitor to check problems, such as high CPU usage or memory usage.
Request timeout
The request timeout cannot be ignored as they may indicate temporary or permanent Dos conditions.
WEB Fuzzer error message
WEB Fuzzer has its suberror handling method. When some specific functions fail to be executed, an error message is displayed. For example, if the target server is offline due to the previous Fuzz request, WEB Fuzzer may give an error message indicating that the server cannot be linked to the target server. This means DoS attacks may occur.
Handled or unhandled exceptions
When a WEB application is Fuzz, vulnerabilities may be detected on the application itself and the server on which it runs. Therefore, it is also important to monitor the status of multiple servers. Although the response information returned by the WEB server provides us with information to discover potential vulnerabilities, it does not reveal all the problems. If the input changes slightly, the Fuzz request is very likely to cause an exception that is being processed or not handled, resulting in available conditions. Therefore, in the Fuzz process, we recommend that you connect to a single debugger on the target WEB server to identify these exceptions. For example, FileFuzz and COMRaider both have built-in debugging functions. WEB Fuzzer does not need to debug the function, because WEB Fuzzer does not need to start or stop an application repeatedly. Our method is to send a series of fuzz requests to a Web application. The server will continue to run these requests and block Dos input.