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
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
We have a similar problem while migrating the web portal from 7.1.3 to 8.1.1.
We get db journal errors and lockouts:
SQL injection by brute force attack detected in WHERE clause: ...
...
User session of…
Hello,
Is this a general problem with using LIKE operators in where clauses?
Yes.
Please see the following related to this as well: https://support.oneidentity.com/identity-manager/kb/288731/false-positive…
In this particular case, the "Fullpath LIKE" query can be rewritten using the BaseTreeCollection table. Try this:
UID_AErole in (select UID_Org
from basetreecollection
where uid_parentorg in …
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.
Markus Weiss-Ehlers : 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')
florian zedler 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.
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.