Platform.sh WAF

Enterprise and Elite projects on Platform.sh come with a web application firewall (WAF) at no additional cost. This WAF monitors requests to your app and blocks suspicious ones.

All traffic to Platform.sh endpoints is also filtered using a system that takes into account traffic patterns and abuse scores.

CRLF injection prevention

Carriage return and line feed (CRLF) injection occurs when an attacker injects a CRLF character sequence to manipulate HTTP requests. CRLF injection can lead to request smuggling, header injection, and response splitting attacks.

To protect your app from such attacks, the WAF detects and blocks requests containing CRLF character sequences.

Request smuggling

When a frontend server forwards HTTP requests to a backend server, it usually sends a series of requests at once. The backend server then parses the request headers to determine where one request ends and the next one begins.

The HTTP protocol provides two different headers to specify where an HTTP request ends: Content-Length and Transfer-Encoding.

When the frontend and backend servers don’t agree on which header they should interpret as the end of a request, attackers can smuggle requests. If a malicious request is injected, the backend server may misinterpret the boundaries of the individual requests within the concatenated request, thereby processing a request differently from what was intended. This can lead to various security risks such as data leakage, privilege escalation, and even remote code execution.

The WAF detects and blocks requests that contain both the Content-Length and Transfer-Encoding headers. It also detects and blocks requests that include both of the following features of an attempt to inject a malicious request:

• A CRLF character or http/\d
• An HTTP or WEBDAV method name

Header injection

During a header injection attack, the attacker tricks your app into inserting extra HTTP headers into legitimate HTTP responses. These attacks can happen when HTTP response headers are generated based on user input.

Header injection attacks can have various impacts, including cookie injection, cross-origin resource sharing header injection, and bypassing your content security policy. Such attacks enable response splitting, which in turn can lead to cross-site scripting, web cache poisoning, and so on.

The WAF detects header injection attempts occurring through the payload and the header itself. By blocking requests containing CRLF character sequences, the WAF prevents malicious data from being returned in a response header and interpreted by the client.

Response splitting

When a user makes an HTTP request, the web server usually returns a single HTTP response. But when an attacker succeeds in injecting headers, they can launch a response splitting attack.

During a response splitting attack, the attacker uses CRLF characters to inject additional HTTP responses into legitimate user requests. This enables further attacks such as cross-site scripting, web cache poisoning, browser cache poisoning, and cross-user attacks.

As the WAF blocks requests containing CRLF character sequences, your app is protected from response splitting attacks.

HTTP protocol enforcement

In addition to protecting your site against CRLF injection-related attacks, the WAF implements additional rules to enforce the HTTP protocol.

Uniform Resource Identifier (URI) syntax

RFC 3986 defines the generic syntax for URIs. When the WAF detects a URI with incorrect syntax, the incoming connection is terminated. The request is then reconstructed on the internal Platform.sh network, enforcing the valid format in transit.

File upload limit

The WAF enforces a file upload limit. By default, this limit is set at 250 MB.

You can customize the file upload limit by amending your app configuration. In the web.locations dictionary, add your desired value for the max_request_size property.

File extension restriction

The WAF enforces any file extension restriction you may have defined in your app configuration.

To set up a file extension restriction, adjust the web.locations dictionary. Set up rules to allow only certain file extensions on a given path.

Disallowed requests and headers

GET requests with a body

The HTTP specification allows for GET requests to have a body. This enables attackers to try and force a request body on unsuspecting applications, which could result in a request smuggling attack.

To prevent such attacks, when the WAF detects a GET request, it scans the request for a potential Content-Length or Transfer-Encoding header.

If one of those headers is found and the payload isn’t 0 or empty, all body-related headers are removed from the request. The request is then passed through otherwise unaltered.

Content-Length and Transfer-Encoding headers together

According to the HTTP specification, requests mustn’t contain both a Content-Length and a Transfer-Encoding header. This rule helps protect apps from request smuggling.

The WAF detects and blocks requests featuring both headers and forces requests to use chunked transfer encoding only on the internal Platform.sh network.

Missing or empty host headers

As routes are mapped based on host names, the Platform.sh WAF blocks requests with an empty or absent host header.

Other restricted HTTP headers

The following headers are disallowed: Connection, Proxy-Authorization, TE, and Upgrade.

Slowloris DDoS attack prevention

Slowloris DDoS attacks use partial HTTP requests to open connections between a single computer and a targeted web server. These connections are then kept open for as long as possible to overwhelm the web server.

While Apache web servers are vulnerable to Slowloris attacks, Nginx servers aren’t. Since Platform.sh router services use Nginx processes, your projects are protected against such attacks.