Uploaded image for project: 'OpenIDM'
  1. OpenIDM
  2. OPENIDM-12283

correlateTreeToQueryFilter.js may be vulnerable to injection


    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s:
    • Fix Version/s: 7.0.0
    • Component/s: UI
    • Labels:
    • Environment:
    • Target Version/s:
    • Verified Version/s:
    • Sprint:
      OpenIDM Sprint 7.0-4
    • Support Ticket IDs:


      Script in question:

      Customer Summary:
      When correlation queries are set up using the tree expressions (as in the UI), the above script is used to construct a query filter expression. When it does this, it includes (possibly transformed) values from fields in the source object. It carries out some sanitization of these, but I think this is not sufficient.

      At present, in, on line 92 of the script, and backslashes () and single-quotes(') are escaped, but notably double-quotes are not. On line 105, the partially-escaped value is included in an expression surrounded by double-quotes. It is therefore possible for a value to escape its quoting, for example, a correlation query which would normally output something like:

      /emailAddress eq "bjensen@example.com"

      could be made to output:

      /emailAddress eq "" OR /employeeNumber eq "12345"

      if a user had control of that field, by setting it to:

      " OR /employeeNumber eq "12345

      This gives them arbitrary control over the query filter.

      Additionally, this would mean that any values containing a double-quote character would break the query filter.

      This could potentially be addressed simply by escaping all double-quotes on line 92.


      Customer Example:
      ForgeRock supplied script which constructs query filter expressions based on a correlation tree expression set up in the UI. For example:

      "expressionTree" :

      { "any" : [ "userName" ] }


      The correlation query returned should be something like `/userName eq "bjensen"` - note the username is interpolated into the expression. The username is formed by the script by transforming (if necessary (4)) the source attribute value according to the transformation script in the mapping.

      As the expression returned is not parameterized, certain characters must be escaped. For example, at present the script escapes backslash and apostrophe, so a username of o'reilly would be interpolated as `/userName eq "o\'reilly"`, but double quotes aren't escaped. Note that a correlation query may be performed on any field including a user specified one, so if a user were able to enter double-quotes, the script could return `/userName eq "" OR /employeeNumber eq "1"` if the username is set to `" OR /employeeNumber eq "1` (this is in essence exactly the same mechanism used to inject into SQL.

      If double quotes were properly escaped, the above example injection would be interpolated safely as `/userName eq "\" OR /employeeNumber eq \"1"` - note that the quotes in the interpolated fields are then correctly escaped. In fact, it may be safest to let JSON.stringify perform all necessary escapes rather than the script doing multiple `replace()`s itself.

      Additionally, there are examples in the integrator's guide which are likely vulnerable in exactly the same manner, as they don't perform any sanitization at all, see ` Writing Correlation Queries` in the the 6.0 integrator's guide (note specifically it warns against SQL injection in a _queryExpression but doesn't give any note as to the risks of unsanitized user input being used to inject against a _queryFilter).


          Issue Links



              • Assignee:
                cgdrake Chris Drake
                jeremy.barras Jeremy Barras [X] (Inactive)
              • Votes:
                1 Vote for this issue
                4 Start watching this issue


                • Created: