SQL Threat Protection
The role of this interceptor is to block SQL Injection attacks in the calls to an API accessing a database.
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:
|
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: 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 valuemultipart/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 valuemultipart/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:
|
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 |
- |
Share your suggestions with us!
Click here and then [+ Submit idea]