mirror of
https://github.com/projectsend/projectsend.git
synced 2026-10-06 13:21:56 +00:00
717852ff6a
An account that signs in through a provider has no password to prove, so the password screen let the signed-in session choose one with no proof at all. A stolen session could then make itself permanent: set a password, confirm it, enrol its own second factor and remove the owner's last provider, since the account now read as local. The screen now refuses to set a provider account's password and offers to email a link instead: the ordinary reset link, to the account's own address, so whoever sets the password must read that inbox. The reset pages accept a signed-in visitor, since the owner opens the link in the browser they are signed in with; the token, not the session, is the authority. Using the link signs out every session holding the old password, the one that asked for it included. Compulsory two-factor lets the link through, so a provider account still has a way to enrol. Ordinary accounts are unchanged: they prove their current password. GHSA-4r8h-mwfm-f5f4
72 lines
2.9 KiB
PHP
72 lines
2.9 KiB
PHP
<?php
|
|
|
|
declare(strict_types=1);
|
|
|
|
namespace App\Modules\Identity\Http\Middleware;
|
|
|
|
use App\Modules\Identity\TwoFactor\TwoFactorEnforcement;
|
|
use App\Modules\Platform\Settings\Setting;
|
|
use App\Modules\Platform\Settings\Settings;
|
|
use App\Support\WriteSafeRedirect;
|
|
use Closure;
|
|
use Illuminate\Http\Request;
|
|
use Symfony\Component\HttpFoundation\Response;
|
|
|
|
/**
|
|
* When the installation enforces two-factor authentication for the
|
|
* user's type, an un-enrolled user can only reach the 2FA setup screen
|
|
* (and the exits: logout, locale) until they enable it.
|
|
*/
|
|
class EnforceTwoFactor
|
|
{
|
|
public function __construct(
|
|
private readonly Settings $settings,
|
|
) {}
|
|
|
|
public function handle(Request $request, Closure $next): Response
|
|
{
|
|
$user = $request->user();
|
|
|
|
if ($user === null || $user->hasTwoFactorEnabled()) {
|
|
return $next($request);
|
|
}
|
|
|
|
$value = $this->settings->get(Setting::TwoFactorEnforcement);
|
|
|
|
$enforcement = (is_string($value) ? TwoFactorEnforcement::tryFrom($value) : null)
|
|
?? TwoFactorEnforcement::None;
|
|
|
|
if (! $enforcement->appliesTo($user->type)) {
|
|
return $next($request);
|
|
}
|
|
|
|
// password.confirm* is on this list because the two-factor mutation
|
|
// routes now require it: without the exemption, enrolling would
|
|
// redirect to the confirm-password screen, which this middleware
|
|
// would redirect straight back to two-factor.show — a loop that
|
|
// locks the user out of the only exit.
|
|
//
|
|
// The pattern covers both halves of that screen. Naming only the
|
|
// GET left the form rendering and its submission redirected away,
|
|
// so the password was never confirmed and the loop stayed shut
|
|
// one step further along than before.
|
|
// password.edit/update is on it for the same shape of reason, one
|
|
// step further out: an account provisioned by a provider has no
|
|
// password to confirm with, so the confirm screen sends it to set
|
|
// one — and without this, that screen was redirected back here
|
|
// too. The loop then had no exit at all, which is how an
|
|
// installation that made two-factor compulsory locked out
|
|
// everybody who signs in with Microsoft.
|
|
//
|
|
// password.link, password.reset and password.store complete that
|
|
// same exit now that a provider account's first password arrives by
|
|
// email: asking for the link, opening it and saving it all happen
|
|
// while signed in, before there is a password to enrol with.
|
|
if ($request->routeIs('two-factor.*', 'password.confirm*', 'password.edit', 'password.update', 'password.link', 'password.reset', 'password.store', 'logout', 'locale.update')) {
|
|
return $next($request);
|
|
}
|
|
|
|
return WriteSafeRedirect::apply($request, redirect()->route('two-factor.show')->with('two_factor_enforced_notice', true));
|
|
}
|
|
}
|