SQL Injection Protection Filter

Supported Versions: 9.12 & above

Introduction 

SQL injection, also known as SQLI, is a common attack vector that uses malicious SQL code for back-end database manipulation to access information that was not intended to be displayed. This information may include any number of items, including sensitive company data, user lists or private customer details. The impact SQL injection can have on a business is far reaching. A successful attack may result in the unauthorised viewing of user lists, the deletion of entire tables and, in certain cases, the attacker gaining administrative rights to a database, all of which are highly detrimental to a business.

  API GATEWAY provides two types of filters that you can enable to prevent SQL injection attacks:

  1. Database-Specific SQL Injection Protection
     
  2. Standard SQL Injection Protection

Workflow

  1. External clients send requests to webMethods API Gateway Server
  2. webMethods API Gateway Server collects client information from each request and evaluates the request against any rules (combination of filters in this case "SQL Injection filter") that have been defined. webMethods API Gateway Server forwards the request to the service
  3. Service processes the request, webMethods API Gateway Server either denies the request or allows the request.
  4. webMethods API Gateway Server then passes requests to the Internal Server.
  5. The Internal Server processes the requests and sends responses to webMethods API Gateway Server.
  6. webMethods API Gateway Server then passes the responses back to the client.

Database-Specific SQL Injection Protection

  • If enabled, webMethods API Gateway Server will check the incoming payload based on the specified database and GET or POST request parameters.
  • If no parameter is specified, all input parameters are checked for possible SQL injection attack. webMethods API Gateway Server adheres to the ESAPI (OWASP Enterprise Security API) standards while validating the parameters.
  • Parameters are applicable only for HTTP queries and HTTP form data, in which there are name value pairs.

 For example, in the HTTP query string, http://localhost:1111/invoke/myjdbc.db:addUser?name=' or '1'='1' the parameter is name.

Runtime

The Query param userid contains an invalid special character ' eventually DB-Specific-SQL-Injection-filter blocks the request.

Standard SQL Injection Protection 

  • If enabled, webMethods API Gateway Server blocks XML and SOAP payload messages that contain quotation mark ('), number sign (#), or double hyphen (--) in the message.

  For example, in the following XML payload, the Text elements (Name, Designation, and Country) contain invalid characters  ', #, and -- respectively.

<Employee><ID>1245</ID>
<NAME>Albu'm name</NAME>
<DESIGNATION>SS#E</DESIGNATION>
<COUNTRY>USA--</COUNTRY>
<DOJ>2014</DOJ>
</Employee>

Runtime

The below XML payload consists of invalid characters like –- in <DOJ> attribute so that SQL Injection filter  gets violated and  denies the request .

image.png

There is now a possibility to add custom filters.
What is the syntax and how to recover examples for it?

@Mihai_Ungureanu5 The Custom filters to invoke a service that is available on API Gateway to support custom authentication, logging/ auditing in the DMZ. Is that are you looking for ?

No, I mean for the “Standard SQL Injection Protection”

So, what exactly are the expressions to be put in the textbox there?

Hi @Mihai_Ungureanu5 It will enable to safe gaurd your system/API from SQL injection attacks.

  1. Rules will be validated only for the external ports [ API Gateway on DMZ ] .
  2. if the Parameters is empty API gateway will validate all the request fields against the SQL Attack Based on the Data Base specific or in General.
  3. if you wanted to validate only for the specific fields in HTTP Query or form data . You have to mention in the parameters box.

Example: In this example , I would like to validate my request against fields called as [ addUser ] , So I would need to specify the same in parameter . if nothings specified gateway will validate against all the parameters.

Parameters are applicable only for HTTP queries and HTTP form data, in which there are name value pairs.

For example, in the HTTP query string,
http://localhost:1111/invoke/myjdbc.db:addUser?userid=’ or ‘1’=‘1’ --, the parameter is userid.

I hope this clarifies your concern