Traditional firewalls protect IT environments against external attacks, by allowing and blocking connections to certain areas.

These firewalls control incoming and outgoing network traffic, based on a set of rules.

Here is a basic example:
Let’s suppose your company has a web server inside its infrastructure. In order for the web server to be reachable from outside your company, some rules will have to be established to authorize web traffic to and from that server.
Some “ports” will be open, on a given IP address (the one of your server).
Your company can choose to allow web traffic only, or allow other traffic according to its needs.

Sometimes security can represent a heavy investment in terms of web development.
But there are some tiny adjustments that you can implement on your website that will help you making substantial progress in security. In fact these adjustments are really small in terms of code and configuration, but have a significant impact that requires proper analysis and validation before being implemented.
Here is how HTTP headers can help you in your security efforts.

Better than just rewriting technical specifications and explaining all the details of these HTTP headers, we will focus on giving you a synthetic analysis and a list of interesting links you would like to browse if you need further details.
One important thing to keep in mind is that these headers have an impact on the browser side. They control how web browsers must behave (if they implement the corresponding functionalities). They do not modify the server’s behavior.

Some years ago this was a common question: should I conduct a pentest on my website? Today the real question is: how often should I conduct a pentest? This does not only apply to websites but more generally to all applications and software developed with web technologies. Although systems and servers also need security, in this article we will only focus on the application layer, which usually faces a lack of awareness regarding to its breaches.

Web Application Firewalls (commonly referred to as WAF) are mainly designed to protect web applications.
But what exact roles can they play in a web architecture?
Depending on how they are integrated in your web platform, their impact and ability to improve your security will differ.

Using a WAF as an attack mitigation solution

A WAF can be used to analyse inbound and outbound traffic in order to block malicious or dangerous items.

In this configuration, the threat detection engine of the firewall detects suspicious inbound traffic and decides to block the request. This means that the request will not reach the web server, and a generic response will be returned to the client.
To decide whether a request is innocuous or malicious, the WAF can use a positive or a negative security model:
The negative security model assumes that all transactions are innocuous, by default. It will look for threat cues and if judged dangerous, block the transaction.
The positive security model, on the other hand, assumes that all transactions can be dangerous and only allows those that are recognized as safe.

Web application firewall

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.