To improve our overall security posture and operational efficiency, we have planned an update to our topology to eliminate certain risk vectors while conforming to common HTTP syntax standards. As part of that effort, Okta will stop processing requests with malformed syntax in query strings starting on July 17, 2024, for Preview Orgs and September 24, 2024, for Production Orgs.
We discovered that some requests to Okta, including those from SailPoint and/or LogRhythm connectors, are being sent with malformed syntax in query strings. Specifically, delimiters such as ?, used to signify the start of a query string, are being encoded when they should be sent as literal characters. Currently, these requests are reinterpreted to minimize impact to customers. However, to eliminate certain risk vectors and conform to standards as listed in RFCs, Okta will no longer accept malformed syntax in query strings, and such non-compliant requests will fail.
It is important to call out that this is NOT a change to any Okta endpoint or underlying functionality. Okta is closing security risk vectors while conforming to common standards.
What is malformed syntax in query strings? Query strings are part of a URL that begins with the delimiter “?” and contains key-value pairs, or parameters, separated by "&" symbols. Query strings provide additional information to web servers when making requests. For example, in the URL "https://www.acme.com/api/users/?org=accounting&name=john%20doe", the query string is "org=accounting&name=john doe". This tells the server that we are interested in only John Doe, who is part of the Accounting organization.
A rare issue that has been observed is the incorrect encoding of the “?” delimiter, which as mentioned above, signifies the start of a query string. Delimiters such as “?”, “&” and “=” should not be encoded and doing so may result in the request getting incorrectly processed. In certain cases, however, encoding is necessary when special or reserved characters are part of query parameter values, as demonstrated in the example above where the space between “john” and “doe” was encoded.
Example:
This concept can be further demonstrated in the following example.
- Correctly encoded: https://www.acme.com/api/product/?category=furniture&color=blue%2Fred"
- Malformed: https://www.acme.com/api/product/%3Fcategory=furniture&color=blue%2Fred"
The ? delimiter for query strings is a literal character in the first URL, but is incorrectly encoded in the second URL. This is done so the web server knows where the path ends and where the query string begins. Notice, however, the special characters (“/”) to “%2F” are still encoded in the query parameter value since it can be misinterpreted by web servers if it is not encoded.
- API requests
- Query strings
- Okta Identity Engine (OIE)
- Okta Classic Engine
After July 17, 2024 for Preview Orgs and September 24, 2024 for Production Orgs, Okta will stop supporting malformed syntax in query strings. Customers and ISVs may receive 400 error codes as the API response, which signifies a bad request was made. As explained above, this may be because a delimiter, such as ?, was encoded when it should have been sent as a literal character.
- Remember to pass any and all delimiters in the query string as literal characters so the request is correctly interpreted and processed.
- Special characters in any query parameter value should still be encoded, as demonstrated in the example above.
- For more information, please refer to Section 2 and beyond of RFC 3986.
- While Okta has notified both vendors of the change, Okta customers should exercise due diligence and validate with SailPoint and LogRhythm account teams that they are rectifying any malformed syntax in their query strings.
