Potential SQL injection attack by brute-force querying the rest api

Hi ,

(reedited after more testing)

In v8.1 we're querying the rest api server as shown:

POST /AppServer/api/entities/Person?limit=15&displaycolumns=CCC_NIF;CentralAccount

Content-Type: application/json

{ "where": "CentralAccount like '%usuario%'"}
but the AppServer is considering this a potential sql injection attack and adds a time penalty to every sucesive query, thus making the access nearly impossible:
"2019-12-16 09:49:49.8124 WARN (ObjectLog c3b242f1-8b87-4e2b-ac2b-8671daa05e48) : Potential SQL injection attack, adding time penalty of 00:00:02.0940000, WHERE clause: CentralAccount like '%usuario%'"
At first I thought it was related to a complex where query, but this one couldnt be simpler. If I remove the "like" operator then it works just fine. I dont know if this is a response sent from the sqlserver or the Appserver. Could I turn off this checking?
Thanks!
Parents
  • We have a quite similar situation when using the '>' operator in the where clause in version 9.1, it triggers a 501 Internal error response with message 

    "message": "Potentially dangerous behavior was detected. The request will be ignored."

  • Please check the following from the release notes of 9.1

    • Due to security issues, you cannot run any database queries directly from the user interface or from web applications. Specific SQL operators undergo a risk assessment that prevents them from being used by One Identity Manager components. This includes operators such as LIKE, NOT LIKE, <, <=, >, or >=.

      In order to continue using certain features in One Identity Manager components, users require the Common_AllowRiskyWhereClauses program function.

      Users who do not have this program function can only run database queries that are classified as trusted or pose no risk. Some of the features in One Identity Manager components, such as testing dynamic roles or running filter queries, are not possible without this function. For more information, see the One Identity Manager Authorization and Authentication Guide.

    and the part Preventing blind SQL injection of the One Identity Manager Authorization and Authentication Guide.


    https://support.oneidentity.com/technical-documents/identity-manager/9.1/authorization-and-authentication-guide/33#TOPIC-1872898

Reply
  • Please check the following from the release notes of 9.1

    • Due to security issues, you cannot run any database queries directly from the user interface or from web applications. Specific SQL operators undergo a risk assessment that prevents them from being used by One Identity Manager components. This includes operators such as LIKE, NOT LIKE, <, <=, >, or >=.

      In order to continue using certain features in One Identity Manager components, users require the Common_AllowRiskyWhereClauses program function.

      Users who do not have this program function can only run database queries that are classified as trusted or pose no risk. Some of the features in One Identity Manager components, such as testing dynamic roles or running filter queries, are not possible without this function. For more information, see the One Identity Manager Authorization and Authentication Guide.

    and the part Preventing blind SQL injection of the One Identity Manager Authorization and Authentication Guide.


    https://support.oneidentity.com/technical-documents/identity-manager/9.1/authorization-and-authentication-guide/33#TOPIC-1872898

Children
  •  : Is this also required for opening the WebPortal after a new installation?
    I'm getting the following error message after login in with a user that has only these roles: Birthright Assignments /  Everyone (Change) / Everyone (Lookup)

    2023-08-08 15:31:09.1457 ERROR ( ObjectLog ) : SQL injection detcted in WHERE clause: (orderstate = N'Assigned') and (UID_PersonInserted = 'e080ba54-58f7-4809-b9e3-6d39314cf6b4') and (isnull(ValidUntil, '1899-12-30 00:00:00.000') < '2023-08-22 13:31:09.144') and (isnull(ValidUntil, '1899-12-30 00:00:00.000') > '1899-12-30 00:00:00.000') 
    2023-08-08 15:31:09.2067 ERROR (    WebLog ) : An error occurred while processing the request: GET https://xxx.xxx.xxx/ApiServer/portal/person/config System.Exception: An error occurred while processing the request: GET https://xxx.xxx.xxx/ApiServer/portal/person/config ---> VI.Base.ViException: Potentially dangerous behavior was detected. The request will be ignored. ---> VI.Base.ViException: SQL injection detected in WHERE clause: (orderstate = N'Assigned') and (UID_PersonInserted = 'e080ba54-58f7-4809-b9e3-6d39314cf6b4') and (isnull(ValidUntil, '1899-12-30 00:00:00.000') < '2023-08-22 13:31:09.144') and (isnull(ValidUntil, '1899-12-30 00:00:00.000') > '1899-12-30 00:00:00.000')

  •   Which version are we talking about? The web portal will be installed with a trusted source key in their configuration.

  • We are having similar issue after upgrading from 8.1 to 9.1, the login fail with SQL injection error message in Web Portal but works in Angular Web Portal

  • Current Version 9.1.1. Then it seems like the trusted source key is not set correctly. I think you are talking about the API Key used when setting up the APIServer? Where do these keys need to be defined to work correctly. Somewhere in the database and somewhere in the web.config of the APIServer?

    For a note: We changed the BaseURL to a DNS alias by changing it in QBMWebApplication after the installation.

    I you have a hint for me how to define the correct URL during the installation of a IAM WebApplication that would be awesome, but I guess the installer pulls the hostname?

  • Just for clarity, you changed the BaseURL in the QBMWebApplication AND in the web.config? 

  • Just checked and corrected that yesterday but didn't had the time to post an update here.
    You are right. It wasn't changed in web.config for some reason. And then I found out the customer reinstalled the solution and just changed it in the database...

    So, for everyone: Make sure BaseURL matches both in database QBMWebApplication and in the web.config of the solution.

    And for One Identity: It would be nice if we could get the possibility to define the correct BaseURL inside the Installer. And when you are on it, as I had it quite often this year: Properly support GMSAccounts as application pool identity in the installer, that is also something you have to change after the solution is installed on the IIS.