Sécurité PHP - Attaque par relecture

Replay Attack

Une attaque par rejeu, parfois appelée attaque de démonstration, consiste à ce qu'un attaquant rejoue des données précédemment envoyées par un utilisateur légitime au serveur pour obtenir l'accès ou d'autres droits attribués à cet utilisateur.

Tout comme le reniflage de mots de passe, la prévention des attaques par rejeu nécessite que vous soyez conscient de l’exposition des données. Pour empêcher les attaques par relecture, vous devez empêcher un attaquant d'obtenir les données utilisées pour accéder à des ressources restreintes. Cela nécessite principalement d'éviter les pratiques suivantes :

Paramétrer l'utilisation des données avec des droits d'accès permanents aux ressources protégées

Paramétrer l'exposition des données protégée ; qui donne accès à des ressources (même aux données qui ne fournissent qu'un accès temporaire

) ; De cette manière, vous ne devez utiliser que les données qui établissent un accès temporaire aux ressources protégées et vous devez également essayer d'éviter la fuite de ces données. Ce ne sont que des lignes directrices générales, mais elles peuvent vous guider sur la façon dont vous opérez.

Le premier principe est, je le sais, violé à une fréquence effrayante. De nombreux développeurs se concentrent uniquement sur la protection des données sensibles contre toute exposition et ignorent les risques causés par l'utilisation des données utilisées pour définir un accès permanent aux ressources protégées.

Par exemple, considérons un script local qui calcule le hachage d'un mot de passe pour un formulaire de validation de formulaire. De cette façon, le texte brut du mot de passe ne sera pas exposé, seule sa valeur de hachage sera exposée. Cela protège le mot de passe d'origine de l'utilisateur. Le principal problème de ce processus est que la vulnérabilité de relecture reste la même : un attaquant peut simplement rejouer une fois le processus d'authentification légitime et réussir l'authentification, et tant que le mot de passe de l'utilisateur est cohérent, le processus d'authentification réussira.

Pour des solutions de fonctionnement plus sécurisées, des fichiers sources JavaScript MD5 et d'autres algorithmes, veuillez consulter http://www.php.cn/ .

Une violation similaire du premier principe consiste à spécifier un cookie pour fournir un accès permanent à une ressource. Par exemple, considérons la tentative suivante d'exécuter un mécanisme d'accès persistant en définissant un cookie :

CODE:
 
  <?php
  $auth = $username . md5($password);
  setcookie(&#39;auth&#39;, $cookie);
  ?>

If An L'utilisateur non authentifié fournit un cookie d'authentification et le programme vérifie si le hachage du mot de passe dans le cookie correspond au hachage du mot de passe stocké dans la base de données. S'ils correspondent, l'utilisateur est authentifié.

Le problème avec ce processus est que l’exposition du cookie d’authentification représente un risque très important. S'il est capturé, l'attaquant obtient un accès permanent. Même si le cookie d'un utilisateur légitime peut expirer, un attaquant peut fournir le cookie pour l'authentification à chaque fois. Voir la figure 7-2 pour une illustration de cette situation.

Une meilleure solution de connexion permanente consiste à utiliser uniquement les données pour définir des droits d'accès temporaires, ce qui est également le sujet de la section suivante.

Ce qui précède est le contenu de l'attaque de sécurité PHP par relecture. Pour plus de contenu connexe, veuillez prêter attention au site Web PHP chinois (www.php. .cn) !