Maison >développement back-end >tutoriel php >Falsification de requêtes de sécurité inter-sites PHP
La falsification de requêtes intersites (CSRF) est un type de méthode d'attaque qui permet à un attaquant d'envoyer des requêtes HTTP arbitraires via une victime. La victime ici est un complice involontaire, et toutes les fausses demandes proviennent de lui, pas de l'agresseur. De cette façon, il vous est très difficile de déterminer quelles requêtes sont des attaques de falsification de requêtes intersites. En fait, si vous ne prenez pas de précautions contre les attaques de falsification de requêtes intersites, votre application risque d'être vulnérable.
Jetez un œil ci-dessous à une application simple qui permet aux utilisateurs d'acheter des stylos ou des crayons. L'interface contient les formulaires suivants :
CODE :
<form action="buy.php" method="POST"> <p> Item: <select name="item"> <option name="pen">pen</option> <option name="pencil">pencil</option> </select><br /> Quantity: <input type="text" name="quantity" /><br /> <input type="submit" value="Buy" /> </p> </form>
Un attaquant utilisera dans un premier temps votre application pour collecter des informations de base. Par exemple, l'attaquant accède d'abord au formulaire et découvre les deux éléments du formulaire item et quantité. Il sait également que la valeur de item sera un crayon ou un stylo.
Le programme buy.php suivant gère les informations de soumission du formulaire :
CODE :
<?php session_start(); $clean = array(); if (isset($_REQUEST['item'] && isset($_REQUEST['quantity'])) { /* Filter Input ($_REQUEST['item'], $_REQUEST['quantity']) */ if (buy_item($clean['item'], $clean['quantity'])) { echo '<p>Thanks for your purchase.</p>'; } else { echo '<p>There was a problem with your order.</p>'; } } ?>
L'attaquant utilisera dans un premier temps ce formulaire pour observer ses mouvements. Par exemple, après avoir acheté un crayon, l’attaquant sait qu’un message de remerciement apparaîtra une fois l’achat réussi. Après avoir remarqué cela, l'attaquant tentera de voir si le même objectif peut être atteint en accédant à l'URL suivante pour soumettre des données à l'aide de GET :
http://www.php.cn/
En cas de succès, l'attaquant dispose désormais d'un format d'URL qui peut déclencher un achat lorsqu'il est visité par un utilisateur légitime. Dans ce cas, il est très simple de mener une attaque de falsification de requêtes intersites car l’attaquant n’a qu’à amener la victime à visiter l’URL.
Bien qu’il existe de nombreuses façons de lancer une attaque de falsification de requêtes intersites, l’utilisation de ressources intégrées telles que des images est la plus courante. Afin de comprendre le fonctionnement de cette attaque, il faut d’abord comprendre comment le navigateur sollicite ces ressources.
Lorsque vous visitez http://www.php.cn/ (photo 2-1), votre navigateur demandera dans un premier temps la ressource identifiée par cette URL. Vous pouvez voir le contenu renvoyé de cette requête en visualisant le fichier source (HTML) de la page. L'image du logo Google a été trouvée après que le navigateur ait analysé le contenu renvoyé. Cette image est représentée par la balise HTML img et l'attribut src de la balise représente l'URL de l'image. Le navigateur émet ensuite une autre requête pour l'image. La seule différence entre les deux requêtes est l'URL.
Figure 2-1 La page d'accueil de Google
<.>
Une attaque CSRF peut utiliser une balise img pour en tirer parti comportement. Pensez à visiter un site Web avec l’image suivante identifiée dans la source :
Sur la base du principe ci-dessus, des attaques de falsification de requêtes intersites peuvent être réalisées via la balise img. Déterminez si la visite comprend Qu'adviendra-t-il de la page avec le code source suivant :
<img src="http://store.example.org/buy.php?item=pencil&quantity=50" />
Étant donné que le script buy.php utilise $_REQUEST au lieu de $_POST, chaque utilisateur connecté à la boutique store.example.org achètera 50 crayons en demandant cette URL.
L'existence d'attaques de falsification de requêtes intersites est l'une des raisons pour lesquelles $_REQUEST n'est pas recommandé.
Le processus d'attaque complet est illustré à la figure 2-2.
Figure 2-2. Attaque de falsification de requêtes intersites provoquée par des images
Lors de la demande d'une image, certains navigateurs modifient la valeur Accepter de l'en-tête de la demande pour donner au type d'image une priorité plus élevée. Des mesures de protection sont nécessaires pour éviter que cela ne se produise.
你需要用几个步骤来减轻跨站请求伪造攻击的风险。一般的步骤包括使用POST方式而不是使用GET来提交表单,在处理表单提交时使用$_POST而不是$_REQUEST,同时需要在重要操作时进行验证(越是方便,风险越大,你需要求得方便与风险之间的平衡)。
任何需要进行操作的表单都要使用POST方式。在RFC 2616(HTTP/1.1传送协议,译注)的9.1.1小节中有一段描述:
“特别需要指出的是,习惯上GET与HEAD方式不应该用于引发一个操作,而只是用于获取信息。这些方式应该被认为是‘安全’的。客户浏览器应以特殊的方式,如POST,PUT或DELETE方式来使用户意识到正在请求进行的操作可能是不安全的。”
最重要的一点是你要做到能强制使用你自己的表单进行提交。尽管用户提交的数据看起来象是你表单的提交结果,但如果用户并不是在最近调用的表单,这就比较可疑了。请看下面对前例应用更改后的代码:
CODE:
<?php session_start(); $token = md5(uniqid(rand(), TRUE)); $_SESSION['token'] = $token; $_SESSION['token_time'] = time(); ?> <form action="buy.php" method="POST"> <input type="hidden" name="token" value="<?php echo $token; ?>" /> <p> Item: <select name="item"> <option name="pen">pen</option> <option name="pencil">pencil</option> </select><br /> Quantity: <input type="text" name="quantity" /><br /> <input type="submit" value="Buy" /> </p> </form>
通过这些简单的修改,一个跨站请求伪造攻击就必须包括一个合法的验证码以完全模仿表单提交。由于验证码的保存在用户的session中的,攻击者必须对每个受害者使用不同的验证码。这样就有效的限制了对一个用户的任何攻击,它要求攻击者获取另外一个用户的合法验证码。使用你自己的验证码来伪造另外一个用户的请求是无效的。
该验证码可以简单地通过一个条件表达式来进行检查:
CODE:
<?php if (isset($_SESSION['token']) && $_POST['token'] == $_SESSION['token']) { /* Valid Token */ } ?>
你还能对验证码加上一个有效时间限制,如5分钟:
CODE:
<?php $token_age = time() - $_SESSION['token_time']; if ($token_age <= 300) { /* Less than five minutes has passed. */ } ?>
通过在你的表单中包括验证码,你事实上已经消除了跨站请求伪造攻击的风险。可以在任何需要执行操作的任何表单中使用这个流程。
尽管我使用img标签描述了攻击方法,但跨站请求伪造攻击只是一个总称,它是指所有攻击者通过伪造他人的HTTP请求进行攻击的类型。已知的攻击方法同时包括对GET和POST的攻击,所以不要认为只要严格地只使用POST方式就行了。
以上就是PHP安全-跨站请求伪造的内容,更多相关内容请关注PHP中文网(www.php.cn)!