# Toward an SDN-Based Web Application Firewall: Defending against SQL Injection Attacks
## 6 Implementation
### Implementation Stages  
As mentioned earlier, the WAF passes through four stages, and each stage has a specific task. The implementation mechanisms for each stage at the POX controller are as follows:  
1. _Reception stage:_ In order to receive the full traffic, we need to modify the POX controller. The modifications include: - Using the misc.full_forwarding function in POX controller, which allows the controller to receive all traffic that does not match any existing flow entries. - Modifying the libopenflow_01.py file in the POX/OpenvSwitch folder to configure the behavior of OpenFlow messages. Furthermore, in the reception stage, the destination IP address of the incoming packets is matched with the IP address of the web server. If there is a match, the traffic is forwarded to the next stage for further processing. 2. _Processing stage:_ In this stage, the pack() function in Python is used to convert the in-wire data to strings, making it possible for the data to be inspected in the next stage. Additionally, the entire traffic is converted to lowercase to avoid simple evasion techniques. It is worth noting that while Python may not be the most efficient language for processing high-speed traffic; it was chosen for its ease of use and versatility in this implementation. The processing stage in the SDN-based WAF is not expected to be the bottleneck for performance, and any delay added by using Python for traffic handling is likely to be negligible. However, in cases where efficiency is crucial during the processing stage, alternative solutions may need to be considered, such as using other programming languages or optimizing the Python code for performance. It is important to thoroughly test and validate the implementation to ensure it meets the performance requirements of the specific use case. 3. _Inspection stage:_ The inspection stage of the WAF is responsible for inspecting the traffic for suspicious patterns, particularly SQL injection attacks. There are two main applications implemented in this stage: 1. [label=()] 2. Matching the content of the packet with predefined signatures indicating the existence of an SQL injection exploitation: In this approach, known signatures are used to detect malicious GET and POST requests. These signatures are predefined and can indicate the presence of SQL injection attacks in the traffic. This approach can detect both GET and POST requests, as all of the traffic is inspected. Table 1 shows an example of known signatures that can be used for SQL injection detection. 2. Matching with regular expressions for whitelisting or blacklisting: In this approach, regular expressions are used to match the content of the packet against a set of predefined patterns, which can be used for whitelisting or blacklisting purposes. In the implementation described, whitelisting was used for custom solutions that fit the installed vulnerable web application. This allows for designing customized solutions that suit the environment/network. As a result, when an adversary sends an anomalous HTTP GET request, the application will classify this request as malicious. It is important to keep the signatures and regular expressions up-to-date, as attackers continuously evolve their techniques. Regular updates and monitoring of the WAF rules are necessary to ensure its effectiveness in detecting and mitigating SQL injection attacks. Additionally, it is essential to thoroughly test and validate the implementation with real-world traffic to ensure its accuracy and reliability. 4. _Containment stage:_ The containment stage of the WAF is responsible for taking action against detected SQL injection attacks. When a match occurs, the following steps are taken: 1. [label=()] 2. Blocking the IP address of the party responsible for the exploitation: A new rule is added to the OpenvSwitch to prevent the suspicious party from sending anyfurther traffic to the web server. This is typically carried out by blocking the IP address of the detected attacker.