Toward an SDN-Based Web Application Firewall: Defending against SQL Injection Attacks

Round 1

Reviewer 1 Report

The proposed technique is based on the standard operation of SDN. The main contribution of the paper is based on trivial configuration of SDN switches to forward the SQL server traffic to pass through the WAF and using signatures and regular expressions to drop the attack traffic.

Packet_In messages are used when no routes exist for routing the flows to destination. There is no need for Packet_In after the routes are configured in the switches. 

It is not a requirement for the attackers to generate SQL injection attacks during initial flow establishment. The attackers can be generated after the routes are established by the controllers. Hence to detect these attacks which are generated after the route establishment, it will require all the packets in the flows to be forwarded to the controller. This can incur significant overhead on the controller which can be vulnerable to new type of attacks.

Where are the WAF components (shown in Figure 3) implemented in SDN network?

Where the framework modules implemented for the scenario shown in Figure 4?  

The implementation is based on a trivial setup. There can be several switches in real world network. Also, the attacks to the SQL sever can be destined from devices on the Internet. How will the proposed framework be used in these scenarios?

It is not a difficult task to deal with the SQL injection attacks with the standard functionality of SDN. How can the proposed techniques be used to deal with different types of attacks?

Author Response

The proposed technique is based on the standard operation of SDN. The main contribution of the paper is based on trivial configuration of SDN switches to forward the SQL server traffic to pass through the WAF and using signatures and regular expressions to drop the attack traffic.

Authors’ response: 

Thank you for your comment. We have updated parts of the introduction and conclusion sections to better highlight the aims of this project. In particular, this work aims to address the crucial question of whether a controller can reach or exceed the efficiency of traditional WAFs in detecting SQL injection attacks. Therefore, we did not aim to design a more complex configuration of SDN switches.  Moreover, by presenting custom SDN-based security solutions, we demonstrate the potential to protect against these attacks without relying on expensive corporate software and hardware. 

Packet_In messages are used when no routes exist for routing the flows to destination. There is no need for Packet_In after the routes are configured in the switches. 

Authors’ response: 

Our proposed framework employs deep packet inspection to thoroughly analyse incoming traffic, accounting for the possibility of multiple attackers. By processing Packet_In messages even after routes are configured, we ensure the early detection and mitigation of SQL injection attacks.

 

It is not a requirement for the attackers to generate SQL injection attacks during initial flow establishment. The attackers can be generated after the routes are established by the controllers. Hence to detect these attacks which are generated after the route establishment, it will require all the packets in the flows to be forwarded to the controller. This can incur significant overhead on the controller which can be vulnerable to new type of attacks.

Authors’ response:  We concur with the reviewer that detecting SQL injection attacks after route establishment necessitates forwarding all packets to the controller, introducing notable overhead. However, as demonstrated in our paper, the overhead is less than that incurred by using a third-party WAF, making it acceptable in some scenarios. Additionally, although controller vulnerability is a valid concern, it is beyond the scope of our paper and merits further exploration.

 

Where are the WAF components (shown in Figure 3) implemented in SDN network?

Authors’ response: The WAF components utilised in our approach are either signature-based or regular expression-based and can be accessed via the following GitHub repository: https://github.com/Falkarshmi/SDN-WAF. These components are implemented on top of the POX controller.

 

Where the framework modules implemented for the scenario shown in Figure 4?  

Authors’ response: Note that Figures 4 shows the SDN testbed topology and configuration. The modules can be accessed via the following GitHub repository: https://github.com/Falkarshmi/SDN-WAF.

 

The implementation is based on a trivial setup. There can be several switches in a real world network. Also, the attacks to the SQL server can be destined from devices on the Internet. How will the proposed framework be used in these scenarios?

Authors’ response: We recognize the reviewer's concern about the scalability of our proposed SDN-based web firewall framework, especially in real-world networks with multiple switches and potential attacks from the internet. Our approach processes traffic regardless of its origin, and while we did not specifically address NAT, our current implementation is a starting point. Future work could enhance the framework by creating a distributed architecture to manage multiple switches and using adaptive strategies for diverse network topologies, ensuring robust protection against SQL injection attacks in complex situations. We have highlighted this information in sections 9 and 10. 

 

It is not a difficult task to deal with the SQL injection attacks with the standard functionality of SDN. How can the proposed techniques be used to deal with different types of attacks?

Authors’ response: Our proposed SDN-based web firewall can efficiently scale to detect multiple types of attacks, such as XSS and LFI, by leveraging both signature-based and regular expression components when processing traffic directed toward the web server. Additionally, incorporating statistical features, like the number of exchanged packets, could further enhance the approach to address various attack types. We added this clarification in section 6.

Reviewer 2 Report

SDN-based web application firewall is presented in this study.

As a proof of concept, detection of SQL injection is implemented.

Section on related works is weak. Existing approaches for well application firewall should be cited and compared.

Only one type of attacks, SQL injection, is not persuasive for the proposed framework. The scale of experiment is limited.

Algorithm 1 and 2 are ill-formatted. The mechanisms are relatively trivial.

SDN controllers are already heavily-loaded. Is it justified to shift the load to them any further?

Author Response

Reviewer #2: 

SDN-based web application firewall is presented in this study. As a proof of concept, detection of SQL injection is implemented.

Section on related works is weak. Existing approaches for well application firewall should be cited and compared.

Authors’ response: We concur with the reviewer that the related works section needs improvement, particularly regarding the inclusion of recent developments in web application firewalls. We appreciate the feedback and have enhanced this section by citing and comparing relevant existing approaches to provide a more comprehensive context. We provided more information about the available detection methods for application-layer attacks, such as flow monitoring, behavioural analysis, and others.

 

Only one type of attacks, SQL injection, is not persuasive for the proposed framework. The scale of experiment is limited.

Authors’ response: While our current work primarily focuses on detecting SQL injection attacks, we believe the deep inspection methodology employed in the proposed framework has the potential to detect various web attacks by adapting the signature-based and regular expression components accordingly. Although we have not covered multiple attack types in this paper, our approach demonstrates a solid foundation for future expansion to address a broader range of web security threats. 

 

Algorithm 1 and 2 are ill-formatted. The mechanisms are relatively trivial.

Authors’ response: Thank you for this feedback. We reviewed the algorithms and improved them. 

 

SDN controllers are already heavily-loaded. Is it justified to shift the load to them any further?

Authors’ response: While adding security functionality to SDN controllers may introduce some overhead, our proposed approach still results in lower overhead compared to traditional third-party solutions. Furthermore, this method offers greater flexibility and the potential for future enhancements, enabling tailored security solutions that can be adapted to specific network needs. 

Reviewer 3 Report

The article technically sounds; however, I have the following concerns.

-          The article requires extensive proofing; there are many typos and grammatical errors.

 

-          The authors should add a comparison table in the section on related work to compare the proposed work with the existing studies.

-          Authors should consider other SDN controllers and compare results. OpenDaylight is recommended.

-          What is the considered OpenFlow version?

Author Response

Reviewer #3: 

The article technically sounds; however, I have the following concerns.

-          The article requires extensive proofing; there are many typos and grammatical errors.

Authors’ response:  We appreciate your feedback and will thoroughly proofread the article to correct any typos and grammatical errors.

 

-          The authors should add a comparison table in the section on related work to compare the proposed work with the existing studies.

Authors’ response: Thank you for this suggestion. We included additional information in the related works section and discussed other existing approaches for detection application level attacks in SDN environments. 

 

-          Authors should consider other SDN controllers and compare results. OpenDaylight is recommended.

Authors’ response: While we appreciate the suggestion to consider other SDN controllers like OpenDaylight, our current implementation using OpenFlow has proven to be effective and sufficient in detecting SQL injection attacks. However, we can explore additional controllers in future work to provide a comparative analysis. In fact there are many controllers available on the market, both open source and commercial solutions, as also discussed in this paper: “Salman, Ola, Imad H. Elhajj, Ayman Kayssi, and Ali Chehab. "SDN controllers: A comparative study." In 2016 18th mediterranean electrotechnical conference (MELECON), pp. 1-6. IEEE, 2016.”

 

-          What is the considered OpenFlow version?

Authors’ response: The OpenFlow version used is 1.0, as this is the only version supported by the POX controller. We included this information in the revised manuscript.

Reviewer 4 Report

The reviewed paper concerns the SDN-based Web Application Firewall protecting against SQL Injection attacks. The topic seems interesting, but its implementation by the authors leaves much to be desired. In particular, I include my remarks below:

11. In the reception stage is written: “After that, it is verified that the port is for the HTTP protocol, either the sender or the receiver.” – How exactly is it done?; HTTP can run on not a standard port; How (if at all ) is it recognized? According to Algorithm 1, only port 80 is considered.

22. In the processing stage is written: Python was used to convert traffic to the proper format. Does python is a good choice? Its efficiency is very poor, and probably in a real scenario, it will be too slow to perform this operation (or at least it will add additional delay for traffic handling)

33. On page 6 authors emphasize that customization of controller detection rules for a particular application is a plus of usage SDN-I disagree with this. For one application, it can be accurate, but usually, WAFs protect more than one application. In such an approach, it does not secure application in a proper way

44. According to the paper, it is enough that only one HTTP traffic will be contained the SQL Injection payload, and the IP address will be blocked (based on page 6). It is very a very bad assumption. Such an approach can cause multiple false positives (e.g., a user, by accident, sent input with an apostrophe, and based on that, her/his IP will be blocked). In my opinion here, two options will be better: blocking based on the many malicious payloads from the same IP or just blocking input rather than IP

55. Aproposed SQL Injection list is very poor in the context of potential detection; a more significant and more detailed list can impact the efficiency of the solution- I see here a need for more tests in the context of proposed solutions

66. In my opinion, comparing a short SDN detection list with a ModSecurity CRS list has no sense – it is evident that ModSecurity will need more time to find the proper rule and block it; reasonable will be to compare the SDN detection list with an appropriate set of CRS

77. The conclusion  “Thus, it can be concluded that the SDN-based WAF is better in the case of the packet transfer speed is of importance to the network administrator, but the traditional WAFs are better” is naive- it is evident that comparing network with WAF and OpenvSwitch (two separate network elements) and OpenvSwitch with WAF function (one element) the second approach returns better time results;

88. The paper contains many grammar and language mistakes (e.g., page 2: “This work aims to be a first step towards designing an SDN-based WAF.”, page 3: “In Section 5 we present our conceptual design of an SDN-based WAF.”, “One of the early attempts that utilized SDN to implement a layer 3 firewall to match rules with packet header is presented in [19].”)

99. blacklist – colloquial expression; should be block list; whitelist – colloquial expression; should be allow list

Author Response

Reviewer #4: 

The reviewed paper concerns the SDN-based Web Application Firewall protecting against SQL Injection attacks. The topic seems interesting, but its implementation by the authors leaves much to be desired. In particular, I include my remarks below:

11. In the reception stage is written: “After that, it is verified that the port is for the HTTP protocol, either the sender or the receiver.” – How exactly is it done?; HTTP can run on not a standard port; How (if at all ) is it recognized? According to Algorithm 1, only port 80 is considered.

Authors’ response: Thank you for pointing out this important point. We acknowledge that in practice, web servers can run on non-standard ports and in our work, we only considered the standard port 80 for the HTTP protocol. This assumption was made for simplicity and to align with common practices. 

 

22. In the processing stage is written: Python was used to convert traffic to the proper format. Does python is a good choice? Its efficiency is very poor, and probably in a real scenario, it will be too slow to perform this operation (or at least it will add additional delay for traffic handling)

Authors’ response: While it is true that Python may not be the most efficient language for processing high-speed traffic, it was chosen for its ease of use and versatility. Additionally, the processing stage in our SDN-based web firewall is not the bottleneck for performance and the delay added by using Python for traffic handling is negligible. However, we will keep in mind the efficiency concerns for future work and consider alternative solutions if necessary. We added this clarification in section 6.

33. On page 6 authors emphasize that customization of controller detection rules for a particular application is a plus of usage SDN - I disagree with this. For one application, it can be accurate, but usually, WAFs protect more than one application. In such an approach, it does not secure application in a proper way

Authors’ response: In our scenario, we focused on protecting a single application and the customization of detection rules for this particular application was a design choice. We acknowledge that this approach may not be suitable for protecting multiple applications, where the customization of rules for each individual application may not be feasible. In these cases, monitoring the IPs of the web servers, if the applications are hosted on different web servers, may be a more suitable solution. 

 

44. According to the paper, it is enough that only one HTTP traffic will be contained the SQL Injection payload, and the IP address will be blocked (based on page 6). It is a very bad assumption. Such an approach can cause multiple false positives (e.g., a user, by accident, sent input with an apostrophe, and based on that, her/his IP will be blocked). In my opinion here, two options will be better: blocking based on the many malicious payloads from the same IP or just blocking input rather than IP.

Authors’ response: We agree that the approach of blocking an IP address based on only one instance of a potential SQL injection payload can lead to false positives. This approach was a design choice for simplicity, but it can also be considered a limitation of our approach. To address this concern, as you mentioned, alternative options such as blocking based on multiple instances of malicious payloads from the same IP or blocking specific inputs rather than the entire IP can be considered. These options would require a more complex implementation, but would reduce the likelihood of false positives. 

 

55. A proposed SQL Injection list is very poor in the context of potential detection; a more significant and more detailed list can impact the efficiency of the solution- I see here a need for more tests in the context of proposed solutions

Authors’ response: We agree with the reviewer that the current SQL injection list is not exhaustive. However, the main aim of this paper is to demonstrate the effectiveness and potential of our custom SDN-based web firewall, and we believe that our evaluation serves this purpose. In future work, we will certainly conduct more tests and refine the detection list to further improve the efficiency of the solution. 

 

66. In my opinion, comparing a short SDN detection list with a ModSecurity CRS list has no sense – it is evident that ModSecurity will need more time to find the proper rule and block it; reasonable will be to compare the SDN detection list with an appropriate set of CRS

Authors’ response: We agree with the reviewer's point; however, our intention is to highlight that SDN-based detection can be faster due to its specificity compared to generic commercial WAFs like ModSecurity. Even if we modified the list, we believe that the conventional WAFs would still be slower due to their broader, less tailored approach. 

77. The conclusion  “Thus, it can be concluded that the SDN-based WAF is better in the case of the packet transfer speed is of importance to the network administrator, but the traditional WAFs are better” is naive- it is evident that comparing network with WAF and OpenvSwitch (two separate network elements) and OpenvSwitch with WAF function (one element) the second approach returns better time results;

Authors’ response: We appreciate the reviewer's perspective, and we acknowledge that the comparison might appear naive. However, we emphasise this point to highlight the potential advantages of the SDN-based WAF in terms of packet transfer speed, while also recognizing that its effectiveness remains to be further proven and explored in future work. 

88. The paper contains many grammar and language mistakes (e.g., page 2: “This work aims to be a first step towards designing an SDN-based WAF.”, page 3: “In Section 5 we present our conceptual design of an SDN-based WAF.”, “One of the early attempts that utilized SDN to implement a layer 3 firewall to match rules with packet header is presented in [19].”)
89. blacklist – colloquial expression; should be block list; whitelist – colloquial expression; should be allow list

Authors’ response:  We appreciate the reviewer's feedback on the grammar and language mistakes, and we will diligently work on improving them in our revised manuscript.

Reviewer 5 Report

This paper proposed an SDN-based firewall capable of detecting SQL injection attacks.

 

The strength:

• The paper structure is complete, including background, motivation, contribution, related work, system description, implementation, evaluation results, conclusion, and future work.
• The proposals have been implemented and compared against alternative solutions using third-party WAFs.

 

The drawbacks are explained in the following paragraphs.

 

In lines 177 and 214, the authors said, "the IP address of attackers that perform SQL injection will be blocked when detected by the system." However, what if the attackers sit behind NAT, sharing the same network with legitimate users? Does that mean that all legitimate users' access will be blocked? Furthermore, Figures 5 and 6 show that the system can detect the source port and perform blocking. Does creating a flow to block specific <IP:source> make more sense than blocking all packets from the IP with a wildcarded source port?

 

In Section 6.2.2, is the path "\filename.php?id=[0-9]" supposed to be secret? What if the attackers know this path and perform GET/POST requests directly to this path? Can they bypass the system?

 

Are there any numerical results to show the detection accuracy between "signature-based" and "regular expression based"? So far, the authors only mentioned the CPU and latency usage without explaining why signatures are slower than regex.

 

Performing SQL injection detection on the SDN controller directly generates lower latency. However, the latency difference is small compared to traditional WAFs. Are there any SQL injection attacks that are "time-sensitive" such that this small gap can make a difference?

 

Modifying the SDN switch to send L1-L7 layer packets to the SDN controller will most likely generate performance overhead on the SDN controller, especially when the SDN controller is a general-purpose device connected to many SDN switches. How do the authors justify this overhead or trade-off?

 

In related work, line 129, the authors said, "no work has been done on an explicit implementation of WAF to block web attacks." However, similar works have used SDN-based DPI tools to detect network attacks, including SQL injection. For example, in [A] and [B], the authors perform experiments on SQL injection attacks and claim that their system can detect and mitigate such attacks. Those studies suggest that their works can prevent SQL injection despite not being tailored specifically for SQL injections (unlike this paper), which means that those studies are superior to this paper as they can also mitigate attacks other than SQL injections. The authors need to rephrase their motivation as to why we need to propose an SDN-based solution for SQL injection and why we need to perform detection on the SDN controller rather than using third-party WAFs.

 

Finally, the authors are encouraged to recheck the manuscript for grammar issues and typos. For example, "rais" in line 125, "forading" in line 190, and "machine <should be capital M>" in line 355.

 

Reference:

[A] Wang, H. and Wu, B., 2019, March. SDN-based hybrid honeypot for attack capture. In 2019 IEEE 3rd Information Technology, Networking, Electronic and Automation Control Conference (ITNEC) (pp. 1602-1606). IEEE.

[B] Kim, M., Cho, J.H., Lim, H., Moore, T.J., Nelson, F.F. and Kim, D.D., 2022, November. Performance and Security Evaluation of a Moving Target Defense Based on a Software-Defined Networking Environment. In 2022 IEEE 27th Pacific Rim International Symposium on Dependable Computing (PRDC) (pp. 119-129). IEEE.

Author Response

Reviewer #5: 

 

This paper proposed an SDN-based firewall capable of detecting SQL injection attacks.

 

The strength:

• The paper structure is complete, including background, motivation, contribution, related work, system description, implementation, evaluation results, conclusion, and future work.
• The proposals have been implemented and compared against alternative solutions using third-party WAFs.

 

 

 

 

The drawbacks are explained in the following paragraphs.

 

In lines 177 and 214, the authors said, "the IP address of attackers that perform SQL injection will be blocked when detected by the system." However, what if the attackers sit behind NAT, sharing the same network with legitimate users? Does that mean that all legitimate users' access will be blocked? Furthermore, Figures 5 and 6 show that the system can detect the source port and perform blocking. Does creating a flow to block specific <IP:source> make more sense than blocking all packets from the IP with a wildcarded source port?

Authors’ response: If an attacker is behind a NAT, the NAT-configured IP would indeed be blocked, potentially affecting legitimate users. Possible solutions include blocking the MAC address or providing both the user's IP and the NAT IP. We chose to block specific ports rather than all ports to minimise the impact on legitimate users and to account for potential false positives, as blocking an IP from using all services may have a greater negative impact. 

 

In Section 6.2.2, is the path "\filename.php?id=[0-9]" supposed to be secret? What if the attackers know this path and perform GET/POST requests directly to this path? Can they bypass the system?

Authors’ response: No, the example provided is just one case; in our research, we thoroughly examine all possible paths. 

 

Are there any numerical results to show the detection accuracy between "signature-based" and "regular expression based"? So far, the authors only mentioned the CPU and latency usage without explaining why signatures are slower than regex.

Authors’ response: We did not provide numerical results comparing "signature-based" and "regular expression-based" detection, as our study focused on CPU and latency usage without employing profiling tools to mimic HTTP traffic. However, we observed that signature-based detection is slower than regex due to the need to iterate over a list of signatures, which is computationally more expensive. 

 

Performing SQL injection detection on the SDN controller directly generates lower latency. However, the latency difference is small compared to traditional WAFs. Are there any SQL injection attacks that are "time-sensitive" such that this small gap can make a difference?

Authors’ response: The significance of the latency difference can be application-dependent. For instance, if a web application's database contains sensitive personal information (PII), it is crucial to identify and block SQL injection attacks rapidly. In such cases, the reduced latency provided by performing detection on the SDN controller directly could be a valuable advantage in securing the application and protecting user data. 

 

Modifying the SDN switch to send L1-L7 layer packets to the SDN controller will most likely generate performance overhead on the SDN controller, especially when the SDN controller is a general-purpose device connected to many SDN switches. How do the authors justify this overhead or trade-off?

Authors’ response: We agree with the reviewer's concern about the potential performance overhead on the SDN controller. To mitigate this issue, our system is designed to inspect only HTTP traffic, which reduces the amount of traffic sent to the controller. Additionally, the benefits of our approach, such as faster detection and greater customization, can justify this trade-off in scenarios where security and rapid response to threats are of paramount importance. 

 

In related work, line 129, the authors said, "no work has been done on an explicit implementation of WAF to block web attacks." However, similar works have used SDN-based DPI tools to detect network attacks, including SQL injection. For example, in [A] and [B], the authors perform experiments on SQL injection attacks and claim that their system can detect and mitigate such attacks. Those studies suggest that their works can prevent SQL injection despite not being tailored specifically for SQL injections (unlike this paper), which means that those studies are superior to this paper as they can also mitigate attacks other than SQL injections. The authors need to rephrase their motivation as to why we need to propose an SDN-based solution for SQL injection and why we need to perform detection on the SDN controller rather than using third-party WAFs.

Authors’ response: We have read and discussed the papers [A] and [B], and acknowledge their contributions in capturing/hardening network attacks, including SQL injection. However, it is important to note that paper [A] focuses on designing a flexible honeynet, while paper [B] is concerned with designing a Moving Target Defense (MTD) system. Our work, on the other hand, specifically targets the development of an SDN-based web application firewall (WAF) to block web attacks, which is a distinct approach from honeynets and MTD. While those papers considered SQL injection in their evaluation, our WAF aims to provide a more focused and specialised solution for detecting and mitigating web attacks, such as SQL injection. 

 

Finally, the authors are encouraged to recheck the manuscript for grammar issues and typos. For example, "rais" in line 125, "forading" in line 190, and "machine <should be capital M>" in line 355.

Authors’ response: We appreciate the reviewer's feedback on the grammar and language mistakes, and we will diligently work on improving them in our revised manuscript. 

 

Reference:

[A] Wang, H. and Wu, B., 2019, March. SDN-based hybrid honeypot for attack capture. In 2019 IEEE 3rd Information Technology, Networking, Electronic and Automation Control Conference (ITNEC) (pp. 1602-1606). IEEE.

[B] Kim, M., Cho, J.H., Lim, H., Moore, T.J., Nelson, F.F. and Kim, D.D., 2022, November. Performance and Security Evaluation of a Moving Target Defense Based on a Software-Defined Networking Environment. In 2022 IEEE 27th Pacific Rim International Symposium on Dependable Computing (PRDC) (pp. 119-129). IEEE.

Round 2

Reviewer 1 Report

The advantages claimed in the paper are valid for the simplistic topology in Figure 4. 

Also, the overall contribution is trivial to be considered for a publication. 

Reviewer 2 Report

No further comments.

Reviewer 4 Report

Thanks to the authors for answering my questions. The only thing I would suggest in further research is to increase the signatures on which detection is performed and perform more reliable tests.

Reviewer 5 Report

The authors have addressed all of my previous comments well. However, some of the answers do not appear in the paper. For example, these two answers:

 

#1

The significance of the latency difference can be application-dependent. For instance, if a web application's database contains sensitive personal information (PII), it is crucial to identify and block SQL injection attacks rapidly. In such cases, the reduced latency provided by performing detection on the SDN controller directly could be a valuable advantage in securing the application and protecting user data. 

 

#2

We agree with the reviewer's concern about the potential performance overhead on the SDN controller. To mitigate this issue, our system is designed to inspect only HTTP traffic, which reduces the amount of traffic sent to the controller. Additionally, the benefits of our approach, such as faster detection and greater customization, can justify this trade-off in scenarios where security and rapid response to threats are of paramount importance.