Open Redirect Affecting @strapi/plugin-users-permissions package, versions <4.24.2
Threat Intelligence
Snyk has a proof-of-concept or detailed explanation of how to exploit this vulnerability.
The probability is the direct output of the EPSS model, and conveys an overall sense of the threat of exploitation in the wild. The percentile measures the EPSS probability relative to all known EPSS scores. Note: This data is updated daily, relying on the latest available EPSS model version. Check out the EPSS documentation for more details.
Do your applications use this vulnerable package?
In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.
Test your applications- Snyk IDSNYK-JS-STRAPIPLUGINUSERSPERMISSIONS-7251015
- published13 Jun 2024
- disclosed12 Jun 2024
- creditSimen Daehlin
Introduced: 12 Jun 2024
CVE-2024-34065 (opens in a new tab)How to fix?
Upgrade @strapi/plugin-users-permissions to version 4.24.2 or higher.
Overview
@strapi/plugin-users-permissions is a headless CMS
Affected versions of this package are vulnerable to Open Redirect when user-controllable data is incorporated into the target of a redirection in an unsafe way. In this specific context, this vulnerability allows the SSO token to be stolen, allowing an attacker to authenticate himself within the application.
Notes:
If parameter $_GET["callback"] is defined in the GET request, the assignment does not evaluate all conditions, but stops at the beginning.
The value is then stored in the cookie koa.sess:
koa.sess=eyJncmFudCI6eyJwcm92aWRlciI6Im1pY3Jvc29mdCIsImR5bmFtaWMiOnsiY2FsbGJhY2siOiJodHRwczovL2FkbWluLmludGUubmV0YXRtby5jb20vdXNlcnMvYXV0aC9yZWRpcmVjdCJ9fSwiX2V4cGlyZSI6MTcwMTI3NTY1MjEyMywiX21heEFnZSI6ODY0MDAwMDB9
Which once base64 decoded become {"grant":{"provider":"microsoft","dynamic":{"callback":"https://<TARGET>/users/auth/redirect"}},"_expire":1701275652123,"_maxAge":86400000}.
The signature of the cookie is stored in cookie koa.sess.sig: koa.sess.sig=wTRmcVRrn88hWMdg84VvSD87-_0
Workaround
If possible, applications should avoid incorporating user-controllable data into redirection targets. In many cases, this behavior can be avoided in two ways:
Remove the redirection function from the application, and replace links to it with direct links to the relevant target URLs.
Maintain a server-side list of all URLs that are permitted for redirection. Instead of passing the target URL as a parameter to the redirector, pass an index into this list.
If it is considered unavoidable for the redirection function to receive user-controllable input and incorporate this into the redirection target, one of the following measures should be used to minimize the risk of redirection attacks:
The application should use relative URLs in all of its redirects, and the redirection function should strictly validate that the URL received is a relative URL.
The application should use URLs relative to the web root for all of its redirects, and the redirection function should validate that the URL received starts with a slash character. It should then prepend http://yourdomainname.com to the URL before issuing the redirect.