SQL Threat Protection

The role of this interceptor is to block SQL Injection attacks in the calls to an API accessing a database.

SQL Injection is an attack in which undue and malicious SQL statements are inserted into a query from the client to the server. It enables from database management operations (such as changing administrator and access settings) to illicit content manipulation (such as altering or deleting data and, of course, exposing sensitive information).

How it works

The interceptor works based on a regular expression (regex) that validates the contents of body, headers, cookies, query params and path params passed in the request. If the regex finds snippets that might indicate an SQL injection, the call is aborted and an error is returned (see possible errors below).

We have made the regex more restrictive as of the Release 4.4.0.0 in order to strengthen the security. If you were using SQL Threat Protection in your APIs before, you may experience traffic issues with some data that didn’t use to be barred.

For example, if the request includes a string containing a keyword and a complement, the interceptor now identifies a threat and aborts the call. In this case, you can change the way the data travels by breaking up the string into different key-value pairs.

Pay attention when sending images in form-data. In these cases, the body is received as an array of bytes and, when they are decoded, some characters might be understood as SQL injection and the call is aborted. To avoid this, you can send the image converted to Base64, as in this example of a body:

{
  "image": {
    "name": "image.jpeg",
    "content-type": "//content base64 encoded",
    "file": "base64string"
  }
}

Configuration

Although the SQL Threat Protection interceptor may be inserted in the response flow of an API as well, it is essential that you place it in the request flow, since the attacks mentioned occur in the direction client ⇒ backend.

sql threat flow

To configure the interceptor, you must choose at least one of the options of blocks to be protected.

When inserted in the request flow, these are the options:

  • Body: applies protection to the body of the request.

    • Ignore body when the key is 'Content/type' and the value is 'multipart/form-data': ignores the body if the Content/type has the value multipart/form-data, thus being able to ignore possible expressions reserved by the SQL that are contained in files sent in this manner.

  • Headers: applies protection to all headers, checking each one separately.

  • Query Params: checks all parameters to search for attacks.

  • Cookies: applies protection to all cookies, checking each one separately.

  • Path Params: checks all parameters for attacks.

When inserted in the response flow, there are two other options to select:

  • Body: applies protection to the body of the response.

    • Ignore body when the key is 'Content/type' and the value is 'multipart/form-data': ignores the body if the Content/type has the value multipart/form-data, thus being able to ignore possible expressions reserved by the SQL that are contained in files sent in this manner.

  • Headers: applies protection to all headers, checking each one separately.

If all options are selected, validations will occur in the following sequence:

  • Request: Query Params → Body → Cookies → Headers → Path Params

  • Response: Body → Headers

sql threat

The request and response flows allow expressions to be ignored by the interceptor, this prevents the call from being interrupted when there are reserved words or characters, but within a safe context. To add an expression, type it in the String field and click ADD, it will be ignored in all blocks chosen above, keep in mind that it is case-sensitive

Every expression added increases the processing time and consequently the latency of the request, especially if you are validating more than one block

We suggest being careful with the added expressions, especially if it’s something very broad, as it can stop validating a SQL reserved word.

Errors

If a SQL Injection attack is identified, the following errors will be returned:

Fields Error HTTP Code Request HTTP Code Response

Body

SQL Injection attack identified in this API Body

400

500

Headers

SQL Injection attack identified in this API Headers

400

500

Query Params

SQL Injection attack identified in this API Query Params

400

-

Cookies

SQL Injection attack identified in this API Cookies

400

-

Path Params

SQL Injection attack identified in this API Path Params

400

-

Thanks for your feedback!
EDIT

Share your suggestions with us!
Click here and then [+ Submit idea]