Sécurité PHP - Attaque d'URL sémantique

Attaque d'URL sémantique

La curiosité est la principale motivation de nombreux attaquants, et les attaques sémantiques d’URL en sont un bon exemple. Ce type d'attaque consiste principalement à modifier l'URL dans l'espoir de découvrir quelque chose d'intéressant. Par exemple, si l'utilisateur Chris clique sur un lien dans votre logiciel et accède à la page http://www.php.cn/, Naturellement, il pourrait essayer de changer la valeur de l'utilisateur et voir ce qui se passe. Par exemple, il peut visiter http://www.php.cn/ pour voir s'il peut voir les informations d'autres personnes. Bien que la manipulation des données GET ne soit que légèrement plus pratique que celle des données POST, leur exposition détermine qu'elles sont plus fréquemment attaquées, en particulier par les attaquants novices.

La plupart des vulnérabilités sont dues à des oublis plutôt qu’à des causes particulièrement complexes. Bien que de nombreux programmeurs expérimentés soient facilement conscients des dangers liés à la confiance dans les URL décrits ci-dessus, ils ne s'en rendent souvent pas compte jusqu'à ce que quelqu'un d'autre le leur fasse remarquer.

Pour mieux démontrer comment les attaques et les vulnérabilités d'URL sémantiques peuvent être négligées, considérons un système de messagerie Web dont la fonction principale est de permettre aux utilisateurs de se connecter et de consulter leurs propres e-mails. Tout système basé sur la connexion utilisateur nécessite un mécanisme de récupération de mot de passe. L'approche habituelle consiste à poser une question que l'attaquant ne connaît probablement pas (comme la marque de votre ordinateur, mais il serait préférable que l'utilisateur puisse spécifier la question et y répondre lui-même. Si la réponse est correcte, une nouvelle réponse). le mot de passe est envoyé à l’adresse e-mail d’inscription spécifiée.

Pour un système de messagerie Web, une adresse e-mail ne peut pas être spécifiée lors de l'inscription, donc les utilisateurs qui répondent correctement à la question seront invités à fournir une adresse e-mail (des informations sur une adresse e-mail alternative peuvent également être collectées pendant qu'un nouveau mot de passe est envoyé à cette adresse e-mail). . Le formulaire suivant permet de demander une nouvelle adresse email, et son nom de compte est stocké dans un champ masqué du formulaire :

CODE :

<form action="reset.php" method="GET">
  <input type="hidden" name="user" value="chris"
/>
  <p>Please specify the email address where
you want your new password sent:</p>
  <input type="text" name="email" /><br
/>
  <input type="submit" value="Send Password"
/>
  </form>

On peut voir que le script de réception reset.php obtiendra toutes les informations, y compris le mot de passe du compte qui est réinitialisé et l'adresse e-mail à laquelle le nouveau mot de passe sera envoyé.

Si un utilisateur peut voir le formulaire ci-dessus (après avoir répondu aux bonnes questions), vous pouvez raisonnablement supposer qu'il est le propriétaire légal du compte Chris. S'il fournit chris@example.org comme adresse e-mail alternative, après la soumission, il sera dirigé vers l'URL suivante :

CODE :

http://www.php.cn/

L'URL apparaît dans la barre du navigateur, afin que quiconque l'ait fait jusqu'ici puisse facilement voir ce que font les variables utilisateur et de messagerie. Après avoir réalisé cela, l'utilisateur a pensé que php@example.org était une adresse très sympa, il a donc visité le lien suivant pour essayer :

CODE :

http://www.php.cn/

Si reset.php fait confiance aux informations fournies par l'utilisateur, il s'agit d'une vulnérabilité d'attaque d'URL sémantique. Dans ce cas, le système générera un nouveau mot de passe pour le compte php et l'enverra à chris@example.org, afin que Chris réussisse à voler le compte php.

Si vous utilisez le suivi de session, vous pouvez facilement éviter la situation ci-dessus :

CODE :

 <?php
 
  session_start();
 
  $clean = array();
  $email_pattern =
&#39;/^[^@\s<&>]+@([-a-z0-9]+\.)+[a-z]{2,}$/i&#39;;
 
  if (preg_match($email_pattern,
$_POST[&#39;email&#39;]))
  {
    $clean[&#39;email&#39;] = $_POST[&#39;email&#39;];
    $user = $_SESSION[&#39;user&#39;];
    $new_password = md5(uniqid(rand(), TRUE));
 
    if ($_SESSION[&#39;verified&#39;])
    {
      /* Update Password */
 
      mail($clean[&#39;email&#39;], &#39;Your New Password&#39;,
$new_password);
    }
  }
 
  ?>

Bien que l'exemple ci-dessus omette certains détails (tels que des informations de courrier électronique plus détaillées ou un mot de passe raisonnable), il démontre le manque de confiance dans le compte fourni par l'utilisateur et, plus important encore, l'utilisation de variables de session pour enregistrer si l'utilisateur a répondu au compte. correctement la question ($_SESSION['verified']) et l'utilisateur qui a répondu correctement à la question ($_SESSION['user']). C'est cette méfiance qui est essentielle pour prévenir les vulnérabilités de votre application.

Cet exemple n'est pas complètement fictif. Il a été découvert par Microsoft en mai 2003 Inspiré par la vulnérabilité de Passport. Veuillez visiter http://www.php.cn/ Voir des exemples spécifiques, des discussions et d’autres informations.

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