0

Is it enough to rely on a web application firewall for protection against SQL injection? or should I use other techniques?

During a conversation with a friend he said it is enough to use web application firewall which I disagreed with and my reasons are:

  1. the web application firewall is not configured by us

  2. we cannot guarantee that the client will not need to move the website to another host which might or might not have firewall or maybe not well configured

  3. it is better to provide more layers of security and by that we make the website more complex to attack.

Improve this question
6
  • Client? It appears that you have a lot of details missing from the scenario. Client decisions have no bearing on the question you asked.
    – schroeder ♦
    Sep 5, 2019 at 12:12
  • 3
    Always use prepared statements. It's such an easy to use tool, and such an effective defense mechanism, there is really no reason not to.
    – Conor Mancone
    Sep 5, 2019 at 12:47
  • @schroeder no the clients do not want to deal with technical details, so, he assigned us to decide. and about my first point what i mean is since we do not know how the firewall configured and we are not direct part of it is configuration then we can not rely on it
    – mark820850
    Sep 8, 2019 at 8:53
  • What the client decides has nothing to do with the technical details. It only matters to what you do with the info.
    – schroeder ♦
    Sep 8, 2019 at 10:50
  • 1
    So your question is about a WAF that you do not control and that you do not know how it is configured? That makes this not about WAF's effectiveness in general but about a control that you have no insight into.
    – schroeder ♦
    Sep 8, 2019 at 11:14

3 Answers 3

Reset to default
10

Problems should be addressed at the root and not (insufficiently) taped over.

The root of the problem in your case (SQL injection) is that unexpected and unverified user input can be injected as SQL instructions into your SQL statements. This is due to concatenating strings with SQL instructions together with untrusted user input and treating the result as a trusted SQL statement.

The easiest and fullest protection against this problem is to make injection impossible by eliminating this flawed string concatenation. This can be done using prepared statements.

While only validating the user input could be sufficient too if it would be perfect, it is usually more complex and usually not as perfect as needed either. But validation and normalization of user input should still be done to protect against other attacks like XSS.

This less than ideal approach of only input validation and normalization could also be done by a Web Application Firewall, if the WAF had full knowledge what user input your application expects. To achieve this the WAF would need to be fully adapted to your application. But, WAF installations instead often contain only general rules against typical attacks and are not tightly tuned to the specific instance of the web application. And even if they were tuned once against the application this protection might not be sufficient anymore after the developers changed the application.

Therefore a WAF should only be used as an additional defense as part of defense in depth but not as the only and ultimate protection.

Improve this answer
4
  • "Usually this is not the case. " - when I was installing and configuring WAF's we had to go through a long training and input validation process for the config. Is this not the case anymore? Are WAFs only blunt instruments?
    – schroeder ♦
    Sep 5, 2019 at 12:19
  • @schroeder: This depends on how a WAF is employed, i.e. how much effort is done. If it is only switched on with the common rule sets it will only protect against low effort attacks with common automated tools (which is actually helpful, but not sufficient). Even a WAF which gets tightly adjusted to the application will likely not be adjusted again and again whenever the developers make changes, especially if developers (responsible for the code) and IT security (responsible for the WAF) are in different parts of the organization.
    – Steffen Ullrich
    Sep 5, 2019 at 12:24
  • We implemented a change process that included changes to inputs. It was all part of the push to live process.
    – schroeder ♦
    Sep 5, 2019 at 12:38
  • @schroeder having successfully bypassed WAFs, I would say that it clearly doesn't always work as well as your team made it work. I certainly wouldn't rely on one as the primary layer of security, although such a choice might be more reasonable in the situation you describe.
    – Conor Mancone
    Sep 5, 2019 at 12:45
0

A security control that you do not understand, have not configured, and do not have insight into how it works is never, ever a useful control. It doesn't matter how effective if could be if configured correctly.

So, regardless of what the control is, it doesn't matter that it's a WAF in your case, use the controls that you do have control over. Security controls are not magic bullets that "just work".

Improve this answer
1
  • @JulieinAustin you got blinded by your assumption that I'm just another security guy in the Department of No. Please read my answer. You just echoed my entire point. This discussion is over. I won't be replying to any follow-ups.
    – schroeder ♦
    Sep 10, 2019 at 16:42
-1

No, a WAF is likely not sufficient. It filters incoming network traffic, and can block things that already look like SQL injection, but this all happens before the traffic gets to your application. Data/input manipulation done by your own code can allow/introduce vulnerabilities.

Additionally, if your application accepts input from, or operates on data from, sources other than incoming network traffic, the WAF is irrelevant.

You should make sure to use appropriate security precautions (e.g. prepared statements for SQL) within each component of your system, rather than relying solely on some other component (that may or may not always be there, and may or may not always work as intended) to provide mitigation for you.

Improve this answer
4
  • Your logic is off. Manipulation done by the app code is no longer SQLi. WAF can be used to cover all input sources, so this point is oddly restricted in its assumed scope.
    – schroeder ♦
    Sep 5, 2019 at 12:15
  • @schroeder my point is that what happens between the WAF and the SQL database can still result in "bad SQL" - whether this is a malicious DROP TABLE users type of thing or just SQL syntax errors - which could be mitigated by properly using prepared statements
    – yoozer8
    Sep 5, 2019 at 12:19
  • (while at that point the WAF is no longer relevant and can't do anything about it)
    – yoozer8
    Sep 5, 2019 at 12:19
  • 2
    @schroeder Manipulation here probably means something like base64 decoding user input before inserting it into a query. If the WAF isn't aware of this happening, it could easily be bypassed. This and the out of band issue (it's a WAF after all ;) ) are two good points against just a WAF. If the WAF isn't fine-tuned for this specific application (which I doubt if OPs friend doesn't want to use prepared statements because a WAF is "enough"), it will also result in a lot of false-positives or allow injections in some/many corner-cases (you eg can't filter sleep(1) or 1# everywhere).
    – tim
    Sep 7, 2019 at 14:32

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .