Cross-Site Request Forgery (CSRF) ist eine Art Angriffsmethode, die es einem Angreifer ermöglicht, beliebige HTTP-Anfragen über ein Opfer zu senden. Das Opfer ist hier ein unwissender Komplize, und alle gefälschten Anfragen stammen von ihm und nicht vom Angreifer. Auf diese Weise ist es für Sie sehr schwierig festzustellen, bei welchen Anfragen es sich um Cross-Site-Request-Forgery-Angriffe handelt. Tatsächlich ist Ihre Anwendung wahrscheinlich anfällig, wenn Sie keine Vorkehrungen gegen Cross-Site-Request-Forgery-Angriffe treffen.
Sehen Sie sich unten eine einfache App an, mit der Benutzer Kugelschreiber oder Bleistifte kaufen können. Die Schnittstelle enthält die folgenden Formen:
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>
Ein Angreifer nutzt zunächst Ihre Anwendung, um einige grundlegende Informationen zu sammeln. Beispielsweise greift der Angreifer zunächst auf das Formular zu und entdeckt die beiden Formularelemente „Artikel“ und „Menge“. Er weiß auch, dass der Wert von „Artikel“ ein Bleistift oder ein Kugelschreiber sein wird.
Das folgende buy.php-Programm verarbeitet Formularübermittlungsinformationen:
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>'; } } ?>
Der Angreifer verwendet dieses Formular zunächst zur Beobachtung seine Bewegungen. Beispielsweise weiß der Angreifer nach dem Kauf eines Bleistifts, dass nach erfolgreichem Kauf eine Dankesnachricht erscheint. Nachdem der Angreifer dies bemerkt hat, wird er versuchen herauszufinden, ob derselbe Zweck erreicht werden kann, indem er auf die folgende URL zugreift, um Daten mit GET zu übermitteln:
//m.sbmmt.com/
Im Erfolgsfall verfügt der Angreifer nun über ein URL-Format, das beim Besuch durch einen legitimen Benutzer einen Kauf auslösen kann. In diesem Fall ist es sehr einfach, einen Cross-Site-Request-Forgery-Angriff durchzuführen, da der Angreifer das Opfer lediglich dazu veranlassen muss, die URL zu besuchen.
Während es viele Möglichkeiten gibt, einen Cross-Site-Request-Forgery-Angriff zu starten, ist die Verwendung eingebetteter Ressourcen wie Bilder die häufigste. Um zu verstehen, wie dieser Angriff funktioniert, muss man zunächst verstehen, wie der Browser diese Ressourcen anfordert.
Wenn Sie //m.sbmmt.com/ besuchen (Bild 2-1) fordert Ihr Browser zunächst die durch diese URL identifizierte Ressource an. Sie können den Rückgabeinhalt dieser Anfrage sehen, indem Sie die Quelldatei (HTML) der Seite anzeigen. Das Google-Logobild wurde gefunden, nachdem der Browser den zurückgegebenen Inhalt analysiert hatte. Dieses Bild wird durch das HTML-Tag img dargestellt und das src-Attribut des Tags stellt die URL des Bildes dar. Der Browser gibt dann eine weitere Anfrage für das Bild aus. Der einzige Unterschied zwischen den beiden Anfragen ist die URL.
Abbildung 2-1.
Ein CSRF-Angriff kann ein IMG-Tag verwenden, um dies auszunutzen Erwägen Sie den Besuch einer Website mit dem folgenden Bild Die Quelle:
Basierend auf dem oben genannten Prinzip können Cross-Site-Request-Forgery-Angriffe über das img-Tag durchgeführt werden. Überlegen Sie, ob der Besuch Folgendes beinhaltet Was passiert mit der Seite mit dem folgenden Quellcode:
<img src="http://store.example.org/buy.php?item=pencil&quantity=50" />
Da das buy.php-Skript $_REQUEST anstelle von $_POST verwendet, kauft jeder im Store.example.org-Shop angemeldete Benutzer 50 Stifte, indem er diese URL anfordert.
Das Vorhandensein von Cross-Site-Request-Forgery-Angriffen ist einer der Gründe, warum $_REQUEST nicht empfohlen wird.
Der vollständige Angriffsprozess ist in Abbildung 2-2 dargestellt.
Abbildung 2-2. Cross-Site-Request-Forgery-Angriff durch Bilder
Beim Anfordern eines Bildes ändern einige Browser den Accept-Wert des Anforderungsheaders, um dem Bildtyp eine höhere Priorität zu geben. Um dies zu verhindern, sind Schutzmaßnahmen erforderlich.
你需要用几个步骤来减轻跨站请求伪造攻击的风险。一般的步骤包括使用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中文网(m.sbmmt.com)!