Defeating cipher padding attacks on individually encrypted inputs

Like its predecessor the BEAST attack (see Prioritize RC4 Cipher Suite), the Lucky 13 attack exploited flaws in SSL/TLS implementations of CBC encryption. Classified as a “padding oracle” attack, Lucky 13 analyzes errors returned by the server (its “oracle”) after submitting incorrect “padding” — empty bytes that are added to plain text to make its length uniform before encryption is applied. (Padding is required by all block ciphers.) Once the attacker guesses the correct padding, the resulting encrypted messages have a similar pattern. Attackers can analyze many packets to find the pattern, and thereby decrypt the data for a MITM attack.

This attack involves some brute force: the attacker must guess repeatedly until the server does not return an error, indicating that the correct padding has been discovered. As such, padding attacks may not have been feasible 10 years ago. However as broadband connections and powerful computers become pervasive, this kind of attack has become practical.

Not all web applications use HTTPS, however. Cryptography generally decreases performance. To improve performance while attempting to protect sensitive data, some web applications selectively encrypt above the application level. They encrypt only specific inputs and outputs, such as:

But if the custom functions to encrypt these inputs use the same principle as CBC, or are not well tested or promptly updated for security, they too are vulnerable to padding attacks.

For example, if only a user ID is encrypted, an attacker may want to decrypt it so that he or she can follow with a session hijacking attack. The attacker’s initial request might look like this:

GET /profile.jsp?UID=0000000000000001F851D6CC68FC9537...

The UID is a guess. Unless he or she is extremely lucky, the attacker did not use the correct key nor padding (e.g. 0x01). Therefore the application would reply with an error response such as:

500 Internal Server Error

But if the attacker increases or decreases the padding byte (e.g. 0x02), sends the request again, and repeats this process, the attacker would eventually guess the correct padding, resulting in a message from the server that indicates a correct padding byte:

200 OK

Repeating the above process with previous padding bytes would eventually yield the full, correct padding, and therefore also the length of the plain text. With that, the attacker would eventually be able to decrypt the entire UID. The attacker could then attempt to hijack the login.

To protect against padding oracle attacks

1.  Consult with your application developer to find inputs that are individually encrypted.

Do not configure padding oracle attack prevention unless the URL, cookie or parameter is encrypted. Only encrypted inputs or URLs, especially those encrypted using CBC, ECB, or OAEP, are vulnerable. Unnecessary protection will decrease FortiWeb performance.

2.  Go to Web Protection > Advanced Protection > Padding Oracle Protection.

3.  Click Create New, then configure these settings:

Setting name Description
Name Type a unique name that can be referenced in other parts of the configuration. Do not use spaces or special characters. The maximum length is 35 characters.

Select which action the FortiWeb appliance will take when it detects a violation of the rule:

  • AlertAccept the request and generate an alert email and/or log message.
  • Alert & DenyBlock the request (reset the connection) and generate an alert and/or log message.

    You can customize the web page that FortiWeb returns to the client with the HTTP status code. See Customizing error and authentication pages (replacement messages).

  • Period Block Block subsequent requests from the client for a number of seconds. Also configure Block Period.

    You can customize the web page that FortiWeb returns to the client with the HTTP status code. See Customizing error and authentication pages (replacement messages).

    Note: If FortiWeb is deployed behind a NAT load balancer, when using this option, you must also define an X-header that indicates the original client’s IP (see Defining your proxies, clients, & X-headers). Failure to do so may cause FortiWeb to block all connections when it detects a violation of this type.

The default value is Alert.

Attack log messages contain Padding Oracle Attack when this feature detects a possible attack. Because this attack involves some repeated brute force, the attack log may not appear immediately, but should occur within 2 minutes, depending on your configured DoS alert interval.

Caution: This setting will be ignored if Monitor Mode is enabled.

Note: Logging and/or alert email will occur only if enabled and configured. See Logging and Alert email.

Note: If you will use this rule set with auto-learning, you should select Alert. If Action is Alert & Deny, or any other option that causes the FortiWeb appliance to terminate or modify the request or reply when it detects an attack attempt, the interruption will cause incomplete session information for auto-learning.

Block Period

Type the number of seconds that you want to block subsequent requests from the client after the FortiWeb appliance detects that the client has violated the rule.

This setting is available only if Action is set to Period Block. The valid range is from 1 to 3,600 (1 hour). The default value is 1. See also Monitoring currently blocked IPs.


When rule violations are recorded in the attack log, each log message contains a Severity Level (severity_level) field. Select which severity level the FortiWeb appliance will use when it logs a violation of the rule:

  • Low
  • Medium
  • High

The default value is Medium.

Trigger Action Select which trigger, if any, that the FortiWeb appliance will use when it logs and/or sends an alert email about a violation of the rule. See Monitoring currently blocked IPs.

4.  Click OK, then click Create New, then configure these settings:

Setting name Description
Host Status

Enable to apply this rule only to HTTP requests for specific web hosts. Also configure Host.

Disable to match the rule based upon the other criteria, such as the URL, but regardless of the Host: field.


Select which protected host names entry (either a web host name or IP address) that the Host: field of the HTTP request must be in to match the rule.

This option is available only if Host Status is enabled.

Type Select whether the Protected URL field must contain a literal URL (Simple String), or a regular expression designed to match multiple URLs (Regular Expression).
Protected URL

Depending on your selection in Type, type either:

  • the literal URL, such as /profile.jsp, that the HTTP request must contain in order to match the rule. The URL must begin with a backslash ( / ).
  • a regular expression, such as ^/*\.jsp\?uid\=(.*), matching all and only the URLs to which the rule should apply. The pattern does not require a slash ( / ).; however, it must at least match URLs that begin with a slash, such as /profile.cfm.

Do not include the domain name, such as, which is configured separately in the Host drop-down list.

To create and test a regular expression, click the >> (test) icon. This opens the Regular Expression Validator window where you can fine-tune the expression (see Regular expression syntax and Cookbook regular expressions).

Protected Target

Indicate which parts of the client’s requests should be examined for padding attack attempts:

  • URL (e.g. parameters are embedded in the URL, such as /user/0000012FE03BC2)
  • Parameter (e.g. parameters are appended in a traditional GET URL parameter, such as /index.php?user=0000012FE03BC2or POST body)
  • Cookie

5.  Click OK.

6.  Repeat the previous 2 steps for each encrypted input in the web application.

7.  Click OK.

8.  To apply the rule, select it in an inline protection profile or an offline protection profile (see Configuring a protection profile for inline topologies or Configuring a protection profile for an out-of-band topology or asynchronous mode of operation).

Malicious clients often send many HTTP requests while attempting to analyze the padding. This could flood your attack logs with repetitive messages. To adjust the interval at which FortiWeb will record identical log messages during an ongoing attack, see max-dos-alert-interval <seconds_int> in the FortiWeb CLI Reference. See also Log rate limits.