CQL injection in asyncValidateField.js

Description

Overview:

Masking/escaping " \ ^ * ? is missing in asyncValidateField.js when doing

const query = `(${fieldName}=="${value}")`;

A: Steps to Reproduce:

  1. Open https://folio-snapshot.dev.folio.org/users/create?sort=name

  2. Enter one of these characters into Barcode field: " \

A: Expected Results:

Runs one of these CQL queries:

barcode=="\"" barcode=="\\"

A: Actual Results:

Runs one of these CQL queries:

barcode==""" barcode=="\"

This causes an error popup with

ERROR: in module @folio/users, operation GET on resource 'uniquenessValidator' failed, saying: org.folio.cql2pgjson.exception.QueryValidationException: org.z3950.zing.cql.CQLParseException: expected index or term, got EOF

 

B: Steps to Reproduce:

  1. Open https://folio-snapshot.dev.folio.org/users/create?sort=name

  2. Enter 78 and one of these characters into Barcode field: * ?

B: Expected Results:

Runs one of these CQL queries:

barcode=="78\*" barcode=="78\?"

and doesn't match the existing barcode 789.

B: Actual Results:

Runs one of these CQL queries:

barcode=="78*" barcode=="78?"

and matches the existing barcode 789 and blocks saving with "This barcode has already been taken".
 
Additional Information:
https://folio-org.atlassian.net/browse/STUTL-33#icft=STUTL-33 "maskCqlValue for " \ ^ * ?" = https://github.com/folio-org/stripes-util/pull/69

CSP Request Details

None

CSP Rejection Details

None

Potential Workaround

None

Checklist

hide

TestRail: Results

Activity

Show:

Zak Burke September 27, 2023 at 7:50 PM
Edited

PSA: Stripes runs in the browser. CQL is executed on the server. There can NEVER be a CQL injection vulnerability in Stripes because Stripes does not execute CQL code. Repeat after me: There can NEVER be a CQL injection vulnerability in Stripes because Stripes does not execute CQL code.

Stripes may send invalid queries to the server, and this looks like an instance of that, and we should clean it up, but that's just a bug and that's all there is to it. There is NO security implication here. If the module that receives this API request and parses this query barfs up a stacktrace rather than detecting the malformed query and throwing a polite exception**, that's a vulnerability in the receiving module. But please note that even if we fix the malformed query here, any other client in the world whether it's curl or Postman or Insomnia or some crazy scriptkiddie typing raw characters straight into HTTP request in telnet, is still free to send the same malformed query to the same module and the onus will still be on that module to deal with it.

** For the record, it looks like the receiving module does exactly the right thing and throws an exception. In summary, there is no security vulnerability here. There is no security vulnerability there. There is no security vulnerability anywhere.

Details

Assignee

Reporter

Priority

Development Team

Volaris

Release

Not Scheduled

RCA Group

Implementation coding issue

Affected releases

Poppy (R2 2023)
Orchid (R1 2023)

TestRail: Cases

Open TestRail: Cases

TestRail: Runs

Open TestRail: Runs
Created May 27, 2023 at 10:10 AM
Updated 4 days ago
TestRail: Cases
TestRail: Runs

Flag notifications