Ddos 
WEB Fuzz is a special form of network protocol fuzzy test, dedicated to follow the HTTP specification of the network packet. WEB Fuzz is not a new concept, there are a variety of WEB application fuzzy tester (WEB Fuzzer), such as SPIKE Proxy, SPI Fuzzer, besTORM, and infiltration of the favorite Burp Suite.
After the Fuzz request is completed, the response from the target application provides a variety of clues to the impact of the Fuzz request. If an exception is found, the exception-related request can be determined. The following summarizes some of the response information, which may indicate the presence of a vulnerability condition:
- HTML status code
- The error message in response
- The user input contained in the response
- Performance degradation
- Request timed out
- WEB Fuzzer error message
- Processing or untreated exception
The following are discussed in detail:
HTML status code
The HTML status code is an important message that provides a quick indication of whether the corresponding request was a success or a failure. Therefore, WEB Fuzzer parses the original response, gets the status code, and then displays it in a list that displays the response details. With THML status code information, the user can quickly determine the response part that requires further detailed inspection.
The error message in response
From the design point of view, WEB server will generally generate a page in the dynamically generated error message. If a WEB server in the production process is not properly activated, enabled debugging function, this will happen. The following is an example of a typical disclosure of information: when the error is verified, WEB application gives the wrong message is “password is incorrect” rather than “user or password is not correct.” If the attacker tries to crack the landing page of a Web application by violent methods, the “incorrect password” error message will tell the attacker to enter the user name, but the password is incorrect. This makes two unknown parameters (user name and password) reduced to one (password), which greatly increases the likelihood that an attacker will enter the system. The error information applied is also particularly useful when identifying SQL injection attacks.
The user input contained in the response
If the dynamically generated WEB page contains the user input data, it is possible to generate XSS vulnerabilities. The designer of the web application should filter the user’s input to ensure that such attacks do not occur. However, WEB applications do not have to verify the filter is a common problem. Therefore, if the data provided by WEB Fuzzer is found in the HTML response message, the surface should test the XSS vulnerability in the application.
Performance degradation
Although it is easy to identify DoS attacks through its manifestation (direct application crashes), the DoS vulnerability is much more subtle. Performance degradation usually indicates that the application may be vulnerable to Dos attacks. Request timeout is a way to discover performance degradation, but in the process of Fuzz, you should also use the blood monitor to check the problem, such as excessive CPU usage or memory usage.
Request timed out
With reference to the previous one, you can not ignore the request timeout because they may indicate a temporary or permanent Dos condition.
WEB Fuzzer error message
WEB Fuzzer has its own error handling, when some specific function fails, it will pop up an error message. For example, if the target server is offline because of a previous Fuzz request, WEB Fuzzer may give an error message indicating that it can not be linked to the target server. This means that a DoS attack may have occurred.
Processed or untreated exception
When Fuzz is applied to a Web application, a vulnerability may be found on the application itself and on the server it is running. Therefore, it is also important to monitor the state of the server. Although the response information returned by the Web server provides us with information about potential vulnerabilities, they do not reveal all the problems. If the input changes slightly, the Fuzz request is likely to result in an exception that is processed or not handled, resulting in conditions that can be exploited. Therefore, in the Fuzz process, it is recommended that the target WEB server connected to a separate debugger, so that you can identify these exceptions, such as FileFuzz and COMRaider, all with built-in debugging capabilities. WEB Fuzzer does not require debugging function, because WEB Fuzzer does not need to repeatedly start and stop an application. Our approach is to send a series of fuzz requests to a Web application, the server will continue to run and correspond to these requests, and prevent the resulting Dos input.