Gestion des sessions – pro-gamification

Sommaire

Introduction
Les bonnes pratiques
Exemples
Conclusion

Introduction:

La gestion des sessions est un pilier essentiel dans l’architecture de la sécurité d’une application web. Ce mécanisme qui peut sembler simple au premier abord, s’avère être un enjeu majeur dans la protection des informations sensibles et dans l’assurance d’une expérience utilisateur sécurisée et transparente.

Lorsqu’un utilisateur se connecte à une application web, une session est généralement créée pour suivre son interaction avec le site. Cette session permet de maintenir un certain état entre les différentes requêtes HTTP, qui sont par nature sans état. Le fait de ne pas gérer correctement les sessions peut conduire à des failles de sécurité majeures, notamment les attaques par usurpation de session et par fixation de session.

La mise en œuvre d’une gestion sécurisée des sessions n’est pas une tâche triviale. Elle nécessite une compréhension approfondie des menaces potentielles et des moyens de les atténuer. Cela implique également de se tenir au courant des meilleures pratiques et des recommandations de sécurité.

Dans cet esprit, cet article vise à vous fournir un guide détaillé sur la gestion sécurisée des sessions. Nous passerons en revue une liste de bonnes pratiques à adopter, et expliquerons en détail pourquoi chaque point est important. Nous fournirons également des exemples concrets de ce qu’il faut faire et ne pas faire pour illustrer ces principes. Nous espérons que ce guide vous aidera à renforcer la sécurité de vos applications web.

Bonnes pratiques:

Établir un délai d’inactivité de session le plus court possible : Limiter la durée d’inactivité d’une session à quelques heures permet de réduire le risque d’attaques, notamment si un utilisateur oublie de se déconnecter d’une session ouverte sur un appareil partagé.
Fermer et établir une nouvelle session après une connexion réussie : Si une session est établie avant la connexion, elle doit être fermée et une nouvelle session doit être créée après une connexion réussie. Cela permet d’éviter la réutilisation des identifiants de session et de réduire le risque de vol de session.
Interdire les connexions concurrentes avec le même identifiant utilisateur : Cette pratique empêche un utilisateur de se connecter à partir de plusieurs appareils en même temps, limitant ainsi les chances d’accès non autorisé à son compte.
Utiliser des algorithmes bien établis pour assurer des identifiants de session suffisamment aléatoires : Les identifiants de session doivent être générés de manière aléatoire et imprévisible pour éviter les attaques par force brute.
La création de l’ID de session doit toujours être faite côté serveur : Cela évite que des identifiants de session soient générés du côté client, ce qui pourrait être exploité par des attaquants.
Ne pas passer les identifiants de session en tant que paramètres GET : Transmettre les identifiants de session dans l’URL pourrait exposer ces informations dans les logs du serveur ou les historiques de navigation.
Les données de session côté serveur devraient avoir des contrôles d’accès appropriés en place : Cela limite l’accès aux données sensibles stockées dans la session et prévient les modifications non autorisées.
Générer un nouvel ID de session et désactiver l’ancien fréquemment : Cela minimise la fenêtre d’opportunité pour qu’un attaquant puisse usurper une session.
Générer un nouveau jeton de session si les privilèges ou le rôle d’un utilisateur changent : Les changements de privilèges pourraient rendre une session plus attrayante pour un attaquant. Un nouveau jeton de session limite ce risque.
Générer un nouveau jeton de session si la sécurité de la connexion passe de HTTP à HTTPS : Le passage de HTTP à HTTPS augmente le niveau de sécurité de la session, il est donc judicieux de générer un nouveau jeton de session pour correspondre à ce niveau de sécurité.
N’utiliser que les ID de session générés par le système pour la gestion de l’état côté client : Cela évite que des attaquants manipulent les données d’état stockées du côté client.
Utiliser des jetons ou des paramètres aléatoires par session dans les formulaires web ou les URL associés à des opérations sensibles côté serveur : Cela permet de prévenir les attaques de type Cross Site Request Forgery (CSRF) qui cherchent à exploiter la confiance qu’un site a en un navigateur utilisateur.
Utiliser des jetons ou des paramètres aléatoires par page pour compléter le jeton de session principal pour des opérations critiques : Cela fournit une couche de sécurité supplémentaire pour les opérations sensibles et aide à prévenir les attaques de type CSRF.
Assurer que les cookies transmis sur une connexion cryptée ont l’attribut « secure » défini : Cet attribut indique que le cookie ne doit être envoyé qu’au-dessus d’une connexion cryptée, ce qui empêche l’interception des cookies lors de la transmission entre le client et le serveur.
Définir les cookies avec l’attribut HttpOnly, à moins que vous n’ayez spécifiquement besoin que des scripts côté client de votre application lisent ou définissent une valeur de cookie : L’attribut HttpOnly empêche les scripts côté client de lire ou de modifier les cookies, protégeant ainsi contre les attaques de type Cross Site Scripting (XSS).
L’application ou le système devrait enregistrer les tentatives de connexion avec des jetons de session invalides ou expirés : La surveillance des tentatives de connexion échouées peut aider à détecter et à répondre aux tentatives d’attaques.
Interdire les connexions persistantes et forcer les terminaisons de session périodiques, même lorsque la session est active : Cela est particulièrement important pour les applications qui établissent des connexions réseau riches ou qui se connectent à des systèmes critiques. Les délais de terminaison devraient soutenir les exigences commerciales et l’utilisateur devrait recevoir une notification suffisante pour atténuer les impacts négatifs.

Exemples:

Examinons un exemple simple de code PHP qui ne respecte pas ces directives :

<?php
session_start();

if(isset($_GET['id'])) {
    $_SESSION['id'] = $_GET['id'];
}

if(isset($_POST['username']) && isset($_POST['password'])) {
    // validate user credentials
    $username = $_POST['username'];
    $password = $_POST['password'];

    // if validation successful
    $_SESSION['logged_in'] = true;
    $_SESSION['username'] = $username;
}
?>

Dans cet exemple, nous voyons plusieurs problèmes de sécurité importants :

Passage de l’identifiant de session en tant que paramètre GET : Le code récupère un identifiant de session à partir d’un paramètre GET, ce qui est contraire aux directives de sécurité. Les identifiants de session ne doivent jamais être passés dans l’URL, car ils pourraient être exposés dans les logs du serveur ou les historiques de navigation.
La création d’ID de session n’est pas faite côté serveur : L’ID de session est simplement pris à partir des paramètres GET, au lieu d’être généré de manière sécurisée côté serveur.
Pas de nouveau jeton de session après la connexion : Après une connexion réussie, le même ID de session est conservé. Cela signifie qu’un attaquant qui a réussi à obtenir l’ID de session d’un utilisateur avant sa connexion pourrait toujours avoir accès à sa session après sa connexion.
Pas de vérification des tentatives de connexion avec des jetons de session invalides ou expirés : Le code ne vérifie pas si l’ID de session fourni est valide ou non. Un attaquant pourrait donc essayer de deviner les ID de session sans être détecté.

Ces problèmes peuvent permettre à un attaquant d’usurper la session d’un utilisateur et d’obtenir un accès non autorisé à ses données. De plus, ils peuvent permettre à un attaquant d’effectuer des attaques par force brute pour deviner les ID de session sans être détecté.

Nous allons maintenant corriger le code précédent afin qu’il respecte les directives de sécurité :

<?php
// Start the session
session_start();

// When the user attempts to log in
if(isset($_POST['username']) && isset($_POST['password'])) {
    // Validate user credentials
    $username = $_POST['username'];
    $password = $_POST['password'];

    // Imagine there is a function checkCredentials() that verifies the username and password against a database.
    if(checkCredentials($username, $password)) {
        // If validation is successful, regenerate the session ID to prevent session fixation attacks
        session_regenerate_id();

        // Set the necessary session variables
        $_SESSION['logged_in'] = true;
        $_SESSION['username'] = $username;

        // Set a session timeout
        $_SESSION['last_activity'] = time();
        $_SESSION['expire_time'] = 30*60; // Session expires after 30 minutes of inactivity
    } else {
        // Log the unsuccessful login attempt
        error_log("Unsuccessful login attempt: ".$username);
    }
}

// Check if the session is still active
if(isset($_SESSION['last_activity']) && (time() - $_SESSION['last_activity']) > $_SESSION['expire_time']) {
    // Session has expired, destroy it
    session_unset();
    session_destroy();
} else {
    // The session is still active, update the last activity time
    $_SESSION['last_activity'] = time();
}
?>

Dans cet exemple corrigé, plusieurs améliorations ont été apportées par rapport au précédent :

Création d’ID de session côté serveur : L’ID de session est maintenant généré côté serveur à l’aide de la fonction session_regenerate_id(). Cela empêche les attaquants de fournir leur propre ID de session.
Nouveau jeton de session après la connexion : Après une connexion réussie, un nouvel ID de session est généré. Cela empêche un attaquant qui a obtenu l’ID de session avant la connexion de continuer à utiliser cette session.
Vérification des tentatives de connexion avec des jetons de session invalides ou expirés : Le code vérifie maintenant si la session a expiré en fonction du temps d’inactivité, et détruit la session si c’est le cas. De plus, une tentative de connexion infructueuse est maintenant enregistrée dans les logs d’erreur.
Délai d’inactivité de la session : Un délai d’inactivité de la session est maintenant en place. Si l’utilisateur n’effectue aucune action pendant 30 minutes, sa session expire et il doit se reconnecter.

Ces améliorations permettent de résoudre les problèmes de sécurité mentionnés précédemment et de rendre l’application plus résistante aux attaques par usurpation de session et par force brute. Cependant, il convient de noter qu’il s’agit toujours d’un exemple simplifié et qu’une véritable application web nécessiterait des mesures de sécurité supplémentaires.

Conclusion:

La gestion sécurisée des sessions est un aspect fondamental de la sécurité d’une application web. En respectant les directives et les meilleures pratiques établies, nous pouvons limiter considérablement le risque d’attaques et protéger les informations sensibles de nos utilisateurs.

Dans cet article, nous avons passé en revue un certain nombre de ces directives, démontré des exemples de code qui ne respectent pas ces directives, puis montré comment corriger ces problèmes pour améliorer la sécurité. Il est important de se rappeler que chaque application est unique et peut nécessiter des mesures de sécurité supplémentaires.

En fin de compte, il est de notre responsabilité en tant que développeurs de comprendre les risques associés à la gestion des sessions et de faire tout notre possible pour minimiser ces risques. La sécurité sur Internet est un effort commun, et chaque pas que nous faisons pour renforcer nos applications contribue à un Internet plus sûr pour tous.

Laisser un commentaire Annuler la réponse