WAF from the scratch
Tips to construct a web application firewall - Date: 04/07/2016
Last updated
Tips to construct a web application firewall - Date: 04/07/2016
Last updated
There are several potential motivations for writing a web application firewall (WAF) from scratch. One motivation is to create a custom WAF that is explicitly tailored to the needs of your web application and your organization. By writing a WAF from scratch, you can design it to provide the exact level of protection that you need, and you can customize it to fit seamlessly with your web application and your overall security strategy.
Another motivation for writing a WAF from scratch is to gain a deeper understanding of how WAFs work and how they can be used to protect web applications. By writing a WAF from scratch, you can learn about the various technologies and techniques used in WAFs, experiment with different approaches and see how they affect the security of your web application.
Finally, writing a WAF from scratch can also be a challenging and rewarding learning experience. It can help you improve your programming skills and knowledge of web security, and it can be a fun and exciting way to explore new technologies and techniques.
Following the definition (like OWASP), a WAF or web application firewall is software intended to protect a web app on the application level. Nowadays, a WAF action is not only defined by the web app. It’s not a customized solution specific to that application but similar to a general software firewall, where one contains parameters to protect against intrusion, and the protection context follows a filter that works through each request and response.
Let's go to clear your mind. There is an overlap between the different types of firewalls. Software and hardware firewalls are used in their own right to protect networks. However, with their specialized function for web applications, WAFs can take the form of input from either of those two main types. By default, a firewall uses a blocklist to protect against an individual, previously logged attacks.
It can also use an allowlist, providing allowable users and instances of interaction for the application. Another function is to block SQL Injection attacks and XSS attacks and soon. In another context, WAFs can create random tokens and put them in HTML forms to stop web robots and automated attacks. This practice can try to mitigate CSRF pitfalls.
A reverse proxy web application firewall (WAF) is a type of security tool placed in front of a web application. It acts as an intermediary between the application and the internet. The reverse proxy WAF receives all incoming traffic to the web application and then forwards it to the application after performing various security checks. This allows the WAF to monitor and control the web application's traffic, helping protect it from various types of attacks.
One of the critical features of a reverse proxy WAF is that it is "transparent" to the client, meaning that the client is unaware that the traffic is being routed through the WAF. This contrasts with a "forward" proxy WAF, which is visible to the client and requires the client to send traffic through the WAF explicitly.
The reverse proxy WAF can perform various security checks on the incoming traffic, such as verifying that the traffic is coming from a trusted source, checking for signs of common web attacks such as SQL injection or cross-site scripting, and filtering out any malicious content. If the WAF detects any suspicious or malicious traffic, it can block the traffic or take other appropriate action to protect the web application.
Overall, a reverse proxy WAF can provide an additional layer of security for a web application, helping protect it from various attacks. Stoping more words, we will study a WAF from scratch.
In this gitbook we meet OctopusWAF, an open-source Web application firewall created in C language that uses lib event to make multiple connections. The event-driven architecture is optimized for many parallel connections, vital for high performance, for example, following AJAX applications. This tool is very light. You can deploy in any, please. This resource turns perfect for protecting specific endpoints that need custom protection.
Reverse proxy function.
Option to load external rules.
Detect anomaly using regex using lib PCRE resources.
Detect security anomalies using algorithms for match strings like DFA, horspool or karp-rabin.
Detect security anomaly using libinjection.
Options to save the log.
Install libpcre or libpcre-dev with apt. If you use RPM-based distro, search the name pcre-devel package, on BSD systems search in ports or brew(MacOS)... You Need libevent-dev to run; on RPM distros libevent-devel, you need to install OpenSSL-dev and OpenSSL-devel.
Example in debian based:
To compile and run OctopusWAF, follow these commands:
Notes: Don't execute with "cd bin; ./OctopusWAF" use full path "bin/OctopusWAF" because binary needs to load content in the config directory. Use HTTP only for WAF usage. This version 0.1 runs TLS but doesn't have a resource to load cert and read TLS requests/responses. If you use TLS, the service can lose the WAF function and work as a reverse proxy.
Tested on Linux but can run in FreeBSD.
So in the past, I have created a WAF using sockets and no external libs(maybe only lib pcre for regex). So just for fun, look at the following:
The purpose of this tool is to use in pentest, take attention if you have proper authorization before using that. I do not have responsibility for your actions. You can use a hammer to construct a house or destroy it, choose the law path, don't be a bad guy, remember.
Thank you for reading.
Cheers!
