コーダーがセキュリティを征服する:共有して学ぶシリーズ-クロスサイトリクエストフォージェリ
Im Gegensatz zu Angriffen, die direkt auf Website- oder Anwendungsbetreiber abzielen, besteht das Ziel vieler Cross-Site Request Forgery (CSRF)-Angriffe darin, Geld, Waren oder Anmeldedaten direkt von einem Benutzer zu stehlen. Das bedeutet nicht, dass Website-Betreiber CSRF-Code-Schwachstellen ignorieren sollten, da der Ersatz der gestohlenen Gelder im Falle eines rein monetären Angriffs letztlich in der Verantwortung der Hosting-Site mit dem unsicheren Code liegen kann. Und wenn der angegriffene Benutzer stattdessen seine Anmeldedaten verliert oder sein Passwort unwissentlich ändert, kann ein Krimineller mit der gestohlenen Identität Schaden anrichten, insbesondere wenn das Opfer privilegierten Zugang hat.
CSRF-Angriffe sind ziemlich komplex und basieren auf mehreren Ebenen, um erfolgreich zu sein. Mit anderen Worten, es müssen viele Dinge zugunsten des Angreifers kaputt gehen, damit sie funktionieren. Trotzdem sind sie ein äußerst beliebter Angriffsvektor, da ein erfolgreicher Angriff einem Hacker direkt Geld überweisen oder ihn in die Lage versetzen kann, sich ungestraft auf einer Website zu bewegen. Wenn alles nach dem Willen des Hackers läuft, weiß der betroffene Benutzer möglicherweise nicht einmal, dass er Opfer eines Angriffs geworden ist.
Die gute Nachricht ist, dass, da so viel richtig laufen muss, damit ein CSRF-Angriff funktioniert, es eine ganze Reihe von großartigen Abwehrtechniken gibt, die sie in ihren Bahnen stoppen können.
Zu diesem Zweck werden wir drei Schlüsselaspekte von CSRF-Angriffen diskutieren:
- Wie sie funktionieren
- Warum sie so gefährlich sind
- Wie Sie Abwehrmaßnahmen ergreifen können, um sie kalt zu stoppen.
Wie funktionieren CSRF-Angriffe?
Da erfolgreiche CSRF-Angriffe die Möglichkeit haben, Geld, Waren oder Anmeldeinformationen von gezielten Benutzern direkt zu stehlen, sind sie trotz des hohen Aufwands, der für ihre Erstellung betrieben werden muss, sehr beliebt. Und weil sie oft auf verschiedenen Plattformen versucht werden, haben sie im Laufe der Jahre eine Vielzahl von Namen und Bezeichnungen erhalten. Sie hören vielleicht, dass CSRF-Angriffe als XSRF, Sea Surf, Session Riding, Cross-Site Reference Forgery oder Hostile Linking bezeichnet werden. Microsoft bezeichnet sie in den meisten seiner Dokumentationen gerne als One-Click-Attacken. Aber es sind alles CSRF-Attacken, und die Techniken, um sie abzuwehren, sind identisch.
Ein CSRF-Angriff kann passieren, wenn ein Benutzer auf einer Website angemeldet ist, um Geschäfte zu tätigen oder seine Arbeit zu erledigen. Der Schlüssel ist, dass der Benutzer angemeldet und aktiv bei einer Website oder Anwendung authentifiziert sein muss. Der Angriff wird normalerweise von einer sekundären Website oder einer E-Mail gestartet. Oftmals verwenden Angreifer Social-Engineering-Techniken, um Benutzer dazu zu verleiten, auf einen Link in einer E-Mail zu klicken, der sie auf eine kompromittierte Website mit dem Angriffsskript führt.
Die kompromittierte Website enthält ein Skript, das den aktiven Browser anweist, Befehle auszuführen, normalerweise etwas Bösartiges wie das Ändern des Kennworts eines Benutzers oder die Überweisung von Geld auf ein vom Angreifer kontrolliertes Konto. Solange der Benutzer authentifiziert ist, denkt die Website, dass die Befehle vom autorisierten Benutzer erteilt werden. Warum sollte sie auch nicht? Der Benutzer hat sich bereits authentifiziert und alle Passwörter angegeben, die für den Zugriff auf die Site erforderlich sind. Möglicherweise befindet er sich sogar innerhalb eines Geofence-Bereichs und sitzt ordnungsgemäß an seinem Büroterminal. Wenn er sein Passwort ändern oder Geld überweisen möchte, gibt es keinen Grund, nicht zu glauben, dass er es ist, der die Anfrage stellt.
Wenn man die Elemente des Angriffs aufschlüsselt, wird klar, warum es für den Angreifer so schwierig ist, diesen Angriff auszuführen. Zunächst einmal muss der Benutzer aktiv bei der Website, auf der der Angriff stattfindet, authentifiziert sein. Wenn eine E-Mail mit einem Angriffsskript eintrifft, nachdem ein Benutzer seine Browsersitzung beendet oder sich abgemeldet hat, schlägt der Angriff fehl.
Der Angreifer ist außerdem gezwungen, eine Menge Aufklärungsarbeit auf der anvisierten Website zu leisten, um zu wissen, welche Skripte diese Website akzeptiert. Angreifer können den Bildschirm des Opfers nicht sehen, und jede Rückmeldung von der Website geht an das Opfer, nicht an den Angreifer. Solange der Angreifer nicht in der Lage ist, Beweise dafür zu sehen, dass sein Angriff funktioniert, wie z. B. Geld, das plötzlich auf dem Konto des Opfers auftaucht, wird er nicht einmal sofort wissen, ob er erfolgreich war.
Unter den schwierigen, aber nicht unmöglichen Parametern, dass der Benutzer zum Zeitpunkt des Angriffs eingeloggt sein muss und dass er weiß, welche Skripte die angegriffene Website akzeptiert, kann der Code zur Ausführung eines CSRF-Angriffs extrem einfach sein, obwohl er je nach Website unterschiedlich ist.
Angenommen, eine Bank- oder Finanzanwendung verwendet GET-Anfragen, um Geld zu überweisen, etwa so:
GET http://bank.com/transferdo?acct=NancySmith12&amount=100 HTTP/1.1
Dieser Code würde eine Anfrage zur Überweisung von 100 $ an einen Benutzer namens NancySmith12 senden.
Wenn der anvisierte Benutzer jedoch eine E-Mail erhält, die vielleicht als von einem Kollegen stammend getarnt ist, könnte ein CSRF-Angriffsskript in die Klickaktion eingebettet werden:
<a href="http://bank.com/transfer.do?acct=ShadyLady15&amount=100000">Can you quickly read over this quarterly report?<a></a></a>
Wenn der anvisierte Benutzer auf den Social-Engineering-Link hereinfiel und ihn anklickte, während die Browsersitzung mit der Finanzanwendung noch geöffnet war, forderte sein Browser die Anwendung auf, 100.000 US-Dollar an das Konto von ShadyLady15 zu senden.
Das Skript könnte sogar in einem unsichtbaren Bild versteckt werden, das der Benutzer nicht sehen würde, das aber dennoch den Browser veranlassen könnte, die Anfrage zu stellen, etwa so:
<img src="http://bank.com/transfer.do?acct=ShadyLady15&amount=100000" width="0" height="0" border="0">
Das Ergebnis ist das gleiche. ShadyLady15 erhält 100.000 $, ohne dass jemand den Angriff entdeckt.
Warum ist CSRF so gefährlich?
CSRF-Angriffe sind heute aus dem gleichen Grund beliebt, aus dem Ransomware-Angriffe weiterhin die Runde machen. Es liegen nur wenige Schritte zwischen den Angreifern und dem Geld des Opfers. Bei einem Ransomware-Angriff werden Systeme verschlüsselt und die Benutzer werden um Geld für die Entschlüsselung der Daten erpresst. Bei einer CSRF-Attacke sind es sogar noch weniger Schritte. Wenn sie funktionieren, schicken die Opfer einfach Geld an die Angreifer, ohne es zu wissen.
Über direkte Angriffe auf das Geld eines Opfers oder die Finanzen eines Unternehmens hinaus können erfolgreiche CSRF-Angriffe dazu verwendet werden, ein Netzwerk mit gültigen Benutzern zu kompromittieren. Stellen Sie sich vor, ein Angreifer könnte mithilfe eines CSRF-Exploits das Passwort eines Administrators ändern. Er könnte dieses Passwort sofort verwenden, um Daten zu stehlen, Löcher in der Netzwerkverteidigung zu öffnen oder Backdoors zu installieren.
Obwohl es eine Menge Arbeit und bis zu einem gewissen Grad auch Glück ist, kann ein erfolgreicher CSRF-Angriff für Hacker wie ein Lottogewinn sein, unabhängig von ihrem eigentlichen Ziel. Bei einem Angriff auf ein Netzwerk würde fast jede andere Art von Angriff monatelange, niedrige und langsame Erkundung erfordern und versuchen, unter dem Radar des SIEM- und Cybersecurity-Personals zu bleiben. Im Gegensatz dazu kann ein einziger CSRF-Angriff einige Schritte entlang der Cyber-Kill-Chain überspringen und lässt sie sehr nah an ihrem ultimativen Ziel beginnen.
Wie kann ich CSRF-Attacken stoppen?
Anders als bei den meisten Schwachstellen liegt der Fehler bei CSRF-Angriffen nicht wirklich beim Code, sondern bei einem Exploit, den Angreifer erstellt haben, um einen Browser zu zwingen, Anfragen zu stellen, die ein Benutzer nicht will und von denen er möglicherweise nicht einmal weiß. Aber sie können besiegt werden.
Eine der besten Methoden besteht darin, dass die Entwickler ein CSRF-Token zur Identität eines Benutzers hinzufügen, wenn eine neue Sitzung erzeugt wird. Es sollte aus einer Zeichenfolge aus eindeutigen und zufälligen Zeichen bestehen und für den Benutzer unsichtbar sein. Als Nächstes fügen Sie die CSRF-Token-Anforderung als verstecktes Feld zu Formularen hinzu, die vom Server geprüft werden, sobald eine neue Anforderung übermittelt wird. Angreifer, die Anfragen über den Browser eines Benutzers übermitteln, werden nicht einmal von dem versteckten Token-Feld wissen, geschweige denn in der Lage sein, herauszufinden, was es ist, sodass alle ihre Anfragen fehlschlagen werden.
Eine noch einfachere Methode, die keinen großen Programmieraufwand erfordert, ist das Hinzufügen einer Captcha-Abfrage zu sensiblen Daten wie Passwortänderungsanfragen oder Überweisungsaufträgen. Sie kann so einfach sein wie die Aufforderung an einen Benutzer, auf eine Schaltfläche zu klicken, um zu bestätigen, dass der Antragsteller kein Roboter oder in diesem Fall ein CSRF-Skript ist. Angreifer sind nicht in der Lage, eine Antwort auf die Aufforderung zu skripten, und Benutzer, die plötzlich eine CAPTCHA-Aufforderung erhalten, ohne vorher etwas zu tun, z. B. eine Überweisungsanforderung zu stellen, wissen, dass etwas nicht stimmt. Alternativ kann ein Einmal-Passwort mit einem Token eines Drittanbieters, z. B. einem Smartphone, generiert werden, je nachdem, wie sehr ein Unternehmen die Arbeit im Namen der Sicherheit verlangsamen möchte.
Schließlich haben viele Browser wie Microsoft Edge oder Google Chrome, auch wenn sie nicht hundertprozentig sicher sind, Beschränkungen in der Same-Origin-Policy, um Anfragen von anderen als dem lokalen Benutzer zu blockieren. Wenn Sie Benutzer dazu zwingen, mit Ihrer Website über die aktuellsten Versionen dieser Browser zu interagieren, können Sie eine weitere Ebene der CSRF-Sicherheit einbauen, ohne die Entwicklungsteams zu belasten.
Die Tür für CSRF zuschlagen
Mit einem so hohen Auszahlungspotenzial werden CSRF-Angriffe wahrscheinlich nie ganz aussterben, aber wir hoffen, Sie haben gelernt, warum sie so hartnäckig sind und wie Sie sie für immer aus Ihrem Netzwerk blockieren können.
Für weitere Informationen können Sie einen Blick auf das OWASP Cross-Site Request Forgery Prevention Cheat Sheet werfen, das als lebendes Dokument dient, das diese Schwachstelle in ihrer Entwicklung aufzeichnet. Wenn Sie Ihr Sicherheitswissen wirklich erweitern möchten, können Sie lernen, wie Sie diese und viele andere Bedrohungen abwehren können, indem Sie den Secure Code Warrior Blog.
Glauben Sie, dass Sie bereit sind, Ihr neues Verteidigungswissen auf die Probe zu stellen? Spielen Sie noch heute mit der kostenlosen Demo der Plattform Secure Code Warrior herum.
CSRF 攻撃はかなり複雑で、成功するには複数のレイヤーが必要です。言い換えると、攻撃者に有利に働かせるためには、多くのことを突破しなければならないということです。それにもかかわらず、これらは非常に人気があり、収益性の高い攻撃ベクトルです。
Jaap Karan Singhは、セキュア・コーディング・エバンジェリストであり、チーフ・シンであり、セキュア・コード・ウォリアーの共同創設者です。
Secure Code Warrior schützt Ihren Code während des gesamten Softwareentwicklungszyklus und hilft Ihnen dabei, eine Kultur zu schaffen, in der Cybersicherheit oberste Priorität hat. Ganz gleich, ob Sie Anwendungs-Sicherheitsmanager, Entwickler, CISO oder Sicherheitsbeauftragter sind – wir helfen Ihnen dabei, die mit unsicherem Code verbundenen Risiken zu minimieren.
デモを予約
Jaap Karan Singhは、セキュア・コーディング・エバンジェリストであり、チーフ・シンであり、セキュア・コード・ウォリアーの共同創設者です。
Im Gegensatz zu Angriffen, die direkt auf Website- oder Anwendungsbetreiber abzielen, besteht das Ziel vieler Cross-Site Request Forgery (CSRF)-Angriffe darin, Geld, Waren oder Anmeldedaten direkt von einem Benutzer zu stehlen. Das bedeutet nicht, dass Website-Betreiber CSRF-Code-Schwachstellen ignorieren sollten, da der Ersatz der gestohlenen Gelder im Falle eines rein monetären Angriffs letztlich in der Verantwortung der Hosting-Site mit dem unsicheren Code liegen kann. Und wenn der angegriffene Benutzer stattdessen seine Anmeldedaten verliert oder sein Passwort unwissentlich ändert, kann ein Krimineller mit der gestohlenen Identität Schaden anrichten, insbesondere wenn das Opfer privilegierten Zugang hat.
CSRF-Angriffe sind ziemlich komplex und basieren auf mehreren Ebenen, um erfolgreich zu sein. Mit anderen Worten, es müssen viele Dinge zugunsten des Angreifers kaputt gehen, damit sie funktionieren. Trotzdem sind sie ein äußerst beliebter Angriffsvektor, da ein erfolgreicher Angriff einem Hacker direkt Geld überweisen oder ihn in die Lage versetzen kann, sich ungestraft auf einer Website zu bewegen. Wenn alles nach dem Willen des Hackers läuft, weiß der betroffene Benutzer möglicherweise nicht einmal, dass er Opfer eines Angriffs geworden ist.
Die gute Nachricht ist, dass, da so viel richtig laufen muss, damit ein CSRF-Angriff funktioniert, es eine ganze Reihe von großartigen Abwehrtechniken gibt, die sie in ihren Bahnen stoppen können.
Zu diesem Zweck werden wir drei Schlüsselaspekte von CSRF-Angriffen diskutieren:
- Wie sie funktionieren
- Warum sie so gefährlich sind
- Wie Sie Abwehrmaßnahmen ergreifen können, um sie kalt zu stoppen.
Wie funktionieren CSRF-Angriffe?
Da erfolgreiche CSRF-Angriffe die Möglichkeit haben, Geld, Waren oder Anmeldeinformationen von gezielten Benutzern direkt zu stehlen, sind sie trotz des hohen Aufwands, der für ihre Erstellung betrieben werden muss, sehr beliebt. Und weil sie oft auf verschiedenen Plattformen versucht werden, haben sie im Laufe der Jahre eine Vielzahl von Namen und Bezeichnungen erhalten. Sie hören vielleicht, dass CSRF-Angriffe als XSRF, Sea Surf, Session Riding, Cross-Site Reference Forgery oder Hostile Linking bezeichnet werden. Microsoft bezeichnet sie in den meisten seiner Dokumentationen gerne als One-Click-Attacken. Aber es sind alles CSRF-Attacken, und die Techniken, um sie abzuwehren, sind identisch.
Ein CSRF-Angriff kann passieren, wenn ein Benutzer auf einer Website angemeldet ist, um Geschäfte zu tätigen oder seine Arbeit zu erledigen. Der Schlüssel ist, dass der Benutzer angemeldet und aktiv bei einer Website oder Anwendung authentifiziert sein muss. Der Angriff wird normalerweise von einer sekundären Website oder einer E-Mail gestartet. Oftmals verwenden Angreifer Social-Engineering-Techniken, um Benutzer dazu zu verleiten, auf einen Link in einer E-Mail zu klicken, der sie auf eine kompromittierte Website mit dem Angriffsskript führt.
Die kompromittierte Website enthält ein Skript, das den aktiven Browser anweist, Befehle auszuführen, normalerweise etwas Bösartiges wie das Ändern des Kennworts eines Benutzers oder die Überweisung von Geld auf ein vom Angreifer kontrolliertes Konto. Solange der Benutzer authentifiziert ist, denkt die Website, dass die Befehle vom autorisierten Benutzer erteilt werden. Warum sollte sie auch nicht? Der Benutzer hat sich bereits authentifiziert und alle Passwörter angegeben, die für den Zugriff auf die Site erforderlich sind. Möglicherweise befindet er sich sogar innerhalb eines Geofence-Bereichs und sitzt ordnungsgemäß an seinem Büroterminal. Wenn er sein Passwort ändern oder Geld überweisen möchte, gibt es keinen Grund, nicht zu glauben, dass er es ist, der die Anfrage stellt.
Wenn man die Elemente des Angriffs aufschlüsselt, wird klar, warum es für den Angreifer so schwierig ist, diesen Angriff auszuführen. Zunächst einmal muss der Benutzer aktiv bei der Website, auf der der Angriff stattfindet, authentifiziert sein. Wenn eine E-Mail mit einem Angriffsskript eintrifft, nachdem ein Benutzer seine Browsersitzung beendet oder sich abgemeldet hat, schlägt der Angriff fehl.
Der Angreifer ist außerdem gezwungen, eine Menge Aufklärungsarbeit auf der anvisierten Website zu leisten, um zu wissen, welche Skripte diese Website akzeptiert. Angreifer können den Bildschirm des Opfers nicht sehen, und jede Rückmeldung von der Website geht an das Opfer, nicht an den Angreifer. Solange der Angreifer nicht in der Lage ist, Beweise dafür zu sehen, dass sein Angriff funktioniert, wie z. B. Geld, das plötzlich auf dem Konto des Opfers auftaucht, wird er nicht einmal sofort wissen, ob er erfolgreich war.
Unter den schwierigen, aber nicht unmöglichen Parametern, dass der Benutzer zum Zeitpunkt des Angriffs eingeloggt sein muss und dass er weiß, welche Skripte die angegriffene Website akzeptiert, kann der Code zur Ausführung eines CSRF-Angriffs extrem einfach sein, obwohl er je nach Website unterschiedlich ist.
Angenommen, eine Bank- oder Finanzanwendung verwendet GET-Anfragen, um Geld zu überweisen, etwa so:
GET http://bank.com/transferdo?acct=NancySmith12&amount=100 HTTP/1.1
Dieser Code würde eine Anfrage zur Überweisung von 100 $ an einen Benutzer namens NancySmith12 senden.
Wenn der anvisierte Benutzer jedoch eine E-Mail erhält, die vielleicht als von einem Kollegen stammend getarnt ist, könnte ein CSRF-Angriffsskript in die Klickaktion eingebettet werden:
<a href="http://bank.com/transfer.do?acct=ShadyLady15&amount=100000">Can you quickly read over this quarterly report?<a></a></a>
Wenn der anvisierte Benutzer auf den Social-Engineering-Link hereinfiel und ihn anklickte, während die Browsersitzung mit der Finanzanwendung noch geöffnet war, forderte sein Browser die Anwendung auf, 100.000 US-Dollar an das Konto von ShadyLady15 zu senden.
Das Skript könnte sogar in einem unsichtbaren Bild versteckt werden, das der Benutzer nicht sehen würde, das aber dennoch den Browser veranlassen könnte, die Anfrage zu stellen, etwa so:
<img src="http://bank.com/transfer.do?acct=ShadyLady15&amount=100000" width="0" height="0" border="0">
Das Ergebnis ist das gleiche. ShadyLady15 erhält 100.000 $, ohne dass jemand den Angriff entdeckt.
Warum ist CSRF so gefährlich?
CSRF-Angriffe sind heute aus dem gleichen Grund beliebt, aus dem Ransomware-Angriffe weiterhin die Runde machen. Es liegen nur wenige Schritte zwischen den Angreifern und dem Geld des Opfers. Bei einem Ransomware-Angriff werden Systeme verschlüsselt und die Benutzer werden um Geld für die Entschlüsselung der Daten erpresst. Bei einer CSRF-Attacke sind es sogar noch weniger Schritte. Wenn sie funktionieren, schicken die Opfer einfach Geld an die Angreifer, ohne es zu wissen.
Über direkte Angriffe auf das Geld eines Opfers oder die Finanzen eines Unternehmens hinaus können erfolgreiche CSRF-Angriffe dazu verwendet werden, ein Netzwerk mit gültigen Benutzern zu kompromittieren. Stellen Sie sich vor, ein Angreifer könnte mithilfe eines CSRF-Exploits das Passwort eines Administrators ändern. Er könnte dieses Passwort sofort verwenden, um Daten zu stehlen, Löcher in der Netzwerkverteidigung zu öffnen oder Backdoors zu installieren.
Obwohl es eine Menge Arbeit und bis zu einem gewissen Grad auch Glück ist, kann ein erfolgreicher CSRF-Angriff für Hacker wie ein Lottogewinn sein, unabhängig von ihrem eigentlichen Ziel. Bei einem Angriff auf ein Netzwerk würde fast jede andere Art von Angriff monatelange, niedrige und langsame Erkundung erfordern und versuchen, unter dem Radar des SIEM- und Cybersecurity-Personals zu bleiben. Im Gegensatz dazu kann ein einziger CSRF-Angriff einige Schritte entlang der Cyber-Kill-Chain überspringen und lässt sie sehr nah an ihrem ultimativen Ziel beginnen.
Wie kann ich CSRF-Attacken stoppen?
Anders als bei den meisten Schwachstellen liegt der Fehler bei CSRF-Angriffen nicht wirklich beim Code, sondern bei einem Exploit, den Angreifer erstellt haben, um einen Browser zu zwingen, Anfragen zu stellen, die ein Benutzer nicht will und von denen er möglicherweise nicht einmal weiß. Aber sie können besiegt werden.
Eine der besten Methoden besteht darin, dass die Entwickler ein CSRF-Token zur Identität eines Benutzers hinzufügen, wenn eine neue Sitzung erzeugt wird. Es sollte aus einer Zeichenfolge aus eindeutigen und zufälligen Zeichen bestehen und für den Benutzer unsichtbar sein. Als Nächstes fügen Sie die CSRF-Token-Anforderung als verstecktes Feld zu Formularen hinzu, die vom Server geprüft werden, sobald eine neue Anforderung übermittelt wird. Angreifer, die Anfragen über den Browser eines Benutzers übermitteln, werden nicht einmal von dem versteckten Token-Feld wissen, geschweige denn in der Lage sein, herauszufinden, was es ist, sodass alle ihre Anfragen fehlschlagen werden.
Eine noch einfachere Methode, die keinen großen Programmieraufwand erfordert, ist das Hinzufügen einer Captcha-Abfrage zu sensiblen Daten wie Passwortänderungsanfragen oder Überweisungsaufträgen. Sie kann so einfach sein wie die Aufforderung an einen Benutzer, auf eine Schaltfläche zu klicken, um zu bestätigen, dass der Antragsteller kein Roboter oder in diesem Fall ein CSRF-Skript ist. Angreifer sind nicht in der Lage, eine Antwort auf die Aufforderung zu skripten, und Benutzer, die plötzlich eine CAPTCHA-Aufforderung erhalten, ohne vorher etwas zu tun, z. B. eine Überweisungsanforderung zu stellen, wissen, dass etwas nicht stimmt. Alternativ kann ein Einmal-Passwort mit einem Token eines Drittanbieters, z. B. einem Smartphone, generiert werden, je nachdem, wie sehr ein Unternehmen die Arbeit im Namen der Sicherheit verlangsamen möchte.
Schließlich haben viele Browser wie Microsoft Edge oder Google Chrome, auch wenn sie nicht hundertprozentig sicher sind, Beschränkungen in der Same-Origin-Policy, um Anfragen von anderen als dem lokalen Benutzer zu blockieren. Wenn Sie Benutzer dazu zwingen, mit Ihrer Website über die aktuellsten Versionen dieser Browser zu interagieren, können Sie eine weitere Ebene der CSRF-Sicherheit einbauen, ohne die Entwicklungsteams zu belasten.
Die Tür für CSRF zuschlagen
Mit einem so hohen Auszahlungspotenzial werden CSRF-Angriffe wahrscheinlich nie ganz aussterben, aber wir hoffen, Sie haben gelernt, warum sie so hartnäckig sind und wie Sie sie für immer aus Ihrem Netzwerk blockieren können.
Für weitere Informationen können Sie einen Blick auf das OWASP Cross-Site Request Forgery Prevention Cheat Sheet werfen, das als lebendes Dokument dient, das diese Schwachstelle in ihrer Entwicklung aufzeichnet. Wenn Sie Ihr Sicherheitswissen wirklich erweitern möchten, können Sie lernen, wie Sie diese und viele andere Bedrohungen abwehren können, indem Sie den Secure Code Warrior Blog.
Glauben Sie, dass Sie bereit sind, Ihr neues Verteidigungswissen auf die Probe zu stellen? Spielen Sie noch heute mit der kostenlosen Demo der Plattform Secure Code Warrior herum.
Im Gegensatz zu Angriffen, die direkt auf Website- oder Anwendungsbetreiber abzielen, besteht das Ziel vieler Cross-Site Request Forgery (CSRF)-Angriffe darin, Geld, Waren oder Anmeldedaten direkt von einem Benutzer zu stehlen. Das bedeutet nicht, dass Website-Betreiber CSRF-Code-Schwachstellen ignorieren sollten, da der Ersatz der gestohlenen Gelder im Falle eines rein monetären Angriffs letztlich in der Verantwortung der Hosting-Site mit dem unsicheren Code liegen kann. Und wenn der angegriffene Benutzer stattdessen seine Anmeldedaten verliert oder sein Passwort unwissentlich ändert, kann ein Krimineller mit der gestohlenen Identität Schaden anrichten, insbesondere wenn das Opfer privilegierten Zugang hat.
CSRF-Angriffe sind ziemlich komplex und basieren auf mehreren Ebenen, um erfolgreich zu sein. Mit anderen Worten, es müssen viele Dinge zugunsten des Angreifers kaputt gehen, damit sie funktionieren. Trotzdem sind sie ein äußerst beliebter Angriffsvektor, da ein erfolgreicher Angriff einem Hacker direkt Geld überweisen oder ihn in die Lage versetzen kann, sich ungestraft auf einer Website zu bewegen. Wenn alles nach dem Willen des Hackers läuft, weiß der betroffene Benutzer möglicherweise nicht einmal, dass er Opfer eines Angriffs geworden ist.
Die gute Nachricht ist, dass, da so viel richtig laufen muss, damit ein CSRF-Angriff funktioniert, es eine ganze Reihe von großartigen Abwehrtechniken gibt, die sie in ihren Bahnen stoppen können.
Zu diesem Zweck werden wir drei Schlüsselaspekte von CSRF-Angriffen diskutieren:
- Wie sie funktionieren
- Warum sie so gefährlich sind
- Wie Sie Abwehrmaßnahmen ergreifen können, um sie kalt zu stoppen.
Wie funktionieren CSRF-Angriffe?
Da erfolgreiche CSRF-Angriffe die Möglichkeit haben, Geld, Waren oder Anmeldeinformationen von gezielten Benutzern direkt zu stehlen, sind sie trotz des hohen Aufwands, der für ihre Erstellung betrieben werden muss, sehr beliebt. Und weil sie oft auf verschiedenen Plattformen versucht werden, haben sie im Laufe der Jahre eine Vielzahl von Namen und Bezeichnungen erhalten. Sie hören vielleicht, dass CSRF-Angriffe als XSRF, Sea Surf, Session Riding, Cross-Site Reference Forgery oder Hostile Linking bezeichnet werden. Microsoft bezeichnet sie in den meisten seiner Dokumentationen gerne als One-Click-Attacken. Aber es sind alles CSRF-Attacken, und die Techniken, um sie abzuwehren, sind identisch.
Ein CSRF-Angriff kann passieren, wenn ein Benutzer auf einer Website angemeldet ist, um Geschäfte zu tätigen oder seine Arbeit zu erledigen. Der Schlüssel ist, dass der Benutzer angemeldet und aktiv bei einer Website oder Anwendung authentifiziert sein muss. Der Angriff wird normalerweise von einer sekundären Website oder einer E-Mail gestartet. Oftmals verwenden Angreifer Social-Engineering-Techniken, um Benutzer dazu zu verleiten, auf einen Link in einer E-Mail zu klicken, der sie auf eine kompromittierte Website mit dem Angriffsskript führt.
Die kompromittierte Website enthält ein Skript, das den aktiven Browser anweist, Befehle auszuführen, normalerweise etwas Bösartiges wie das Ändern des Kennworts eines Benutzers oder die Überweisung von Geld auf ein vom Angreifer kontrolliertes Konto. Solange der Benutzer authentifiziert ist, denkt die Website, dass die Befehle vom autorisierten Benutzer erteilt werden. Warum sollte sie auch nicht? Der Benutzer hat sich bereits authentifiziert und alle Passwörter angegeben, die für den Zugriff auf die Site erforderlich sind. Möglicherweise befindet er sich sogar innerhalb eines Geofence-Bereichs und sitzt ordnungsgemäß an seinem Büroterminal. Wenn er sein Passwort ändern oder Geld überweisen möchte, gibt es keinen Grund, nicht zu glauben, dass er es ist, der die Anfrage stellt.
Wenn man die Elemente des Angriffs aufschlüsselt, wird klar, warum es für den Angreifer so schwierig ist, diesen Angriff auszuführen. Zunächst einmal muss der Benutzer aktiv bei der Website, auf der der Angriff stattfindet, authentifiziert sein. Wenn eine E-Mail mit einem Angriffsskript eintrifft, nachdem ein Benutzer seine Browsersitzung beendet oder sich abgemeldet hat, schlägt der Angriff fehl.
Der Angreifer ist außerdem gezwungen, eine Menge Aufklärungsarbeit auf der anvisierten Website zu leisten, um zu wissen, welche Skripte diese Website akzeptiert. Angreifer können den Bildschirm des Opfers nicht sehen, und jede Rückmeldung von der Website geht an das Opfer, nicht an den Angreifer. Solange der Angreifer nicht in der Lage ist, Beweise dafür zu sehen, dass sein Angriff funktioniert, wie z. B. Geld, das plötzlich auf dem Konto des Opfers auftaucht, wird er nicht einmal sofort wissen, ob er erfolgreich war.
Unter den schwierigen, aber nicht unmöglichen Parametern, dass der Benutzer zum Zeitpunkt des Angriffs eingeloggt sein muss und dass er weiß, welche Skripte die angegriffene Website akzeptiert, kann der Code zur Ausführung eines CSRF-Angriffs extrem einfach sein, obwohl er je nach Website unterschiedlich ist.
Angenommen, eine Bank- oder Finanzanwendung verwendet GET-Anfragen, um Geld zu überweisen, etwa so:
GET http://bank.com/transferdo?acct=NancySmith12&amount=100 HTTP/1.1
Dieser Code würde eine Anfrage zur Überweisung von 100 $ an einen Benutzer namens NancySmith12 senden.
Wenn der anvisierte Benutzer jedoch eine E-Mail erhält, die vielleicht als von einem Kollegen stammend getarnt ist, könnte ein CSRF-Angriffsskript in die Klickaktion eingebettet werden:
<a href="http://bank.com/transfer.do?acct=ShadyLady15&amount=100000">Can you quickly read over this quarterly report?<a></a></a>
Wenn der anvisierte Benutzer auf den Social-Engineering-Link hereinfiel und ihn anklickte, während die Browsersitzung mit der Finanzanwendung noch geöffnet war, forderte sein Browser die Anwendung auf, 100.000 US-Dollar an das Konto von ShadyLady15 zu senden.
Das Skript könnte sogar in einem unsichtbaren Bild versteckt werden, das der Benutzer nicht sehen würde, das aber dennoch den Browser veranlassen könnte, die Anfrage zu stellen, etwa so:
<img src="http://bank.com/transfer.do?acct=ShadyLady15&amount=100000" width="0" height="0" border="0">
Das Ergebnis ist das gleiche. ShadyLady15 erhält 100.000 $, ohne dass jemand den Angriff entdeckt.
Warum ist CSRF so gefährlich?
CSRF-Angriffe sind heute aus dem gleichen Grund beliebt, aus dem Ransomware-Angriffe weiterhin die Runde machen. Es liegen nur wenige Schritte zwischen den Angreifern und dem Geld des Opfers. Bei einem Ransomware-Angriff werden Systeme verschlüsselt und die Benutzer werden um Geld für die Entschlüsselung der Daten erpresst. Bei einer CSRF-Attacke sind es sogar noch weniger Schritte. Wenn sie funktionieren, schicken die Opfer einfach Geld an die Angreifer, ohne es zu wissen.
Über direkte Angriffe auf das Geld eines Opfers oder die Finanzen eines Unternehmens hinaus können erfolgreiche CSRF-Angriffe dazu verwendet werden, ein Netzwerk mit gültigen Benutzern zu kompromittieren. Stellen Sie sich vor, ein Angreifer könnte mithilfe eines CSRF-Exploits das Passwort eines Administrators ändern. Er könnte dieses Passwort sofort verwenden, um Daten zu stehlen, Löcher in der Netzwerkverteidigung zu öffnen oder Backdoors zu installieren.
Obwohl es eine Menge Arbeit und bis zu einem gewissen Grad auch Glück ist, kann ein erfolgreicher CSRF-Angriff für Hacker wie ein Lottogewinn sein, unabhängig von ihrem eigentlichen Ziel. Bei einem Angriff auf ein Netzwerk würde fast jede andere Art von Angriff monatelange, niedrige und langsame Erkundung erfordern und versuchen, unter dem Radar des SIEM- und Cybersecurity-Personals zu bleiben. Im Gegensatz dazu kann ein einziger CSRF-Angriff einige Schritte entlang der Cyber-Kill-Chain überspringen und lässt sie sehr nah an ihrem ultimativen Ziel beginnen.
Wie kann ich CSRF-Attacken stoppen?
Anders als bei den meisten Schwachstellen liegt der Fehler bei CSRF-Angriffen nicht wirklich beim Code, sondern bei einem Exploit, den Angreifer erstellt haben, um einen Browser zu zwingen, Anfragen zu stellen, die ein Benutzer nicht will und von denen er möglicherweise nicht einmal weiß. Aber sie können besiegt werden.
Eine der besten Methoden besteht darin, dass die Entwickler ein CSRF-Token zur Identität eines Benutzers hinzufügen, wenn eine neue Sitzung erzeugt wird. Es sollte aus einer Zeichenfolge aus eindeutigen und zufälligen Zeichen bestehen und für den Benutzer unsichtbar sein. Als Nächstes fügen Sie die CSRF-Token-Anforderung als verstecktes Feld zu Formularen hinzu, die vom Server geprüft werden, sobald eine neue Anforderung übermittelt wird. Angreifer, die Anfragen über den Browser eines Benutzers übermitteln, werden nicht einmal von dem versteckten Token-Feld wissen, geschweige denn in der Lage sein, herauszufinden, was es ist, sodass alle ihre Anfragen fehlschlagen werden.
Eine noch einfachere Methode, die keinen großen Programmieraufwand erfordert, ist das Hinzufügen einer Captcha-Abfrage zu sensiblen Daten wie Passwortänderungsanfragen oder Überweisungsaufträgen. Sie kann so einfach sein wie die Aufforderung an einen Benutzer, auf eine Schaltfläche zu klicken, um zu bestätigen, dass der Antragsteller kein Roboter oder in diesem Fall ein CSRF-Skript ist. Angreifer sind nicht in der Lage, eine Antwort auf die Aufforderung zu skripten, und Benutzer, die plötzlich eine CAPTCHA-Aufforderung erhalten, ohne vorher etwas zu tun, z. B. eine Überweisungsanforderung zu stellen, wissen, dass etwas nicht stimmt. Alternativ kann ein Einmal-Passwort mit einem Token eines Drittanbieters, z. B. einem Smartphone, generiert werden, je nachdem, wie sehr ein Unternehmen die Arbeit im Namen der Sicherheit verlangsamen möchte.
Schließlich haben viele Browser wie Microsoft Edge oder Google Chrome, auch wenn sie nicht hundertprozentig sicher sind, Beschränkungen in der Same-Origin-Policy, um Anfragen von anderen als dem lokalen Benutzer zu blockieren. Wenn Sie Benutzer dazu zwingen, mit Ihrer Website über die aktuellsten Versionen dieser Browser zu interagieren, können Sie eine weitere Ebene der CSRF-Sicherheit einbauen, ohne die Entwicklungsteams zu belasten.
Die Tür für CSRF zuschlagen
Mit einem so hohen Auszahlungspotenzial werden CSRF-Angriffe wahrscheinlich nie ganz aussterben, aber wir hoffen, Sie haben gelernt, warum sie so hartnäckig sind und wie Sie sie für immer aus Ihrem Netzwerk blockieren können.
Für weitere Informationen können Sie einen Blick auf das OWASP Cross-Site Request Forgery Prevention Cheat Sheet werfen, das als lebendes Dokument dient, das diese Schwachstelle in ihrer Entwicklung aufzeichnet. Wenn Sie Ihr Sicherheitswissen wirklich erweitern möchten, können Sie lernen, wie Sie diese und viele andere Bedrohungen abwehren können, indem Sie den Secure Code Warrior Blog.
Glauben Sie, dass Sie bereit sind, Ihr neues Verteidigungswissen auf die Probe zu stellen? Spielen Sie noch heute mit der kostenlosen Demo der Plattform Secure Code Warrior herum.
Klicken Sie auf den folgenden Link, um die PDF-Datei dieser Ressource herunterzuladen.
Secure Code Warrior schützt Ihren Code während des gesamten Softwareentwicklungszyklus und hilft Ihnen dabei, eine Kultur zu schaffen, in der Cybersicherheit oberste Priorität hat. Ganz gleich, ob Sie Anwendungs-Sicherheitsmanager, Entwickler, CISO oder Sicherheitsbeauftragter sind – wir helfen Ihnen dabei, die mit unsicherem Code verbundenen Risiken zu minimieren.
Bericht anzeigenデモを予約
Jaap Karan Singhは、セキュア・コーディング・エバンジェリストであり、チーフ・シンであり、セキュア・コード・ウォリアーの共同創設者です。
Im Gegensatz zu Angriffen, die direkt auf Website- oder Anwendungsbetreiber abzielen, besteht das Ziel vieler Cross-Site Request Forgery (CSRF)-Angriffe darin, Geld, Waren oder Anmeldedaten direkt von einem Benutzer zu stehlen. Das bedeutet nicht, dass Website-Betreiber CSRF-Code-Schwachstellen ignorieren sollten, da der Ersatz der gestohlenen Gelder im Falle eines rein monetären Angriffs letztlich in der Verantwortung der Hosting-Site mit dem unsicheren Code liegen kann. Und wenn der angegriffene Benutzer stattdessen seine Anmeldedaten verliert oder sein Passwort unwissentlich ändert, kann ein Krimineller mit der gestohlenen Identität Schaden anrichten, insbesondere wenn das Opfer privilegierten Zugang hat.
CSRF-Angriffe sind ziemlich komplex und basieren auf mehreren Ebenen, um erfolgreich zu sein. Mit anderen Worten, es müssen viele Dinge zugunsten des Angreifers kaputt gehen, damit sie funktionieren. Trotzdem sind sie ein äußerst beliebter Angriffsvektor, da ein erfolgreicher Angriff einem Hacker direkt Geld überweisen oder ihn in die Lage versetzen kann, sich ungestraft auf einer Website zu bewegen. Wenn alles nach dem Willen des Hackers läuft, weiß der betroffene Benutzer möglicherweise nicht einmal, dass er Opfer eines Angriffs geworden ist.
Die gute Nachricht ist, dass, da so viel richtig laufen muss, damit ein CSRF-Angriff funktioniert, es eine ganze Reihe von großartigen Abwehrtechniken gibt, die sie in ihren Bahnen stoppen können.
Zu diesem Zweck werden wir drei Schlüsselaspekte von CSRF-Angriffen diskutieren:
- Wie sie funktionieren
- Warum sie so gefährlich sind
- Wie Sie Abwehrmaßnahmen ergreifen können, um sie kalt zu stoppen.
Wie funktionieren CSRF-Angriffe?
Da erfolgreiche CSRF-Angriffe die Möglichkeit haben, Geld, Waren oder Anmeldeinformationen von gezielten Benutzern direkt zu stehlen, sind sie trotz des hohen Aufwands, der für ihre Erstellung betrieben werden muss, sehr beliebt. Und weil sie oft auf verschiedenen Plattformen versucht werden, haben sie im Laufe der Jahre eine Vielzahl von Namen und Bezeichnungen erhalten. Sie hören vielleicht, dass CSRF-Angriffe als XSRF, Sea Surf, Session Riding, Cross-Site Reference Forgery oder Hostile Linking bezeichnet werden. Microsoft bezeichnet sie in den meisten seiner Dokumentationen gerne als One-Click-Attacken. Aber es sind alles CSRF-Attacken, und die Techniken, um sie abzuwehren, sind identisch.
Ein CSRF-Angriff kann passieren, wenn ein Benutzer auf einer Website angemeldet ist, um Geschäfte zu tätigen oder seine Arbeit zu erledigen. Der Schlüssel ist, dass der Benutzer angemeldet und aktiv bei einer Website oder Anwendung authentifiziert sein muss. Der Angriff wird normalerweise von einer sekundären Website oder einer E-Mail gestartet. Oftmals verwenden Angreifer Social-Engineering-Techniken, um Benutzer dazu zu verleiten, auf einen Link in einer E-Mail zu klicken, der sie auf eine kompromittierte Website mit dem Angriffsskript führt.
Die kompromittierte Website enthält ein Skript, das den aktiven Browser anweist, Befehle auszuführen, normalerweise etwas Bösartiges wie das Ändern des Kennworts eines Benutzers oder die Überweisung von Geld auf ein vom Angreifer kontrolliertes Konto. Solange der Benutzer authentifiziert ist, denkt die Website, dass die Befehle vom autorisierten Benutzer erteilt werden. Warum sollte sie auch nicht? Der Benutzer hat sich bereits authentifiziert und alle Passwörter angegeben, die für den Zugriff auf die Site erforderlich sind. Möglicherweise befindet er sich sogar innerhalb eines Geofence-Bereichs und sitzt ordnungsgemäß an seinem Büroterminal. Wenn er sein Passwort ändern oder Geld überweisen möchte, gibt es keinen Grund, nicht zu glauben, dass er es ist, der die Anfrage stellt.
Wenn man die Elemente des Angriffs aufschlüsselt, wird klar, warum es für den Angreifer so schwierig ist, diesen Angriff auszuführen. Zunächst einmal muss der Benutzer aktiv bei der Website, auf der der Angriff stattfindet, authentifiziert sein. Wenn eine E-Mail mit einem Angriffsskript eintrifft, nachdem ein Benutzer seine Browsersitzung beendet oder sich abgemeldet hat, schlägt der Angriff fehl.
Der Angreifer ist außerdem gezwungen, eine Menge Aufklärungsarbeit auf der anvisierten Website zu leisten, um zu wissen, welche Skripte diese Website akzeptiert. Angreifer können den Bildschirm des Opfers nicht sehen, und jede Rückmeldung von der Website geht an das Opfer, nicht an den Angreifer. Solange der Angreifer nicht in der Lage ist, Beweise dafür zu sehen, dass sein Angriff funktioniert, wie z. B. Geld, das plötzlich auf dem Konto des Opfers auftaucht, wird er nicht einmal sofort wissen, ob er erfolgreich war.
Unter den schwierigen, aber nicht unmöglichen Parametern, dass der Benutzer zum Zeitpunkt des Angriffs eingeloggt sein muss und dass er weiß, welche Skripte die angegriffene Website akzeptiert, kann der Code zur Ausführung eines CSRF-Angriffs extrem einfach sein, obwohl er je nach Website unterschiedlich ist.
Angenommen, eine Bank- oder Finanzanwendung verwendet GET-Anfragen, um Geld zu überweisen, etwa so:
GET http://bank.com/transferdo?acct=NancySmith12&amount=100 HTTP/1.1
Dieser Code würde eine Anfrage zur Überweisung von 100 $ an einen Benutzer namens NancySmith12 senden.
Wenn der anvisierte Benutzer jedoch eine E-Mail erhält, die vielleicht als von einem Kollegen stammend getarnt ist, könnte ein CSRF-Angriffsskript in die Klickaktion eingebettet werden:
<a href="http://bank.com/transfer.do?acct=ShadyLady15&amount=100000">Can you quickly read over this quarterly report?<a></a></a>
Wenn der anvisierte Benutzer auf den Social-Engineering-Link hereinfiel und ihn anklickte, während die Browsersitzung mit der Finanzanwendung noch geöffnet war, forderte sein Browser die Anwendung auf, 100.000 US-Dollar an das Konto von ShadyLady15 zu senden.
Das Skript könnte sogar in einem unsichtbaren Bild versteckt werden, das der Benutzer nicht sehen würde, das aber dennoch den Browser veranlassen könnte, die Anfrage zu stellen, etwa so:
<img src="http://bank.com/transfer.do?acct=ShadyLady15&amount=100000" width="0" height="0" border="0">
Das Ergebnis ist das gleiche. ShadyLady15 erhält 100.000 $, ohne dass jemand den Angriff entdeckt.
Warum ist CSRF so gefährlich?
CSRF-Angriffe sind heute aus dem gleichen Grund beliebt, aus dem Ransomware-Angriffe weiterhin die Runde machen. Es liegen nur wenige Schritte zwischen den Angreifern und dem Geld des Opfers. Bei einem Ransomware-Angriff werden Systeme verschlüsselt und die Benutzer werden um Geld für die Entschlüsselung der Daten erpresst. Bei einer CSRF-Attacke sind es sogar noch weniger Schritte. Wenn sie funktionieren, schicken die Opfer einfach Geld an die Angreifer, ohne es zu wissen.
Über direkte Angriffe auf das Geld eines Opfers oder die Finanzen eines Unternehmens hinaus können erfolgreiche CSRF-Angriffe dazu verwendet werden, ein Netzwerk mit gültigen Benutzern zu kompromittieren. Stellen Sie sich vor, ein Angreifer könnte mithilfe eines CSRF-Exploits das Passwort eines Administrators ändern. Er könnte dieses Passwort sofort verwenden, um Daten zu stehlen, Löcher in der Netzwerkverteidigung zu öffnen oder Backdoors zu installieren.
Obwohl es eine Menge Arbeit und bis zu einem gewissen Grad auch Glück ist, kann ein erfolgreicher CSRF-Angriff für Hacker wie ein Lottogewinn sein, unabhängig von ihrem eigentlichen Ziel. Bei einem Angriff auf ein Netzwerk würde fast jede andere Art von Angriff monatelange, niedrige und langsame Erkundung erfordern und versuchen, unter dem Radar des SIEM- und Cybersecurity-Personals zu bleiben. Im Gegensatz dazu kann ein einziger CSRF-Angriff einige Schritte entlang der Cyber-Kill-Chain überspringen und lässt sie sehr nah an ihrem ultimativen Ziel beginnen.
Wie kann ich CSRF-Attacken stoppen?
Anders als bei den meisten Schwachstellen liegt der Fehler bei CSRF-Angriffen nicht wirklich beim Code, sondern bei einem Exploit, den Angreifer erstellt haben, um einen Browser zu zwingen, Anfragen zu stellen, die ein Benutzer nicht will und von denen er möglicherweise nicht einmal weiß. Aber sie können besiegt werden.
Eine der besten Methoden besteht darin, dass die Entwickler ein CSRF-Token zur Identität eines Benutzers hinzufügen, wenn eine neue Sitzung erzeugt wird. Es sollte aus einer Zeichenfolge aus eindeutigen und zufälligen Zeichen bestehen und für den Benutzer unsichtbar sein. Als Nächstes fügen Sie die CSRF-Token-Anforderung als verstecktes Feld zu Formularen hinzu, die vom Server geprüft werden, sobald eine neue Anforderung übermittelt wird. Angreifer, die Anfragen über den Browser eines Benutzers übermitteln, werden nicht einmal von dem versteckten Token-Feld wissen, geschweige denn in der Lage sein, herauszufinden, was es ist, sodass alle ihre Anfragen fehlschlagen werden.
Eine noch einfachere Methode, die keinen großen Programmieraufwand erfordert, ist das Hinzufügen einer Captcha-Abfrage zu sensiblen Daten wie Passwortänderungsanfragen oder Überweisungsaufträgen. Sie kann so einfach sein wie die Aufforderung an einen Benutzer, auf eine Schaltfläche zu klicken, um zu bestätigen, dass der Antragsteller kein Roboter oder in diesem Fall ein CSRF-Skript ist. Angreifer sind nicht in der Lage, eine Antwort auf die Aufforderung zu skripten, und Benutzer, die plötzlich eine CAPTCHA-Aufforderung erhalten, ohne vorher etwas zu tun, z. B. eine Überweisungsanforderung zu stellen, wissen, dass etwas nicht stimmt. Alternativ kann ein Einmal-Passwort mit einem Token eines Drittanbieters, z. B. einem Smartphone, generiert werden, je nachdem, wie sehr ein Unternehmen die Arbeit im Namen der Sicherheit verlangsamen möchte.
Schließlich haben viele Browser wie Microsoft Edge oder Google Chrome, auch wenn sie nicht hundertprozentig sicher sind, Beschränkungen in der Same-Origin-Policy, um Anfragen von anderen als dem lokalen Benutzer zu blockieren. Wenn Sie Benutzer dazu zwingen, mit Ihrer Website über die aktuellsten Versionen dieser Browser zu interagieren, können Sie eine weitere Ebene der CSRF-Sicherheit einbauen, ohne die Entwicklungsteams zu belasten.
Die Tür für CSRF zuschlagen
Mit einem so hohen Auszahlungspotenzial werden CSRF-Angriffe wahrscheinlich nie ganz aussterben, aber wir hoffen, Sie haben gelernt, warum sie so hartnäckig sind und wie Sie sie für immer aus Ihrem Netzwerk blockieren können.
Für weitere Informationen können Sie einen Blick auf das OWASP Cross-Site Request Forgery Prevention Cheat Sheet werfen, das als lebendes Dokument dient, das diese Schwachstelle in ihrer Entwicklung aufzeichnet. Wenn Sie Ihr Sicherheitswissen wirklich erweitern möchten, können Sie lernen, wie Sie diese und viele andere Bedrohungen abwehren können, indem Sie den Secure Code Warrior Blog.
Glauben Sie, dass Sie bereit sind, Ihr neues Verteidigungswissen auf die Probe zu stellen? Spielen Sie noch heute mit der kostenlosen Demo der Plattform Secure Code Warrior herum.
目次
Jaap Karan Singhは、セキュア・コーディング・エバンジェリストであり、チーフ・シンであり、セキュア・コード・ウォリアーの共同創設者です。
Secure Code Warrior schützt Ihren Code während des gesamten Softwareentwicklungszyklus und hilft Ihnen dabei, eine Kultur zu schaffen, in der Cybersicherheit oberste Priorität hat. Ganz gleich, ob Sie Anwendungs-Sicherheitsmanager, Entwickler, CISO oder Sicherheitsbeauftragter sind – wir helfen Ihnen dabei, die mit unsicherem Code verbundenen Risiken zu minimieren.
デモを予約[ダウンロード]Ressourcen für den Einstieg
Themen und Inhalte der Secure-Code-Schulung
Unsere branchenführenden Inhalte werden unter Berücksichtigung der Aufgaben unserer Kunden ständig weiterentwickelt, um mit der sich ständig verändernden Softwareentwicklungsumgebung Schritt zu halten. Sie decken alle Themen von KI bis hin zu XQuery-Injection ab und sind für verschiedene Aufgabenbereiche konzipiert, von Architekten und Ingenieuren bis hin zu Produktmanagern und Qualitätssicherungsfachleuten. Werfen Sie einen Blick auf die Inhalte unseres Content-Katalogs, sortiert nach Themen und Aufgabenbereichen.
Die Kamer van Koophandel setzt Maßstäbe für entwicklergesteuerte Sicherheit in großem Maßstab
Die Kamer van Koophandel berichtet, wie sie sicheres Codieren durch rollenbasierte Zertifizierungen, Trust Score-Benchmarking und eine Kultur der gemeinsamen Verantwortung für Sicherheit in die tägliche Entwicklungsarbeit integriert hat.
%20(1).avif)
.avif)
Bedrohungsmodellierung mit KI: So wird jeder Entwickler zum Bedrohungsmodellierer
Sie werden besser gerüstet sein, um Entwicklern dabei zu helfen, Ideen und Techniken zur Bedrohungsmodellierung mit den KI-Tools zu kombinieren, die sie bereits verwenden, um die Sicherheit zu erhöhen, die Zusammenarbeit zu verbessern und von Anfang an widerstandsfähigere Software zu entwickeln.
Ressourcen für den Einstieg
Cybermon ist zurück: Die KI-Mission zum Besiegen des Bosses ist jetzt auf Abruf verfügbar.
「Cybermon 2025 Beat the Boss」 kann nun das ganze Jahr über bei SCW gespielt werden. Führen Sie anspruchsvolle AI/LLM-Sicherheitsherausforderungen ein, um die sichere AI-Entwicklung in großem Maßstab zu stärken.
Erläuterung des Cyber-Resilience-Gesetzes: Bedeutung für die Entwicklung sicherer Software
Erfahren Sie, was das EU-Gesetz zur Cyberresilienz (CRA) verlangt, für wen es gilt und wie sich Ingenieurteams auf Secure-by-Design-Praktiken, Schwachstellenprävention und die Kompetenzentwicklung von Entwicklern vorbereiten können.
Enabler 1: Definierte und messbare Erfolgskriterien
Enabler 1 ist der erste Teil der zehnteiligen Reihe „Enablers of Success“ und zeigt, wie sichere Programmierung mit geschäftlichen Ergebnissen wie Risikominderung und Geschwindigkeit verknüpft werden kann, um Programme langfristig zu optimieren.
