Web applications are programs stored on a remote server, delivered via the Internet to a client through a browser interface.
There are challenges in protecting applications. And technological history explains why.
In the early days of the internet, websites were static. Basically, what you had was a browser that read html and set up the page for users to browse. In those early days, user interaction with the site was minimal and very limited. And security was limited to a layer 3 or 4 firewall, which protected the web server from access to ports other than 80/443 (where http access occurs by default).
That's why, at the time, most attacks were aimed at exploiting vulnerabilities in the components of the service that ran on the web server, rather than in the code of the site itself.
In the 1990s, this began to change, with web servers accepting server-side scripts. User interaction with the site began to exist, which allowed the first applications to emerge, such as e-commerce, webmail, blogs and forums.
And here's the first thing to remember. The static site, the first super-simple applications, and today's super-complex applications, running PYTHON, JAVA, HTML5, PHP, ASP, RUBY, all depend on the same protocol to work: good old http.
The problem is that http wasn't created with the idea of being a protocol to support all this complexity. This means that the foundation, the bedrock of today's web applications, is the same as it was 30 years ago.
Web applications are essential tools for business
Data and information are the new money. This has made web applications prime targets for hackers. They are easily accessible via the internet and at the same time connect users to corporate databases. So what separates the user, whether legitimate or malicious, from unrestricted access to company information is the web application.
So it's no exaggeration to say that there will always be someone trying to attack an application. And since today's operating systems have constant update policies, it's easier to find an open door in the application than in the infrastructure.
In this context, what protects the application best?
If we look at the OSI model, we can say that the traditional firewall is not an option. It usually only sees information from the network, so it has no idea what's going on in the application since its decisions are based on port, protocol and IP address.
Is a next generation firewall enough? They are certainly better than traditional ones, because they add more context to decisions and have capabilities such as IPS, web filtering, antivirus and antimalware, which simplifies and improves security management. But they still have their main focus below layer 7. Many attacks will pass through the NGFW without difficulty.
So who's left?
WAF
The WAF - Web Application Firewall - will protect web applications against non-volumetric attacks, both at the application layer and at the network layer.
That's why, when it comes to protecting applications, the best solution is always a WAF, because it is specifically designed to protect that part of the traffic that comes to web applications. So much so that a WAF doesn't replace a perimeter firewall. A company will still need one on its network.
The WAF will compensate, for example, for insecure application developments. Let's say the company has 100 legacy applications, developed when there wasn't such a strong concern for security. It will be much easier, more efficient and cheaper to protect these applications all at once with a WAF than to try to recode them securely.
The WAF will be able to apply a virtual patch to these applications. And because it can fix the application virtually, it is also an excellent tool for protecting against zero-day threats.
Main vulnerabilities
Injection attacks, such as SQL injection, URL injection, LDAP injection, which are common and exploit flaws in the validation of data that the user can enter into the application. The attacker tries to make the application execute unauthorized commands or queries. A WAF would be able to identify the attack and block only the malicious packets, without affecting legitimate users who are using the application at the same time.
Exposure of sensitive data, which occurs when information known to be confidential is being sent by the application to the user. The WAF can detect and block the transmission of information in real time.
Cross site scripting. Two-thirds of all applications have this vulnerability at some point in their code. The application uses a piece of insecure code that an attacker develops. Very common in pishing attacks aimed at stealing access credentials, for example.
Use of vulnerable components. Today, developers use various components developed by third parties in their applications and have no idea what code is running behind them.
A WAF will be able to fix the application code "on the fly". It can embed a CAPTCHA in the application dynamically. In other words, instead of redoing application by application to insert a CAPTCHA into data entry forms, your waf can do it for you with the click of a mouse.
Or the WAF can determine whether the user accessing the application is a robot, and take actions such as blocking access. It also works with threat intelligence. An attack carried out on the other side of the world that goes to a threat intelligence database can be blocked in the company without the WAF ever having seen that attack before, without the need for prior configuration.
False positives
Many people may think that a tool like this will generate a large number of false positives. In fact, the opposite is true: the number of false positives is very small. And there's also the possibility of activating it in learning mode, so that the WAF understands how that business's application works before it starts blocking traffic outside the normal and legitimate operation of the application.
If you need more information, contact us. We want to help protect your business.