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.

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: the interceptor applies protection to the body of the request;
Headers: it applies protection to all headers, checking each one separately;
Query Params: it checks parameter by parameter to search for attacks.
Cookies: it applies protection to all cookies, checking each one separately;
Path Params: it checks parameter by parameter for attacks.

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

Body: the interceptor applies protection to the body of the response;
Headers: it 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, Headers, Cookies, Path Params.
Response: Body, Headers.

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]