# SloTFuzzer: Fuzzing Web Interface in IoT Firmware via Stateful Message Generation
## 3 Background and Motivation
### Motivation  
In Section 3.1, a web interface is used to accept the user inputs and translate inputs into communication messages. These messages result in the change of device state. When the pagehandler accepts the error messages, it may cause the device to crash. Generating mutated device messages is a major concern for a tester. Due to the different standards established by vendors in the protocol communication process between the front-end and web server, the method of injecting mutated data into a web page is often used. However, with the application scenarios of IoT devices shifting from LAN to WAN, vendors are improving the security of their web interfaces, such as adding some kind of security validation to the input field. From the code in Figure 2, lines 1-6 show the input validation for the web page, including XSS, special character, and invalid address checks. Inputs that cannot pass validation will not be received by device. As a result, the method of direct injection does not apply. Therefore, we can only use a proxy server to grab the normal messages. We need web crawlers to visit all pages of the device. Through front-end analysis, input simulation, and click-on page elements, we obtain the normal device messages.  
In previous work, \(FirmFuzz\)[13] grabs the first message after a click operation and mutates all of the message's data fields. \(FirmFuzz\) will generate hundreds of test cases and send these requests to the server one at a time. As an operation always contains a message sequence, a single message is just a part of the operation. Some messages are used for device state transition. As shown in Figure 2 lines 7-10, this example shows that  
\begin{table}
\begin{tabular}{c c c c c c} \hline \hline
**Fuzzer** & **Boofuzz** & **IoTFuzzer** & **WMIFuzzer** & **FirmFuzz** & **Firm-AFL** \\  & [12] & [9] & [14] & [13] & [15] \\ \hline
**Fuzzing Technique** & Blackbox & Blackbox & Blackbox & Blackbox & Greybox \\
**Hardware Support** & All & Real & Real & Emulation & Emulation \\
**Protocol Support** & Needs template & None & HTTP & HTTP & HTTP \\
**Message Dependency** & None & None & None & None & None \\ \hline \hline \end{tabular}
\end{table}
Table 1: Comparison of Internet of Things (IoT) firmware testing tools.  
Figure 2: Security validation of web page.  
the front-end needs to ask for a _sessionKey_ of the current session to perform parameters. The _sessionKey_ is unique in every connection, and a single message without the key to the parameter transmission will be rejected by the web server. When generating a test case, the fuzzer needs to request the server for a unique key first and then add it into the message. In addition, this session has a timeout so that we need to request the server in every test case. If we ignore device status and stateful messages, this will lead to two issues:  
1. During the generation phase, if a test case lacks stateful messages, it will not bypass the early check of the server;
2. During the mutation phase, only mutating all data fields of the message could break parameter dependency between messages.  
The forced mutation strategy will lead to too many invalid messages being generated, and most of these mutated messages will be rejected by server. In general, for improving the efficiency of fuzzing, we prefer to send more test cases in a period of time. However, when most test cases are invalid, testing cannot trigger vulnerabilities.  
Through the above problems, the fuzzer needs to keep the connection status and mutated data field that have no dependency to make sure that web server receives all mutated message. In Table 1, we list five fuzzing tools that can test IoT devices; none of them can deal with these two problems. In this work, we propose a stateful message generation (SMG) mechanism to maintain the device status and connection, which is described in Section 4.