Étiquette : Sécurité

[PHP] Identification basique avec CakePHP 4.x

[PHP] Identification basique avec CakePHP 4.x

Si vous utilisez le framework CakePHP et que vous avez dû migrer vers la dernière version pour bénéficier de la compatibilité avec PHP 8.1, vous aurez probablement dû migrer votre système d’identification.

CakePHP : identification basique

Ce petit tutoriel se base sur la documentation officielle, en apportant quelques modifications si vous n’avez pas la même structure au niveau de votre table d’utilisateurs ou de vos contrôleurs.

Installation du plugin

Il faut tout d’abord installer le plugin fourni par CakePHP. Pour cela on utilise l’outil composer.

composer require "cakephp/authentication:^2.0"

Cette version est bien sûr compatible avec la version 4 du framework.

Chargement du plugin

Il faut maintenant éditer le fichier src/Application.php et y ajouter la méthode qui chargera le plugin.

Dans la méthode bootstrap(), après tous les éléments déjà chargés, ajoutez ce bout de code:

$this->addPlugin('Authentication');

Configuration du middleware

Le plugin va permettre de gérer facilement l’authentification d’un utilisateur, et va appliquer une stratégie de sécurité par défaut quelque soit l’action demandée.

Toujours dans le même fichier src/Application.php, ajoutez d’abord les imports nécessaires.

use Authentication\AuthenticationService;
use Authentication\AuthenticationServiceInterface;
use Authentication\AuthenticationServiceProviderInterface;
use Authentication\Identifier\IdentifierInterface;
use Authentication\Middleware\AuthenticationMiddleware;
use Cake\Http\MiddlewareQueue;
use Cake\Routing\Router;
use Psr\Http\Message\ServerRequestInterface;

Ensuite, ajoutez l’implémentation de l’interface:

class Application extends BaseApplication implements AuthenticationServiceProviderInterface

Puis modifiez la méthode middleware() et spécifiez la classe qui implémentera le middleware d’authentification. Dans ce cas, il s’agit de l’instance actuelle.

$middlewareQueue->add(new AuthenticationMiddleware($this));

Faites particulièrement attention à l’ordre : il doit être placé après BodyParserMiddleware et RoutingMiddleware.

Implémentation

Il faut ensuite ajouter la méthode getAuthenticationService(). Elle sera appelée à chaque fois qu’une requête est traitée.

public function getAuthenticationService(
    ServerRequestInterface $request
   ): AuthenticationServiceInterface
{
	$service = new AuthenticationService();

	// Automatic redirection when not authenticated
	$service->setConfig([
		'unauthenticatedRedirect' => Router::url([
			'prefix' => false,
			'plugin' => null,
			'controller' => 'Utilisateurs',
			'action' => 'login',
		]),
		'queryParam' => 'redirect',
	]);

	$fields = [
		IdentifierInterface::CREDENTIAL_USERNAME => 'nom',
		IdentifierInterface::CREDENTIAL_PASSWORD => 'password'
	];
	
	// Load the authenticators. Session should be first.
	$service->loadAuthenticator('Authentication.Session');
	$service->loadAuthenticator('Authentication.Form', [
		'fields' => $fields,
		'loginUrl' => Router::url([
			'prefix' => false,
			'plugin' => null,
			'controller' => 'Utilisateurs',
			'action' => 'login',
		]),
	]);
	
	$service->loadIdentifier('Authentication.Password', [
	  'resolver' => [
		'className' => 'Authentication.Orm',
		'userModel' => 'Utilisateurs',
	  ],
	  'fields' => [
		'username' => 'nom',
		'password' => 'password',
	  ],
	]);

	return $service;
}

Ce qu’on fait :

  • On définit avec setConfig() la stratégie à appliquer quand un utilisateur n’est pas connecté.
  • On spécifie les paramètres utilisés pour le formulaire d’identification.
  • On spécifie la liste des champs qui servent à identifier l’utilisateur.

Ici des modifications ont été apportées par rapport à l’exemple par défaut.

  • La classe du contrôleur qui gérera l’identification s’appelle UtilisateursController. Il faut donc spécifier « Utilisateurs » comme nom de contrôleur. CakePHP résoudra le nom complet lui-même.
  • Les champs de la table que l’on utilise sont le nom et password.
  • Notre table n’est pas appelée users mais utilisateurs. On le spécifie dans la clé resolver.

Charger le composant

Dans le contrôleur par défaut AppController.php (dont vos contrôleurs devront hériter), ajoutez l’appel suivant dans la méthode initialize().

$this->loadComponent('Authentication.Authentication');

L’erreur fréquente à ne pas reproduire: si vous écrivez une méthode initialize() dans un contrôleur enfant, n’oubliez pas d’appeler la méthode parent.

Désactiver l’authentification au cas par cas

Par défaut, toutes les actions nécessiteront une authentification. Mais vous pouvez modifier ce comportement en ajoutant l’événement beforeFilter() à chaque contrôleur où vous souhaitez que cela s’applique.

public function beforeFilter(EventInterface $event)
{
    $this->Authentication->allowUnauthenticated([
        'register', 'login', 'logout'
    ]);
}

On appelle la méthode allowUnauthenticated() de l’objet d’authentification, et on lui spécifie un tableau d’actions. Dans notre cas on autorise notamment login puisque c’est la méthode qui permet de gérer la requête d’auhentification.

Traiter la requête d’identification

Lorsqu’on valide le formulaire d’identification, voici l’action exécutée. La méthode est ajoutée au sein du contrôleur UtilisateursController.

public function login()
{
	if ($this->request->is('post')) 
	{
		$user = $this->Authentication->getResult();
		if ($user->isValid()) 
		{
			$target = $this->Authentication
				->getLoginRedirect() ?? '/';
			return $this->redirect($target);
		}
		
		$this->Flash->error(__("Bad user or password"));
	}
}

La méthode isValid() confirme si l’authentification s’est bien déroulée. Si c’est le cas on redirige l’utilisateur vers l’URL qu’on récupère à l’aide de getLoginRedirect(), et si celle-ci n’existe pas on redirigera vers la route « / ».

Dans le template associé, voici le code qui génère le formulaire:

<div class="users form">
<?= $this->Form->create() ?>
    <fieldset class="subfield">
        <legend><?= __("Saisissez vos identifiants") ?></legend>
        <?= $this->Form->control('nom',
                    ['label'=>'Identifiant']) ?>
        <?= $this->Form->control('password',
                    ['label'=>'Mot de passe']) ?>
  
<?= $this->Form->button(__('Connexion')); ?>
  </fieldset>
<?= $this->Form->end() ?>
</div>

Attention à bien respecter le nom des champs définis dans la configuration du middleware. Ils correspondent également aux champs définis dans le modèle.

Traiter la requête de déconnexion

Toujours dans le même contrôleur, on peut ajouter une action logout().

public function logout()
{
	$this->Authentication->logout();
	return $this->redirect([
		'controller' => 'Utilisateurs', 'action' => 'login'
	]);
}

La session de l’utilisateur est invalidée automatiquement.

Sources

[Sécurité] Découverte d’une faille de sécurité critique dans Spring

[Sécurité] Découverte d’une faille de sécurité critique dans Spring

Comme nous le rapporte le magazine Programmez! VMWare signale la présence d’une faille de sécurité critique dans son produit Spring, permettant l’exécution de code à distance (RCE). Cela touche les versions de Spring Framework 5.2.0 à 5.2.19 et 5.3.0 à 5.3.17, ainsi que des versions plus anciennes. Reprise sous l’identifiant CVE-2022-22965 et baptisée Spring4Shell, cette faille ne peut être exploitée que si certaines conditions sont réunies.

Faille de sécurité Spring

En effet, sont vulnérables des applications Spring MVC ou WebFlux, tournant sur une JDK 9 (ou supérieur) sur un serveur Tomcat, et qui ne sont pas déployées en tant qu’exécutables Spring Boot (mais bien sous la forme d’archives WAR). Dans sa note, VMWare met toutefois en garde que la faille pourrait être exploitée par d’autres moyens.

VMWare recommande de mettre à jour au plus vite vos applications avec une version plus récente de Spring Framework. S’il n’est pas possible pour vous de changer de version, des solutions de contournement sont proposées dans une publication sur le blog de Spring.

Sources

[Sécurité] Avast Threat Labs publie ses recherches sur Crackonosh

[Sécurité] Avast Threat Labs publie ses recherches sur Crackonosh

Le laboratoire Avast Threat Labs a publié ses recherches sur le malware Crackonosh. Ce dernier a pour particularité d’utiliser les ressources de votre machine afin de miner de la cryptomonnaie. On le retrouve dans des versions pirates de jeux vidéo. En circulation depuis près de trois ans, il aurait rapporté à ses créateurs près de deux millions de dollars en Monero, d’après Global Security Mag.

avast recherches Crackonosh

En France, Avast a recensé 7205 systèmes infectés. Chez nous, en Belgique, on compte 1815 systèmes touchés. Le top 3 des pays impactés comprend les Philippines, le Brésil et l’Inde, avec respectivement 18448, 16584 et 13779 systèmes touchés.

Dans ses recherches, Avast a détecté la présence du malware Crackonosh dans l’installateur des jeux suivants :

NBA 2K19
Grand Theft Auto V
Far Cry 5
Les Sims 4 : Saisons
Euro Truck Simulator 2
Les Sims 4
Jurassic World Evolution
Fallout 4 GOTY
Call of Cthulhu
Pro Evolution Soccer 2018
We Happy Few

Si vous voulez en savoir plus sur le fonctionnement de ce malware, consultez la publication complète – en anglais – sur le site Decoded, rédigée par Daniel Beneš. On notera par exemple que, parmi ses fonctionnalités, le logiciel malveillant est capable de désactiver certaines protections antivirus lorsqu’il est activé.

Pour éviter ce genre de situation fâcheuse, le mieux est finalement de vous procurer une copie légale de vos jeux.

Sources

[WordPress] L’extension Ninja Forms également touchée par plusieurs failles de sécurité

[WordPress] L’extension Ninja Forms également touchée par plusieurs failles de sécurité

L’un des avantages de WordPress, c’est la possibilité d’installer des extensions pour en étendre les fonctionnalités. En 2019 on en comptait plus de 55.000 rien que dans le dépôt officiel. Et parmi celles-ci la populaire extension Ninja Forms fait parler d’elle. En effet c’est via Clubic que nous apprenons qu’elle est touchée par plusieurs failles de sécurité.

wordpress ninja forms failles

Pour ceux qui ne connaissent pas cette extension, Ninja Forms est en fait un gestionnaire de formulaires pour vos sites (exemple basique : pour créer facilement une page de contact pour vos visiteurs). D’après la page descriptive, il y aurait plus d’un million d’installations actives.

Les failles découvertes sont au nombre de quatre, et sont très bien détaillées par le site Threatpost. La première permettrait d’intercepter le trafic des e-mails envoyés via SendWP. Cela fait repenser au bug qui avait été découvert dans l’extension Easy WP SMTP Settings. Nous en parlions il y a quelques semaines. Le score CVSS de cette vulnérabilité est de 9.9 sur 10.

Ensuite deux failles concernent l’outil de gestion des modules complémentaires, intégré à Ninja Forms. L’une d’entre elle permettrait de mettre fin à une connexion autorisée via OAuth. Enfin, la dernière faille – considérée comme moyennement grave avec un score CVSS de 4,8 – permettrait de rediriger aisément un utilisateur vers une URL malveillante après sa connexion.

Un correctif rapide

Heureusement tous ces problèmes seraient résolus depuis la version 3.4.34.1 publiée le 8 février 2021. Depuis l’extension a reçu d’autres mises à jour. Les statistiques nous montrent qu’actuellement 64,2 % des versions actives sont en 3.4 (sans spécifier le numéro précis). 13% d’entre elles sont en version 3.2 ou inférieur. Cela fait donc potentiellement un paquet de sites vulnérables.

Si vous utilisez WordPress et en particulier Ninja Forms, vérifiez vite les mises à jour, sauf si vous avez activé l’automatisation de celles-ci pour vos extensions (ce qui peut être utile dans ce cas précis). De manière générale il est bon de rappeler de faire attention à ce que vous installez. Par exemple, une extension ou un thème dont le développement n’est plus suivi, pourrait être problématique.

Sources

[WordPress] Découverte d’une faille dans l’extension Easy WP SMTP Settings

[WordPress] Découverte d’une faille dans l’extension Easy WP SMTP Settings

WordPress est un CMS – Content Management System, ou « Système de gestion de contenu » en français – largement utilisé sur de nombreux sites. Il offre notamment aux utilisateurs la possibilité d’installer des extensions développées par des tiers. Celles-ci ne sont pas toujours sans défaut. C’est en tout cas ce qu’a démontré la découverte d’une faille dans l’extension Easy WP SMTP Settings, heureusement déjà corrigée.

faille plugin smtp

Comme son nom le suggère, l’extension permet aux propriétaires de leur site de configurer les paramètres pour l’envoi d’e-mail. Cela concerne notamment ceux envoyés par WordPress. Par exemple, quand un utilisateur veut réinitialiser son mot de passe, un lien est généré puis transmis à l’utilisateur par e-mail.

C’est malheureusement à cause de ceux-ci que des personnes mal intentionnées ont été capables d’intercepter les liens et réinitialiser les mots de passe de comptes. En effet, dans la version 1.4.2 (et inférieures) le dossier de l’extension ne contient pas de page « index.html » ou similaire. Cela a pour conséquence de permettre l’affichage du contenu du dossier si la fonctionnalité est active sur le serveur.

Il est ainsi possible d’accéder à un fichier journal, qui contient toutes les traces d’envoi des mails. Il reprend évidemment le contenu de ceux-ci. Ainsi il ne reste plus qu’à récupérer les liens de réinitialisation… et le tour est joué !

L’auteur de l’extension a d’ores et déjà corrigé le problème dans la version 1.4.4 d’après les notes de version. On soulignera cependant que le nombre d’installations actives est de plus de 500.000. Si vous consultez la vue avancée sur la page de description de l’extension, vous pourrez constater que 43% de versions actives sont en 1.3, ce qui est relativement inquiétant. Cela signifie que de nombreux sites sont encore vulnérables aux attaques.

Si vous utilisez donc cette extension sur votre site, procédez rapidement à sa mise à jour!

Sources