The following is a transcript of the “Hacker Reacts to Web Application Firewall” livestream - it has been minimally edited for clarity.
Gaby: Good morning, good afternoon, good evening. Today I have a very special guest, Harel Friedlander - there’s a reason we both have the same last name. We're going to have a very interesting conversation today. But before we start, why don't we get to know you a little bit, Harel?
Can you share a little bit about yourself? And then we're going to jump into the topic of the day.
Harel: Great. So my name is Harel Friedlander. I'm a hacker, penetration tester, and security researcher, as well as a bug bounty hunter in my free time.
I started hacking when I was 14. I was still a script kiddie, doing some Wi-Fi hacking and stuff like that.
And then around high school, I really got into CTFs - started playing a lot, you know, building my skills. While in high school, I hacked my school's information system. That's how I got one of my first jobs in cybersecurity as a security researcher there.
And I gained a lot of experience there in web application testing. Now I'm doing penetration testing and bug bounty hunting. I've hacked quite a lot of big companies. One pentest I did for Glassdoor, which I've written research on, was nominated for one of the top 10 techniques in 2022. It was a very cool technique of Web cache poisoning with parser confusion - it's pretty neat if you want to check it out. “Caching the Un-cacheables - Abusing URL Parser Confusions (Web Cache Poisoning Technique)”
And recently I’ve worked for some cool companies. I'm not allowed to disclose, but one is a big AI Company and the other is a meeting company. But yeah, that's a little bit about me.
Gaby: So let's deep dive and explain to me what's going on and how you're doing it. I thought we could have this discussion live and share it with others, but for those who don't know what a WAF is, can you share what it is, and what it's supposed to do?
And then we're going to talk about how you overcome it.
Harel: Yeah, sure. So a WAF stands for web application firewall, and it does exactly what it sounds like it does - it's supposed to protect you from web attacks like any injection vulnerabilities and DDoS.
That's pretty much it.
Gaby: So if it's supposed to do all of that how come it's so easy for you to bypass them? I've hardly ever heard you struggling with any web application because of a firewall. What's going on? Why is it relatively easy?
Harel: The thing about WAFs is well, they're trying to protect you, right?
And by that, you need to block requests. WAFs are missing a lot of context. It's trying its best to say what's malicious and what's not. It’s very hard to differentiate between legitimate user input and malicious user input. So it's trying its best and trying to find the right balance between letting things in and blocking certain things. If you want it to be 100 % protected, you just block every single request, but that's not realistically possible.
You need to find sort of a middle ground between what's malicious and what's not. And that's what we're attempting to do.
Gaby: So you spoke to me earlier about the difference between detecting a vulnerability and exploiting it; about sanitizing it. Can you explain that and give an example?
Harel: What a WAF isn't supposed to do is patch your vulnerability.
It attempts to detect vulnerabilities instead of trying to sanitize them like you would if you were to actually fix a vulnerability. I'm talking specifically about injection vulnerabilities right now. A WAF is not supposed to fix a vulnerability- this means that if I were to try to detect a vulnerability, like, let's say, an XSS vulnerability, I would try to see if there is sanitization on the server or not.
And the way I do that is not by going and giving it an actual XSS payload because the WAF will see that it's a payload and block it. The way I would do that is by putting special characters that I know I need to make myself an XSS payload.
And that would be like, just quotes and less than, greater than signs and certain special characters like that, which by itself are not really malicious, right? These are characters we use all the time.
So a WAF can't block that, right? If it blocks that, then we get to the point where it needs to balance what's legitimate and what's not. That is why it's so hard to do. The way that I personally go about detecting payload, detecting vulnerabilities is by manually seeing if these characters are reflected or not.
Because these are innocent and no WAF is going to block just these characters, it's easy to detect them. The issue comes when you're trying to exploit it. That's what a WAF is attempting to block. A WAF is looking at the payload as if you were looking at it in your eyes, right?
Imagine the WAF had eyes, it looked at your payload and said, oh, this is obviously an XSS payload trying to steal my cookies and send them to a malicious server, I'm going to block that; or even as simple as injecting a script tag that suggests you're trying to run JavaScript.
A WAF tries to look at it and tell if it's malicious, sort of like by eye-balling it. It's not trying to sanitize. If you were to sanitize your user input, then you would encode these special characters and you wouldn't necessarily block them, right? You let it through, but you will encode it safely like you're supposed to do.
Gaby: So you send the character that is not necessarily malicious by itself. Like the greater sign and stuff like that. If you detect a vulnerability, for example, that the code didn't sanitize this parameter by looking at how it's reflected back, you can see, it wasn't escaped then you know that the developer didn't sanitize the parameters.
Gaby: So now, you know there's a vulnerability here for sure. What needs to be done next? It's to exploit it. So let's talk about that part. You found a parameter that is not sanitized or done in a proper way but the WAF is looking for an exploit, right? They're looking for that script.
So how do you overcome that gap because you want to exploit it? You don't just want to find a vulnerability. You want to exploit the vulnerability. How do you bypass that part?
Harel: I just try to talk to the WAF to see what it likes and what it doesn't like. So I start with as basic of a payload as I can.
I don't try to bypass anything. I go with something that I know the WAF will block, for example, a script tag. Let's say my user input was reflected within the JavaScript context. I put in a closing script tag. I know that the WAF will block that. Most WAFs block that.
I try to see what does it not like exactly about the script tag? Is it complete? So I delete a character and see, does it like this? Does it not like this? I do an incomplete script tag, for example, and I try to find the line where the WAF says, “this is okay and this is not.” And I work around that. The WAF doesn't consider the context of the web application. So I can use certain quirks to break down the payload in a way that will confuse the WAF.
Other times it's simply a different tag that I can use with certain attributes. I sort of play around with it. Eventually, more often than not, I find a way around it. While I can't say exactly, I would estimate around 70 - 80% of the time, maybe even more, I can bypass a WAF with no problem.
And it's actually pretty fun because it's a challenge. It makes my payload look sometimes really, really cool, right? You show it off to your friends and they're like, holy crap, this looks sick. But in reality, it's just a WAF bypass with a simple XSS payload.
Gaby: You also said that even if a WAF would be 100%configured, let's say the best WAF configuration ever, still there's a huge category of web attacks that can go through the front door through the WAF because it's not meant to detect them. And those are some of the major ones. Do you want to talk about that?
Harel: So those would be logic bugs, authorization bugs,and authentication bugs.
The most common vulnerability you see nowadays would be IDORs, right? And IDORs by themselves, look innocent. You look at an XSS failure, and that's an XSS failure. You look at an SQL injection failure, and you say, that's an SQL injection.
But you look at an IDOR and you just see a normal request requesting something from the API, for example - settings or credit card information - but from a different ID. And since the WAF doesn't have the context of the application, it doesn't understand the logic. So it's almost impossible to say if this is an IDOR payload or not.
It's abusing the fact that there is missing authentication, there is missing authorization. You're just literally, if you could rename the IDOR, you can just say ID substitution, you're substituting an ID for a different ID, and you're getting someone else's information.
It's as simple as it gets the most simple vulnerability, in my opinion, and it's just no fun, in my opinion, because I like more complex things but it's so common. You have an entire class of API vulnerabilities, logic vulnerabilities,which the WAF just cannot detect and that is an entire missing attack surface that the WAF won't protect you against.
Gaby: So when we read that, WAF takes care of the OWASP 10 -that's a bit overrated, let's call it that way.
Harel: I mean even if it attempts to block IDORs and stuff like that, it attempts to protect you, it doesn't protect you. If you were to deal with an actual, persistent attacker who cares about bypassing your stuff, he will. There's no way around it.
Gaby: We talked about the weaknesses of the WAF, so what is it good for? Because everybody's using it there has to be an advantage of using a WAF.
Harel: Yeah, like I said before, if you're dealing with someone who's manually going to look at your application, any attacker with a bit of experience will be able to bypass it eventually - they're specifically targeting you.
However, most of the attackers that you will see are just automated scripts, scanners, bots, and script kiddies. So the WAF will probably be effective in blocking those, and obviously, you're trying to integrate some WAF bypasses, but the WAF is going to catch them all. That is personally why I'm not a big fan of these types of scanners, because I just do a better job myself manually. A WAF is good at getting rid of those low-level attackers.
And, you know, DDoS stuff like that, DOS those you know, you'd have to configure it as such, but it can help you with those specific instances.
Gaby: So you mentioned that the WAF gets rid of the tire kickers.
Harel: Yeah, WAFs get rid of the noise of the attacker world.
Gaby: So when you're looking for a needle in a haystack, it shrinks the haystack significantly. And allows you to focus on the more sophisticated attacks and the ones that probably you would not have seen because of the noise.
Gaby: What do companies need to protect themselves against web attacks? What do you usually see when you say to yourself ‘this is too hard’?
Harel: When you code securely, it's tough, because there's no way of getting around it because your code is secure, so there's no vulnerability. You want to avoid having a vulnerability in the first place - which is extremely hard to do and not realistically possible to have an application with no vulnerabilities.
But if you want to be secure, you need to try your best to follow good security standards and security best practices making sure that you address all vulnerabilities and code securely.
Don't confuse a WAF with good secure code. Don’t say as a security person “Oh, it’s okay we have a WAF.”
If you say “It’s ok we have a WAF,” I'm gonna attack your website, because I know since I can bypass the WAF I know I will find vulnerabilities. A WAF is an extension to your security system, don’t use it as a replacement for good code.
Writing secure code and following all the best security practices is very important.
Gaby: Maybe this is a topic for another day but the complexity of the infrastructures that are deployed today makes it easier for you to hack. We no longer have just a web server and that’s it. We have cache servers, web servers, front end, back end, and a lot of web services and APIs. Even if each one of them is configured perfectly from a security point of view the issue is what happens in the way they talk to each other.
So like parser confusion, I think that's sort of what happened with Glassdoor.
Harel: Yeah. I'll give you another example. So I was recently looking at this web application that was using a gateway API, and forwarding all the requests to internal APIs.
And they were both written in two different languages. So the two different languages parsed the URL differently. And the gateway URL, and the gateway API was doing all the authentication and authorization. So if you were able to bypass that and get the internal API, then you have like no authorization, authentication on anything.
The way I was able to bypass that is by using the simplest, easiest bug I've ever done - add a forward slash at the end. The gateway API looked at the URL, saw a forward slash at the end, and thought, this endpoint does not exist, I will forward that to the internal API to deal with the 404.
The internal API looked at it, and said, this is valid, it's just a forward slash, so I'm going to return whatever you asked for. That allowed me to bypass all of the authentication, all the authorization and I was able to take over any user that I wanted and to do anything I wanted with it on a massive scale. These types of vulnerabilities aren't necessarily issues with the code itself. It’s not something you can eyeball.
Parsers in different languages are different and this is a more modern attack that I see nowadays where it's just parser confusions, you know, like differentials and the way that certain interpreters are interpreting URLs, HTTP packets, etc.
Gaby: If you're launching an app, WAF is a good idea to have. It gets rid of the noise and allows you to focus more on the sophisticated attacks or the manual attacks. But I would also advise you to code securely and have your team trained on secure coding. That’s part of what we do here at Wizer - helping companies learn how to code securely.
It's a mission because of everything you spoke about. You just can't live with a false sense of security when you buy a product that allows you to code in a non-secure way. I would also advise companies to have somebody review their code.
So I think, there are different levels whether it's a pen tester, whether it's a bug bounty program, when do you do each, when do you invite a red team security researchers versus pen testers versus bug bounty - there's different levels. But at the end of the day, you have to have people that are testing your system.
You have to have a security QA for your app and not live in that false sense of security that you just purchased a product that will defend you. It's good marketing but it does not necessarily work and it makes it fun for you.
Harel: Yeah, no, it's very fun.
Gaby: Avishai Avivi is saying [if you do get a WAF] take the time to configure it correctly because there are different levels of hackers, security researchers, bad guys, and good guys - different levels.
For some people, it's a fun challenge and for others, they will just move on to an easier destination. So, take the time to configure the WAF, don't just deploy it. You have to maintain it, too.
Do you have any final thoughts?
Harel: Just make sure that you're coding securely,
Gaby: Cool. So thank you. I enjoyed it. Let's do it again. I think we have a lot of other topics we can talk about. Thank you all for attending.