Test Your WAF and Make it Your Friend with Franziska Buehler

Five, four, three, two, one.

Drop that.

Welcome to the Test Guild Security Podcast. We're all getting together to learn more about security testing with your host, Joe Calantonio.

Hey, it's Joe. And welcome to another episode of the Test Guild Security Testing Podcast. Today we'll be talking with Francisca Buhler all about web application Firewall security and OWASP core rules. Francisca is an architect at Swissport where she combines her passion for IT security, DevOps and open source software. She is highly experienced in reverse proxy platforms and web application firewalls from her extensive experience at the Swiss Port and as a co developer of the OWASP MOD Security Core rule set. She's also part of the OWASP Dev Slot team and she also speaks at conferences all over the world, providing technical training throughout Europe and also online for DevOps days and secure Guild. So really excited to have her. Listen up.

It's no secret that the number and complexity of applications are growing, but what is alarming is that 90% of security incidents result from exploits against defects in software. The need for better application security has never been higher and Micro Focus Fortify is here to help. Fortify is the recognized market leader in application security and it is the most comprehensive and scalable application security solution that works with your current development tools and processes. With Fortify, you can start security applications in a single day, including custom code, open source or commercial components and scale as your needs grow with an on premise as a service or hybrid implementation. Check them out. Head on over to micro focus.com Apple Security Hey Francisca, welcome to the Guild.

Hi Joel, thank you for having me.

Thank you so much for joining us. But before we get into it, is there anything you'd like to add to your intro that I may have missed?

As you mentioned, I'm working at Puzzle itc, a Swiss company and I'm here to improve the security and I'm also an active member of the OWASP foundation where I try to help improve security of web applications.

You've been doing a lot of conferences and especially you've been focusing on the topic of web application firewall security. So why do you think that area of security is so important?

I think it's important to have an additional layer of defense in front of a web application because it's difficult to write 100% secure code or it's almost impossible. So you will always have.

Vulnerabilities or problems in the web application. And I think with a web application firewall in front of it, you don't have a solution for all problems. But you have an additional safety net in front of the web application and maybe you can sleep a little bit better when you know you have a WAF in front of it, you have a little bit of more security.

Awesome. So for the folks that don't know, I should start with this question. What is a firewall and what does it do and why should it be secure?

Okay. We have different types of firewalls. We have traditional or typical firewalls that work on the TCP or IP layer that block special TCP ports or IP addresses. And web application firewalls works at a higher level at application layer. And it looks into the traffic. It not only blocks TCP or IP address, TCP ports or IP addresses, but it also looks into the HTTP traffic and it looks if there is an attack in an HTTP request, for example, so you have deeper, you look deeper into the request.

So it sounds like if someone was trying to hack into your system, do they scan ports and see if there's an open port that's normally secured, and if it's not secure, they're able then to somehow get into your system using that particular port.

Okay.

To use, to find open ports, you typically use port scanners. And once you found an open port that listens on HTTP or HTTPs, you can try to.

Attack the web application that sits behind this port, or you can try to attack the web server that sits behind this port. And with a web application firewall, it's more difficult to do a web application attack because when you for example, try to do an SQL injection into the web application, or you want to do cross site scripting, or if you want to to misconfigure the HTTP protocol to make an attack, the web application firewall probably will detect this attack in your HTTP request and it will hopefully block you. And it also examines HTTP responses. So if you have been successful to do an attack against a web application and you have an error message, for example, or a ST or data leakage in general, the web application firewall is possible to detect such information leakage or detailed error messages which can have sensitive information about internal structure. So the web application firewall could also block an outgoing response.

Awesome. Do you know how many like maybe percentage wise or how common it is for for this to be hacked if someone doesn't have either IT set up correctly or not have a web firewall properly set up?

We say that we have different installation, we have different paranoia levels. In the CORAL set, we have four different paranoia levels. Paranoia level one is the Standard installation. And we say that we with paranoia level one with the standard installation, you probably have no false positives. And we say that you have about maybe 80% of coverage of web app attacks. Of course, it's always possible to circumvent web application firewall. You can always.

Try to trick it out. But it's harder to make a web application attack with a WAF in front of the web application. And we say that we have maybe 80% shelter in the default installation. But yeah, it's difficult to say in general.

Being new to security, I'm also kind of new to the terminology. So I also came across some things where you talk about mod security in the core rule set. What is mod security and the core rule set and how does it apply to WAFs?

Yeah, we have different WAFs on the market and one of them is mod Security. It's an open source and free web application firewall. It's very widespread and popular. It's available as Nginx, Apache, IaaS modules and some more. And now mod security is the engine and the engine has no rules yet. Now the engine needs rules to do its job, to detect attack patterns in the HTTP traffic. And here is where the OWASP mod Security core rule set comes in. Because the core rule set is a rule set against web application attacks. It's an open source project too. It's an OWASP flagship project. It's very popular, I think it's blacklisting rule set and it mainly consists of regular expressions. We are a very active project and we released 3.2 in last September. I think it's very easy to install and we also have a Docker container to use it. It's a cool project, I think.

Yes. How does it work? Like I said, you install it and then it automatically applies those rules that are commonly exploited. So it protects you from those particular vulnerabilities.

Yeah, of course you have to have mod security installed first and then you only have three steps to install the core rule set. You download the zip file or you clone the git repository. And then we have an example configuration file. You move or copy this example configuration file to your configuration file. You don't have to change anything in the configuration file itself. And then you include the rule files. We have different rule files that it has regular expressions for request rules. We have request rules and response rules. You include these rules and it's done. And you already have a working WAF with hopefully no false positives and a good coverage against web app attacks. And of course you can also use the Docker container and there you have to install nothing, you just have. Yeah, it's just a container.

A big trend is people trying to get things in their CI CD pipeline. So is there a way you can make WAF part of your, say, your DevOps workflow?

Yes, I think it doesn't make sense to have a DevOps environment and then you just put the WAF in production and you will probably have false positives and problems in production. And of course, with the Coral Set container, for example, it's very easy to add a WAAF to a CI CD pipeline. You probably have end to end tests or web application tests. And what you can do now is you just put the WAF between your tests and the web application firewall. The web application, of course. So you test the web application through your web application firewall and you will have the chance to fail early and fast and to delete your false positives in your CID CD pipeline already and not in production, when you will have problems, which is too late, of course. So if you have web app tests, you should do the test with a WAF already and the test should be successful and you should not have false positives. So your mod security logs should be empty, of course. And I think it makes sense to release an application or to go into production with a web application only if it's tested with a WAF in front of it, so you won't have problems in production.

So you've mentioned false positives a few times. Is there a way you can avoid false positives or any best practices so that you can avoid a lot of false positives?

Yeah, if you have false positives, you have different possibilities to tune them away. Maybe you have false positives just in the way you're. You name your arguments or your cookies or cookie names, for example, so you have the chance to rename them if they cause false positives. Or you have the possibility to do mod security tuning.

You can change a rule or part of a rule so it's not checked anymore. And you have the chance to do this early. And then if you have your mod security tuning rules, you can add them to production and you won't have problems there. Or of course, if you think that's a problem that everyone has, you can also open a GitHub issue in our Coral Set project and we try to tune this false positive away for everyone.

So you did mention testing your web application security. Are there any tools or test tools you can use to help you with testing your web application? Firewall.

Very popular tools that are used to test a web application like an end user does is Selenium, for example, or what I use also in my demos and in my conferences I use Test Cafe. It's very small, it's very easy to write tests. And the thing here is to automate your tests so you don't have to do them every time you release a new release. And Yes, I use TestCafe here. It's open source and very easy to write, I think. But of course there are also other tools available.

Cool. So it's just like anything else, I guess, in your pipeline you have a set of tests that are dedicated just to testing your waf. And if they don't pass, obviously the code doesn't get shipped to production. Is that how it typically works?

Okay, if your tests do not pass, either you have a problem with your tests or web application, then it's another problem. And if your tests do not pass because of the web application firewall, you have to change the application or you do mod security tuning so that the tests pass again so that the legitimate tests do not trigger a Coral set rule or do not trigger the waf. Because sometimes a false positive. The problem here is that sometimes a legitimate request looks a bit like an attack. And I always use an example here. The address 100 Union street that triggered an SQL injection rule because of 100 in conjunction with Union smells a bit like SQL injection. But of course the address is not an attack and so we had to tune this false positive away.

Is there anything about WAF security you think is misunderstood or folks don't know enough about?

I think a lot of people fear web application firewalls because.

It was hard to use it. But we released 3.0 and I'm not sure anymore in 2017 and our goal with 3.0 was to have as less false positives as possible and still have a good coverage. So the goal was to. It's not only for WAF experts and it's usable by everyone.

So are there any resources you recommend to someone trying to learn more about WAF security or security in general?

Okay. If you want to learn about our Coral SET project, you can of course go to coralset.org or if you want to have more information about mods security, there is modsecurity.org and of course in general, if you want to learn about web app security, you have many, many resources on owasp, the Open Web Application Security project.

Many resources and a lot to learn about it.

Cool. So another term that Comes up a lot when I see your bio is OWASP Dev Slope pkce. What's owasp Dev Slop PKCE owasp Dev.

Slop is another project where you also contribute. It stands for Sloppy DevOps. And Dev Slop has different modules. We have blog posts, we have YouTube shows with Tanya Janka and Nancy Karachay, we have pipelines on GitHub, how to do DevSecOps and Pixie is one part of Dev Slab. It's a vulnerable web application written by Nicole Becker. And the goal there is to learn how to hack a vulnerable web application. And there are also videos on YouTube available with Tanya Janka and Nicole Becker on how to hack Pixie. And what I do, what I have is I have a Pixie CRS pipeline where I combined the Coral Set with PKCE to show how a web application could be tested and how the Coral Set can protect against web application attacks. Because of course Pixie is vulnerable.

You're very active in the community, you give generously of your time. How did you get into open source contribution in OWASP?

I think I started in 2016 when Christian Follini, he's one of the Coral Set co leads, he just asked me if I want to help write rules and help extend the Coral Set. And yeah, I think I began in 2016 with the coral Set and then yeah, things grow. And in 2018 I think I joined OWASP Dev Slob. I started to speak at conferences and yeah, I think it started like that.

Nice. So if someone is, I think a lot of people are scared to contribute as well. How would one get started, say, helping out, say the OWASP project or dev slot? Can anyone contribute or help out?

Of course everyone could contribute. We are, I think at coral set and DEVSLab both. We are a very friendly and open community and everyone is welcome. And for example, for the Coral Set, we have.

Issues tagged as good first issues. So for a beginner who wants to start contributing, that would be something he can do or she can do. So everyone is welcome. And of course help is always very welcome. And we always welcome new contributors. And we have a Coral Set meeting on every first Monday of the month where we talk about new issues, pull requests, open problems, and of course everyone is welcome there too.

Okay, Francisca, before we go, is there one piece of actionable advice you can give someone to help them with their security testing efforts and let us know the best way to find or contact you?

Of course my advice would be use a web application firewall, use it in a pipeline and in production. Of course it's not the silver bullet against every attack, but it a good safety net for you and your web application. And you can contact me on Twitter. My Twitter handle is poofrash. I don't know if I spell it correctly. Or you can contact me on LinkedIn or you can write me an email.

Yeah, there are many possibilities to contact me.

Thank you Francisca for your security testing awesomeness. For links to everything of value we covered in this episode, head on over to testguild.com sslikesecurity04 and while you're there, make sure to click on the Try Today link under the Exclusive Sponsor section to learn all about Micro Focus's Fortify, which is the recognized market leader in application security. So you definitely want to check that out. So that's it for this episode of the Test Guild Security Testing Podcast. I'm Joe and my mission is to help you succeed with creating end to end full stack automation awesomeness. As always, test everything and keep the good. Cheers.

Thanks for listening to the Test Guild Security Podcast. Head on over to testguild.com for full show notes, amazing blog articles and online online testing conferences. Make sure to subscribe to join the Guild and continue your testing journey. This has been a Joe Calantonio production.