31

My SaaS company recently lost the bid for an enterprise software licensing deal.

One of the reasons the prospect gave for not choosing us as a vendor was:

the use of a WAF

I'm not an information security specialist, so I'm confused as to why the use of a WAF (Web Application Firewall) could be seen as a potential security vulnerability.

Is it best to avoid using a WAF? Could they be concerned because the use of a WAF suggests inadequate protection? Is their concern legitimate?


The full quote[^1] is as follows.

Technical Integration – $PROSPECT is a multi-national subsidiary of an industry leader in $INDUSTRY, which brings with it a lot of cyber security risks. This means our technical security standards are high, so $TECH_DUE_DILIGENCE_PROVIDER raised concerns about the implications of $REASON_1, the use of a WAF, and $REASON_2. Although in isolation these issues may seem minor, the cumulative risk and potential exposure was difficult to overlook – which ultimately led to $VENDOR being classed as a ‘high risk vendor' by IT.

[1^]: irrelevant or sensitive information redacted; emphasis mine.

13
  • 1
    But from that note, I'd ask for clarification. Doesn't make sense to me. "use of a WAF" is not an explanation.
    – schroeder
    Nov 27, 2023 at 10:27
  • 3
    I'm afraid that the key is Although in isolation these issues may seem minor, the cumulative risk and potential exposure was difficult to overlook. By itself having a WAF as an additional defence line is not bad. But pretexting a WAF for lowering other defence lines is. Nov 27, 2023 at 10:50
  • 6
    @Anon, you only give partial informations. Most languages do have versions, some of them are no longer maintained. Using a no longer maintained thing (be it a language, framework or library) is seen as poor security practice. And using an old version even if maintained comes with an additional risk of using other old libraries or modules, some of them could in turn no longer be maintained. But for example PHP based applications are often seen as less secure than Java based ones, just because many third party PHP modules authors did not pay enough attention to security... Nov 27, 2023 at 11:23
  • 5
    ... Finally they are the client. That means that if they are consistent in their security referential, there is little you can do, past politely asking for explainations, telling them that you would like to later be able to provide them a response that they could accept. Nov 27, 2023 at 11:26
  • 3
    Web application firewalls tend to corrupt or block legitimate traffic.
    – Jasen
    Nov 28, 2023 at 2:46

8 Answers 8

35

A WAF is fundamentally a MITM attack against your own web services. It intercepts, and, in the event that it has a vulnerability, backdoor, poor handling of data transmission or storage, etc., has the capability to record and exfiltrate highly sensitive data including session tokens, credentials, private information, etc. It is an additional layer that, in order for your system as a whole to be secure, must also be secure against all the same sorts of threats. It is additional attack surface.

These are not merely theoretical considerations. Again and again, there have been compromises involving sloppy WAFs. And this makes sense: given that there is a correlation between viewing WAF as a "security solution" and having very naive ideas about security architecture and attack surface, a WAF is at least as likely to have vulnerabilities as a web application whose implementors only have mediocre security experience, if not more likely.

19
  • 13
    The same could be said for the IP-level firewall in front of the website, the load balancer, the router, the switch, the TLS off-loading module, etc. Are you saying that a WAF is a special risk?
    – schroeder
    Nov 27, 2023 at 20:05
  • 10
    "a WAF is at least as likely to have vulnerabilities as a web application" -- citation needed
    – schroeder
    Nov 27, 2023 at 20:06
  • 33
    "The same could be said for the IP-level firewall in front of the website, the load balancer, the router, the switch, the TLS off-loading module"--These don't decrypt traffic, they just pass it a long. In order for a WAF to work, it needs decrypted access to the application traffic. In other words, something with a WAF wouldn't be end-to-end encrypted.
    – nijave
    Nov 27, 2023 at 20:16
  • 9
    While I agree that the use of a WAF highly correlates with a poor secure SDLC, I'm hesitant to call a WAF a MITM attack. Assuming it's deployed on-premise (so it's not on the edge, like a CDN WAF, or a total detour to third-party servers). I'm hesitating because, by that definition, even your MVC framework would be a MITM. Or any library you use to process your data. Of course, you must assess the WAF's company reputation first but many WAFs are just augmented reverse proxies deployed autonomously. Nov 28, 2023 at 9:56
  • 8
    @Anon "does that assessment change if the WAF is tailor-made to the web application?" - the assessment about mismatch and protection, yes. The assessment on the attack surface, no. However, I'd still consider it a sign of incompetence to build and run two web applications where one would have sufficed… it looks like security was only an afterthought, why not just build the tailored security into the primary application?
    – Bergi
    Nov 29, 2023 at 0:38
32

One possible explanation would be that they think you rely on a WAF for your security, rather than using it as an additional security layer. I've met people who have very insecure legacy sites (full of XSS, SQLi, etc), but they think that it's OK because "they have a WAF", and they think that's sufficient to protect them.

So if they asked a question like "How to you ensure that your website is secure?" and your answer was just "We have a WAF" then that would raise concerns. But if you gave a full explanation about what you do (secure development, patching, etc), and added to the end that you have a WAF as an additional layer, that shouldn't be an issue.

If you're using a cloud-based WAF, there could also potentially be concerned there about that, and who the third party is that you're exposing all their data to? They may not be happy with everything being sent to Cloudflare/Akamai/whoever.

But it does seem a rather odd response - and certainly something I'd go back to them and ask for clarification on.

1
  • 22
    Even if you're not relying on it as security, a WAF is a huge additional risk. It's a MITM that has access to all traffic, all access tokens, credentials, etc. and that's implemented by folks with very dubious ideas about security architecture and attack surface. Nov 27, 2023 at 19:14
9

One thing I can think of, and I don't know if this applies to you, is if a WAF has been used instead of fixing application vulnerabilities. Sometimes companies do this, especially when it's difficult to make changes to the application. But it is a weak approach compared to fixing the vulnerabilities, as typically WAF controls can be bypassed by a determined attacker.

4

You mentioned your product is implemented in an older programming language dating to 1990. This suggests Python, Haskell or something more obscure (and if so likely worse).

The customer's security report has identified use of a Web Application Firewall in front of the application. One likely assumption many would make is that your application has a WAF because it is insecure without.

What does a WAF do? According to Wikipedia they monitor content and attempt to detect & block:

  • SQL injection,
  • cross-site scripting (XSS)
  • file inclusion
  • improper system configuration.

Wikipedia recommends against them saying "they also introduce a performance degradation and are easily bypassed by attackers."

You also answered, again in comments, that the WAF in question "In our case, it's a [very] small application that we maintain, audit, and build from source. It runs adjacent to our web application."

Now, if I was doing security diligence in a sector vulnerable to attacks:

  1. Old/ insecure languages are going to put me right off. Haskell is a good language, I don't want a Python appserver, anything else is likely a total load of cobblers.

  2. Having the WAF, and the generally understood purposes of a WAF, can easily feed into a perception that your underlying app & security may be very weak; and that you may be highly reliant on the WAF for security.

  3. Many of the kind of things that Wikipedia suggests a WAF protects against -- such as SQL injection -- I would consider absolutely unacceptable to be in the core application. I would not accept these anti-patterns present anywhere whether an attempt had been made to mitigate them at other levels or not.

  4. Perhaps the customer was willing to overlook security weakness of the core, if the WAF was solid. But what WAF are you using? Is independently known and reputable, something the customer can really trust in? Apparently not -- it's a small application you maintain and build yourself.

I'm presenting solely the critical view here so this will be negative, but ask yourself:

Would you, as a customer, trust a company with outdated technology, poor security and maybe using bad practices (SQL injections?) to maintain & build a security layer that needs to be 1000% secure?

Or would you instead prefer to choose a vendor with current technology (likely a memory-safe compiled language such as Java/Kotlin, C#, Rust, Go), good security and robust practices?

I am sure there is much we don't know, but perhaps this feedback could inform your company in regard of selecting & building a more secure technology architecture.

3
  • 2
    I appreciate you're trying to empathise with the client, and not arguing whether or not any given language is "old". For me though, it raises the question: how old is any given programming language? And does it matter? Is Haskell as old as its first implementation? Or is it as old as its latest major compiler version? Or latest stable release? Essentially all RDBMS queries are done in SQL which first appeared in 1972, but I don't see anyone arguing that the use of SQL queries is a red flag. PHP arrived years after Haskell, but it certainly isn't safer, etc., etc.
    – Anon
    Dec 1, 2023 at 12:04
  • @Anon In regards of security, concerns are probably memory safety and reliability (that code reliably does what was intended). Garbage collected or memory-safe languages help with the first, and became much more prevalent from 2000 onward. Compiled, type-checked, declarative and to some extent functional languages help with the second.
    – Thomas W
    Dec 4, 2023 at 22:49
  • The general state of language technology in 1990 was imperative, non memory-safe compiled languages or weakly-typed interpreters (Perl, Python). Haskell as an academic language was well ahead as far as language design goes. From my perspective broad commercial acceptance of memory-safe languages came with Java 1.3 in 2000, which combined GC, threading, and network functionality in a portable language. I see a robust language foundation (memory-safety & compilation) as ideal for security. For me that is Haskell, Java, C#, Rust, Go.
    – Thomas W
    Dec 4, 2023 at 22:54
3

The reviewer deemed the WAF a negative, when combined with the other 2 reasons which are not provided here. Therefore we can't really answer the question, because seriously, in general (ie without other reasons) a WAF is better than no WAF. Some situations where a WAF would be deemed negative, compared to no WAF in the same situation :

  1. if end-to-end encryption is required and the WAF is not sufficiently configurable (eg it cannot do anything if e2ee is needed, in which case a WAF is just another layer of maintenance, cost, and network lag)
  2. if the WAF is in-house
  3. if the WAF does not meet (or cannot be shown to meet) one or more essential standards
  4. if there is requirement for privacy (the WAF has to introspect)

There are probably more reasons. Really wish we could know what those 2 other reasons are.

Update

Here's an interesting article that I just came across, referenced in Hashicorp's newsletter, on that exact topic: https://www.macchaffee.com/blog/2023/wafs

5
  • What standards for WAFs are there?
    – Bergi
    Dec 7, 2023 at 22:19
  • 1
    SANS, NIST, NSA, ISO/IEC, OWASP, they may have recommendations / guides that the reviewer has in high regard, even if they are not standards in the official sense that's the idea
    – Oliver
    Dec 8, 2023 at 22:48
  • 1
    I have to agree with this as well. WAF, by itself, is no reason to reject a solution. A real WAF only enhances the security of access to an application. There are many more companies that would reject a vendor if there was NO WAF in place. WAF plus $REASON_1 and $REASON_2 must be the real reason.
    – JD Allen
    Dec 8, 2023 at 23:45
  • @Oliver "they may have" - do you have any concrete links?
    – Bergi
    Dec 9, 2023 at 1:47
  • @JDAllen "A real WAF" sounds like a true scotsman
    – Bergi
    Dec 9, 2023 at 1:48
1

What could be a consideration is that, even with a secure connection between Client->WAF, and then WAF->Your server, the WAF by definition has access to the raw request/response. In a case where data security (for example healthcare, finance) requires full encryption in transit, this is a big loophole, and essentially potentially provides a third party with access to the data.

Edit: My above discussed cloud WAF, and as such the concern that a third party has potential access to the unencrypted data.

4
  • Most real WAFs do not touch a packet's payload, so this should not have been the issue.
    – JD Allen
    Dec 8, 2023 at 23:47
  • @JDAllen What do you mean by "touch"?
    – Bergi
    Dec 9, 2023 at 1:45
  • This depends on what WAF is used and how it is configured. An on-prem WAF built into the server stack is not a problem for "full encryption in transit". And this answer echoes another answer.
    – schroeder
    Dec 9, 2023 at 9:06
  • "touch" = inspect, and possibly modify
    – JD Allen
    Dec 10, 2023 at 15:15
0

As @Jasen mentioned in one of its comments, Web application firewalls tend to corrupt or block legitimate traffic.

In one of our project we had WAF & one of specific functionality our application was doing to upload different kind of document to our portal. We had seen major issues where WAF was blocking traffic pretty randomly because of some of rules (specifically XSS rule) was interpreting document we were uploading had malicious content.

There was no issue with documents we upload but after deep diving we saw some of meta-data of document are cause of concerns but again that too vary with machine from where these documents got created.

We end up modifying & disabling some of WAF rules because as we already had solid file scanner in place. So long story short, we didn't relay on WAF for security but there were additional security measures in place.

Considering this scenario, my assumption is that you are primarily relying on WAF for your security which might have raised red flag during review process.

1
  • "my assumption is that you are primarily relying on WAF for your security" I think this is where I'm struggling. I can't work out how anyone could just make that blanket assumption. You (and others) have outlined where the use of some software in front of your web application might make sense as part of a defence in depth strategy. The client in question jumped straight to the [wrong] conclusion that you did here.
    – Anon
    Dec 1, 2023 at 12:16
0

I would never call a WAF a security vulnerability by itself. That is, unless there is a known issue with your specific implementation. There are three primary issues with using a WAF en lieu of finding/fixing vulnerabilities:

  1. The WAF, by definition, is unaware of the context (with regard to the backend application) of a request. Because of this it can only block certain types of attacks (typically injection style attacks). Even then, clever attackers can often evade the protection through various reformating/reencoding techniques that bypass the rules in the WAF. A WAF is never going to be able to detect and stop logic-level vulnerabilities, or at least not without very careful, custom tuning.

  2. Even if a WAF was 100% effective at blocking the attacks against your application, it still is acting only as a wall between the attacker and your vulnerable application. This means that if the attacker can get past the wall, the WAF will no longer protect you. Common scenarios where this could occur include:

    • The attacker lands a phishing foothold and can tunnel to the app from a "trusted" internal corporate IP address.

    • A poorly configured WAF may be circumvented by directly accessing the IP of the webserver or load balancer behind the WAF.

    • A server-side forgery attack might allow the malicious request to appear to originate from the same subnet or server as the vulnerable code, thus bypassing the WAF.

  3. It is difficult for a WAF to always stitch requests together and view them the same way the application does. This is due to the fact that each webserver, loadbalancer, proxy, etc. may chop up and interpret the request slightly differently. This means that new bypasses are always being discovered from transport-encoding, TLS parsing, cache-poisoning, and other attack methods.

The bottom line is that a WAF should always be viewed as a defense-in-depth technique or a quick mitigation while more thorough fixes are implemented. It is always an imperfect solution, unlike patching known vulnerabilities in the underlying software.

You must log in to answer this question.

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