0

I have a head-scratcher here. Over a year ago, I wrote a website feature/form where I could submit SQL Code that is not executed but stored in a table. This feature worked when I created it, as I was able to upload several scripts into the database. I have not needed to use this feature for several months, and recent upgrades to my website had me re-checking features. The feature stopped working ... and after some research, it was determined that our company firewall was now blocking the form from submitting due to a detection of "SQL Injection".

They swear that no changes were made to the firewall, however, this seems unlikely since this feature previously functioned. Regardless ... the confusion I have is that I know many websites, like this one, that allow people to post "code" using a web form interface without being flagged as SQL Injection. I am sure websites (like this one) have firewalls protecting them as well.

Is there something that needs to be done when transmitting code on a page submit/postback to clear a firewall's SQL Injection checks?

For clarification ...

There is a form, with a LargeTextArea control, where a SQL Script is entered. This SQL code is transmitted via postback to the server, and server-side code handles the saving of the script into a table. Very similar to what this website (StackOverflow) does I would assume. We can post code here, without it being intercepted and blocked by a firewall. The code we post here in our messages is eventually stored in a database on the server. That is the same behavior that I am performing.

Because of the firewall intervening between the client browser and the web server, the postback is never completed. Therefore, the server never receives the postback data to perform any processing. The client browser simply receives a "connection-reset" error.

I always thought of SQL Injection as something that should be handled server-side ... the responsibility of the programmer to ensure it is not abused. Having a firewall interfere prior to arriving at the server and having code execute to even check for SQL Injections ... feels wrong to me. Even if you have code that prevents SQL Injection, it would not matter if the firewall intercepts and intervenes prior to any server-side logic. Am I wrong?

UPDATE (04/17/2023): The final solution for anyone reading this ... is that there is no solution. When there is a situation where another department that controls a firewall, institutes a "rule" that blocks communication, there is nothing that honestly can be done. The firewall is interfering with the entire process and takes the decision-making out of the programmer's hands. The only "solution" is to run the website code/page on the IIS Server directly, which would bypass the firewall entirely. This is a band-aid at best ... because it would only be a usable solution for administrators (like myself) that have access to run the site on the server directly. If at any point, this functionality is needed for clients to use, there would be no workaround.

TekkGuy
  • 107
  • 2
  • 15
  • Please post the code that saves the text the database. Without knowing what exactly you are doing, it's impossible for us to help you figure out a different approach. What you are experiencing is most likely a software/firmware update of the antivirus/firewall. Their detection methods evolve all the time and you are obviously doing something in code that they deem dangerous. – JuanR Dec 12 '22 at 14:21
  • I am using a 3rd party RAD Development tool, but the code used to "save" the data is not the problem, as the server-side code never has an opportunity to run. It is the postback of the form itself, that is being blocked by the firewall claiming "SQL Injection". Typically I always thought SQL Injection was something that should be handled at the server-level, not the firewall level, as the firewall cannot (from my understanding) differentiate between code to be executed and code to be stored. Am I wrong? – TekkGuy Dec 12 '22 at 16:58
  • We are getting somewhere. What are you using for your form? Is it WebForms? MVC? Please post the code that creates the form field as well as the code that handles the postback. – JuanR Dec 12 '22 at 17:15
  • Also, please refrain from adding comments as answers. Either edit your question or post additional comments here. I edited your question with the information from the answer you posted. Please delete your answer. – JuanR Dec 12 '22 at 17:16
  • I am using a 3rd party RAD Development suite (Plant-An-App) on a CMS Framework (DNN). There is no code for me to post, as this is generally a low-code/no-code environment. – TekkGuy Dec 12 '22 at 17:25
  • 1
    I see. It definitely sounds like a firewall rule. I assume you determined the source to be the server network's firewall, right? Your only recourse in this case is for network admins to modify the rule or add an exception for your form. Generally speaking though, there is a reason these checks are put in place. It's a bad idea, lol. If these forms are not properly secured, they can be a nightmare so it's unlikely they will agree to this. You may end up having to rework your form in a more secure way that can make it through the firewall. – JuanR Dec 12 '22 at 18:12
  • [Check this out](https://docs.citrix.com/en-us/citrix-adc/current-release/application-firewall/top-level-protections/html-sql-injection-check.html) as an example of such firewall rule. – JuanR Dec 12 '22 at 18:12
  • It's been confirmed as a firewall rule. The networking dept's answer is no exceptions, claiming it's safer. This is IMHO, unacceptable. It's like nailing every window and door to a house shut, except for one window on the 2nd floor, and expecting you to open a locked shed, take out a ladder, place it to the window to climb to get in and out of the house that way. It's extreme insanity. Doesn't seem like there is any solution outside of modifying the firewall. – TekkGuy Dec 12 '22 at 18:27
  • I figured. Well, that's the world we live in nowadays and there are other ways to go about this without modifying the rule. That being said, there is only so much you can do with low-code/no-code solutions. :-) – JuanR Dec 12 '22 at 18:31

1 Answers1

0

Your firewall rules for SQL injection are blocking parameters that "look like" SQL injection - and that can lead to false positives for code that is not executed.

The correct way to get around this is to modify the firewall rule. See this answer for a way to that in ModSecurity.

Since this doesn't seem to be an option for you, you might consider bypassing the rule with obfuscation. For example - encrypting with a simple fixed key before putting it in the database (and decrypting on display) would hide this code from the firewall. And also provide some guardrails against it being executed in the future.

With bypassing security checks you are taking on a great responsibility. You should be very careful to ensure (and warn in comments) that this code is never executed. This includes executing it to check that it is correct SQL - which could also be abused for SQL injection.

Egret
  • 739
  • 3
  • 8
  • Thank you for your added comment. As you reiterated ... our networking group here is claiming "no exceptions" ... so these false positives are literally shutting down sections of website functionality. I thought about obfuscation/encryption ... just a pain to perform that on a client's browser before postback and then have to unencrypt on the server side. For the time being, my only current solution is working directly on the web server itself, bypassing the firewall entirely. – TekkGuy Dec 14 '22 at 12:50