escapeCqlValue for " \ ^ * ?

@Tetiana Gusar , I don’t understand how this blocks https://folio-org.atlassian.net/browse/UIU-2882. Looking at the code, asyncValidateField() directly issues an API query without escaping value except to trim off its whitespace. stripes-util isn't involved. If you want to do some escaping, uh, do some escaping.

I created a story and PR to provide escaleCqlWildcards which provides this functionality (https://folio-org.atlassian.net/browse/STUTL-45). Please note that if you use this function in UIU, you must update its peer-dependency on @folio/stripes to ^9.2.0. Updating the minimum version of a peer-dependency is a breaking change.

Also please note that the “security” labels on https://folio-org.atlassian.net/browse/UIU-2882 are junk/incorrect. There is NO security implication to that work but the labels have been left in place for historical reasons since the Security Team has, in fact, reviewed that story. It is true that the front-end may send an invalid CQL query if certain characters are not escaped, but an invalid query is just that: an invalid query. An injection vulnerability can only occur when a query is parsed and executed; the UI does neither.

@Zak Burke sorry for confusion, I didn’t notice that UIPFO-45 was just closed as duplicate without any changes, so STUTL-33 is remaining open (and it is blocking https://folio-org.atlassian.net/browse/UIU-2882, so Volaris will need to wait until it is done)

Sorry, @Tetiana Gusar, it isn’t clear precisely what you are asking about. I see that https://folio-org.atlassian.net/browse/UIPFO-45 is closed although there is no related PR attached , and this ticket remains open. Please clarify which ticket you think is done and which is unblocked, and why.

Hello @Julian Ladisch , @Zak Burke I can see that this issue is duplicated by https://folio-org.atlassian.net/browse/UIPFO-45 Can we consider this as done and hence this one unblocked? https://folio-org.atlassian.net/browse/UIU-2882

That is correct, @Khalilah Gambrell, the initial implementation was reverted because there are many places that places that deliberately insert an asterisk as a wildcard into a query string and therefore do not want it to be escaped. As noted in the revert PR, in order to move ahead with this we need to do some other things first:

1. implement a new function that preserves the asterisk

2. convert existing search code to use that function

3. change the behavior of this function

@Amelia Sutton, FTR, UIU-2882 is NOT a security vulnerability; see comments on that ticket for details. And UIU-2731 could probably be resolved by implementing #1 above (write a new function, and call that one instead of this one) but I haven't looked in detail at what's going on there. It's possible that ui-users isn't directly in control of the function it uses for escaping (e.g. if it handles tags via an import from stripes-smart-components) but, fine, then we need to update the function in STSMACOM instead if we know we don't want to use an asterisk as a wildcard WRT when looking up tags.