Cross-Site-Request-Forgery-CSRF-Angriff und -Verteidigung

1. Was ist CSRF?

CSRF (Cross-Site Request Forgery), chinesischer Name: Cross-Site Request Forgery, auch bekannt als: One Click Attack/Session Riding, abgekürzt als: CSRF/XSRF.

2. Was kann CSRF tun?

Sie können CSRF-Angriffe so verstehen: Der Angreifer stiehlt Ihre Identität und sendet in Ihrem Namen böswillige Anfragen. Was CSRF tun kann, umfasst: das Versenden von E-Mails und Nachrichten in Ihrem Namen, den Diebstahl Ihres Kontos und sogar den Kauf von Waren, virtuelle Währungstransfers ... Zu den verursachten Problemen gehören: Verlust der Privatsphäre und der Eigentumssicherheit.

3. Aktueller Stand der CSRF-Schwachstellen

Diese Angriffsmethode von CSRF wurde im Jahr 2000 von ausländischen Sicherheitskräften vorgeschlagen, aber in China begann sie erst 2006 Beachtung zu finden. Im Jahr 2008 wurden CSRF-Schwachstellen im In- und Ausland in vielen großen Communities und interaktiven Websites gemeldet, wie zum Beispiel: NYTimes.com (New York Times), Metafilter (eine große BLOG-Website), YouTube und Baidu HI ... Und jetzt viele Websites im Internet sind nach wie vor so unvorbereitet, dass die Sicherheitsbranche CSRF als „schlafenden Riesen“ bezeichnet.

4. Das Prinzip von CSRF

Um einen CSRF-Angriff abzuschließen, muss das Opfer zwei Schritte nacheinander ausführen:

1. Melden Sie sich bei der vertrauenswürdigen Website A an und generieren Sie es lokal Cookies.

2. Greifen Sie auf die gefährliche Website B zu, ohne sich von A abzumelden.

Wenn Sie dies sehen, könnten Sie sagen: „Wenn ich eine der beiden oben genannten Bedingungen nicht erfülle, werde ich nicht von CSRF angegriffen.“ Ja, das stimmt, aber Sie können nicht garantieren, dass die folgenden Situationen nicht passieren:

1. Sie können nicht garantieren, dass Sie nach der Anmeldung auf einer Website keine Registerkarte mehr öffnen und eine andere Website besuchen.

2. Sie können nicht garantieren, dass Ihre lokalen Cookies nach dem Schließen des Browsers sofort ablaufen und Ihre letzte Sitzung beendet ist. (Tatsächlich kann das Schließen des Browsers eine Sitzung nicht beenden, aber die meisten Leute denken fälschlicherweise, dass das Schließen des Browsers dem Abmelden/Beenden der Sitzung gleichkommt ...)

　3. Was im Bild oben heißt Bei der angreifenden Website kann es sich um eine vertrauenswürdige und häufig besuchte Website handeln, die andere Schwachstellen aufweist.

Das Obige geht kurz auf die Idee von CSRF-Angriffen ein. Im Folgenden werde ich bestimmte CSRF-Angriffe im Detail erläutern. Hier nehme ich einen Banküberweisungsvorgang als Beispiel Bank-Websites sind nicht so dumm:>)

Beispiel 1:

Bank-Website A, die GET-Anfragen verwendet, um Banküberweisungsvorgänge abzuschließen, wie zum Beispiel: http://www.mybank.com /Transfer .php?toBankId=11&money=1000

Gefährliche Website B, die einen HTML-Code wie folgt enthält:

Zuerst melden Sie sich an Gehen Sie zur Bank-Website A und besuchen Sie dann die gefährliche Website B. Oh, dann werden Sie feststellen, dass auf Ihrem Bankkonto 1.000 Yuan fehlen ...

Warum ist das so? Der Grund dafür ist, dass die Website A der Bank gegen HTTP-Spezifikationen verstößt und GET-Anfragen zur Aktualisierung von Ressourcen verwendet. Bevor Sie auf die gefährliche Website B zugreifen, haben Sie sich auf der Website A der Bank angemeldet, und B verwendet GET, um Ressourcen von Drittanbietern anzufordern (der Dritte bezieht sich hier auf die Website der Bank). Ursprünglich war dies eine rechtliche Anfrage, aber hier haben Kriminelle sie ausgenutzt davon), sodass Ihr Browser das Cookie Ihrer Bank-Website A mitbringt, um eine Get-Anfrage zum Abrufen der Ressource „http://www.mybank.com/Transfer.php?toBankId=11&money=1000“ auszugeben. Als Ergebnis Nachdem der Website-Server der Bank die Anfrage erhalten hatte, dachte er, es handele sich um einen Ressourcenaktualisierungsvorgang (Übertragungsvorgang) und führte den Übertragungsvorgang sofort aus ...

　Beispiel 2:

In der Reihenfolge Um das oben genannte Problem zu verhindern, entschied sich die Bank, die POST-Anfrage zu verwenden, um den Überweisungsvorgang abzuschließen.

Das WEB-Formular der Bank-Website A lautet wie folgt:

    <form action="Transfer.php" method="POST">
　　　　<p>ToBankId: <input type="text" name="toBankId" /></p>
　　　　<p>Money: <input type="text" name="money" /></p>
　　　　<p><input type="submit" value="Transfer" /></p>
　　</form>

Die Hintergrundverarbeitungsseite Transfer.php lautet wie folgt:

    <?php
　　　　session_start();
　　　　if (isset($_REQUEST[&#39;toBankId&#39;] &&　isset($_REQUEST[&#39;money&#39;]))
　　　　{
　　　　    buy_stocks($_REQUEST[&#39;toBankId&#39;],　$_REQUEST[&#39;money&#39;]);
　　　　}
　　?>

Gefährliche Website B immer noch enthält nur den HTML-Satz Code:

　

　　和示例1中的操作一样，你首先登录了银行网站A，然后访问危险网站B，结果.....和示例1一样，你再次没了1000块～T_T，这次事故的原因是：银行后台使用了$_REQUEST去获取请求的数据，而$_REQUEST既可以获取GET请求的数据，也可以获取POST请求的数据，这就造成了在后台处理程序无法区分这到底是GET请求的数据还是POST请求的数据。在PHP中，可以使用$_GET和$_POST分别获取GET请求和POST请求的数据。在JAVA中，用于获取请求数据request一样存在不能区分GET请求数据和POST数据的问题。

　　示例3：

　　经过前面2个惨痛的教训，银行决定把获取请求数据的方法也改了，改用$_POST，只获取POST请求的数据，后台处理页面Transfer.php代码如下：

   <?php
　　　　session_start();
　　　　if (isset($_POST[&#39;toBankId&#39;] &&　isset($_POST[&#39;money&#39;]))
　　　　{
　　　　    buy_stocks($_POST[&#39;toBankId&#39;],　$_POST[&#39;money&#39;]);
　　　　}
　　?>

　　然而，危险网站B与时俱进，它改了一下代码：

<html>
　　<head>
　　　　<script type="text/javascript">
　　　　　　function steal()
　　　　　　{
          　　　　 iframe = document.frames["steal"];
　　     　　      iframe.document.Submit("transfer");
　　　　　　}
　　　　</script>
　　</head>
　　<body onload="steal()">
　　　　<iframe name="steal" display="none">
　　　　　　<form method="POST" name="transfer"　action="http://www.myBank.com/Transfer.php">
　　　　　　　　<input type="hidden" name="toBankId" value="11">
　　　　　　　　<input type="hidden" name="money" value="1000">
　　　　　　</form>
　　　　</iframe>
　　</body>
</html>

如果用户仍是继续上面的操作，很不幸，结果将会是再次不见1000块......因为这里危险网站B暗地里发送了POST请求到银行!

　　总结一下上面3个例子，CSRF主要的攻击模式基本上是以上的3种，其中以第1,2种最为严重，因为触发条件很简单，一个就可以了，而第3种比较麻烦，需要使用JavaScript，所以使用的机会会比前面的少很多，但无论是哪种情况，只要触发了CSRF攻击，后果都有可能很严重。

　　理解上面的3种攻击模式，其实可以看出，CSRF攻击是源于WEB的隐式身份验证机制！WEB的身份验证机制虽然可以保证一个请求是来自于某个用户的浏览器，但却无法保证该请求是用户批准发送的！

五.CSRF的防御

CSRF 的防范机制有很多种，防范的方法也根据 CSRF 攻击方式的不断升级而不断演化。常用的有检查 Refer 头部信息，使用一次性令牌，使用验证图片等手段。出于性能的考虑，如果每个请求都加入令牌验证将极大的增加服务器的负担，具体采用那种方法更合理，需要谨慎审视每种保护的优缺点。

1. 检查 HTTP 头部 Refer 信息，这是防止 CSRF 的最简单容易实现的一种手段。根据 RFC 对于 HTTP 协议里面 Refer 的定义，Refer 信息跟随出现在每个 Http 请求头部。Server 端在收到请求之后，可以去检查这个头信息，只接受来自本域的请求而忽略外部域的请求，这样就可以避免了很多风险。当然这种检查方式由于过于简单也有它自身的弱点：

a) 首先是检查 Refer 信息并不能防范来自本域的攻击。在企业业务网站上，经常会有同域的论坛，邮件等形式的 Web 应用程序存在，来自这些地方的 CSRF 攻击所携带的就是本域的 Refer 域信息，因此不能被这种防御手段所阻止。

b) 同样，某些直接发送 HTTP 请求的方式（指非浏览器，比如用后台代码等方法）可以伪造一些 Refer 信息，虽然直接进行头信息伪造的方式属于直接发送请求，很难跟随发送 cookie，但由于目前客户端手段层出不穷，flash，javascript 等大规模使用，从客户端进行 refer 的伪造，尤其是在客户端浏览器安装了越来越多的插件的情况下已经成为可能了。

2. 使用一次性令牌，这是当前 Web 应用程序的设计人员广泛使用的一种方式，方法是对于 Get 请求，在 URL 里面加入一个令牌，对于 Post 请求，在隐藏域中加入一个令牌。这个令牌由 server 端生成，由编程人员控制在客户端发送请求的时候使请求携带本令牌然后在 Server 端进行验证。但在令牌的设计上目前存在着几个错误的方案：

a) 使用和 Session 独立的令牌生成方式。这种令牌的值和 Session 无关，因此容易被其他用户伪造。这里的其他用户指的是当前 Web 应用程序的其他用户和活跃在网络传输阶段各个设置上的监听者，这种恶意用户可能使用自己的令牌来进行替换以便达到伪造的目的。

b) 完全使用 Session 认证信息作为令牌的生成方式。这种保护方式对于保护 CSRF 是起了作用的，但是可能会造成其他危害，具体来说，如果某些 URL 或者网页被拷贝下来与其他人共享，那么这些 URL 或者拷贝下来的网页中可能会含有用户的会话信息，这种信息一旦被恶意用户获得，就能造成极大的危害。

因此，一个正确的令牌设计应该是使用 Session 信息做 Hash，用得出的哈希值来做 CSRF 的令牌。

3. Verwenden Sie Verifizierungsbilder. Der Zweck dieser Methode besteht darin, Brute-Force-Angriffe durch Roboter zu verhindern. Allerdings gibt es im Hinblick auf die CSRF-Prävention auch einige Anwendungen mit relativ hohen Sicherheitsanforderungen, die Verifizierungsbilder und Einmal-Tokens für einen doppelten Schutz kombinieren. Da diese Bildüberprüfungsinformationen für Schadprogramme auf dem Client schwer zu identifizieren sind, können sie einen stärkeren Schutz bieten. Wenn sich der Browser des Clients möglicherweise bereits in einer unsicheren Umgebung befindet (z. B. wenn die Sicherheitsstufe des Clients auf eine niedrige Stufe eingestellt ist, im Browser des Clients unsichere Plug-Ins installiert sind usw.).

Die oben genannten sind nur einige der allgemeineren Methoden zur Verhinderung von CSRF. Webentwickler können die Sicherheitsniveauanforderungen basierend auf ihrem Verständnis der Funktionen ihrer Anwendungen bestimmen und sich für die Verwendung verschiedener Schutzmaßnahmen entscheiden Verwenden Sie eine Kombination von Schutzmethoden innerhalb derselben Anwendung.

Hinweis: Das Hinzufügen von Verteidigungsanlagen wirkt sich ebenfalls stark auf die Leistung aus, genau wie die Errichtung einer Mautstation auf der Autobahn. Es wird empfohlen, Verteidigungsanlagen nur bei wichtigen Vorgängen hinzuzufügen. Bitte überlegen Sie sorgfältig.