As cybersecurity issues increase, Web application filters and Web Application Firewalls are becoming more popular. These tools can be an excellent first step towards securing your applications. How do they work? What is the difference between them? Please read the following lines for an introduction of this topic.

Filters or WAF: Who’s who?

The first kind of defense is called “Filtering”. Whether implemented as part of a development framework or implemented by the developer himself, filtering is in the end part of the application.
Of course the efficiency of this protection will depend on the awareness of the developers on security and also on their experience in developing secure applications.

The second type of defense is called WAF (Web Application Firewall). This type of product is not to be confused with “usual firewalls”, in the sense that web application firewalls analyse the web traffic and don’t stop at filtering traffic based on a particular port number, address or protocol.
Web application firewalls can be implemented on the web server itself, or in front of the web server (between the end-user and the web server).

Website shield

We’ve been hearing a lot of things about HTTPS during the past months, and the Heartbleed “bug” has its responsibility in that phenomenon.
There was a time when HTTPS was dedicated to highly sensitive transactions, like banking transactions.

Now HTTPS is considered mandatory as soon as a user is authenticated on a website, in order to protect his web session and connection credentials.

HTTPS Lock

What is HTTPS?

HTTPS is nothing more than HTTP, the Internet protocol used to exchange data between a server and a client (web browser) on which we add a security layer.
HTTP is not a secured protocol: it has been designed in a pure functional objective without taking any security constraint into consideration.

So we add a security layer to HTTP. To be more accurate, we encapsulate HTTP into a secured connection.

This flaw is ranked #10 on the OWASP Top 10. It is the last one of the top 10, so it is not the most “important” but is doesn’t mean we can ignore it, quite the contrary.
This vulnerability empowers phishing attacks. It helps attackers gaining the trust of their victims.
In some cases, it also helps attackers accessing resources their should not be able to access.

How does this flaw work?

Change direction illustration

Web attack types

Web attacks can be divided into two basic categories

  • Those related to technical flaws (control weaknesses, lack of rigor in the developments, cryptographic weaknesses…)
  • Those related to logical flaws (weaknesses in the business logic of the web application)

There are many types of flaws and different attacks to exploit them. Attacks can also be combined.
The direct consequences of an attack generally fall into the following broad categories:

  • Illegal access to certain data (theft)
  • Loss or modification of data
  • Ilegal access to some functions of the web application
  • Execution of some actions on the website on behalf of other users
  • Malware installation
  • Web Server takeover (and more)

With some more efforts, attackers can perform some pivots and in the end gain control over the company’s internal servers, even if the website is not hosted on the internal network of the company.
The vast majority of these attacks can either be invisible or be quickly spotted, stay active or be stealthy.

The impact for the company

A web application attack can impact both the company and the website users (clients, consumers, employees).

Still in our series of articles about web vulnerabilities, this 6th episode is about Sensitive Data Exposure.
As usual, we won’t dive into the highly technical details here (this would require several pages) and won’t therefore discuss cryptography.
This type of vulnerability is ranked number 6 on the OWASP Top 10 2013. These vulnerabilities are usually quite difficult to exploit by hackers, but the impact being really severe, it is very important to properly understand them and make appropriate choices in the application architecture.

We assume here that your hosting environment is already secure, whether managed by yourself or by a hosting provider.
Let’s focus on the applications. What steps can you take to improve the security of a web application? How to reduce the attack surface and remove easily detectable risks? This article does not pretend to be the manual of the perfect web application defender, but recalls basic principles and presents a list of items to be considered and applied on a regular basis.