Programmierer erobern Sicherheit: Share & Learn-Serie — Site-übergreifende Anforderungsfälschung
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 Anmeldeinformationen direkt von einem Benutzer zu stehlen. Dies bedeutet nicht, dass Webseitenbetreiber Sicherheitslücken im CSRF-Code ignorieren sollten, da letztlich für den Ersatz gestohlener Gelder im Falle eines rein monetären Angriffs die Hosting-Website mit dem unsicheren Code verantwortlich sein kann. Und wenn der Zielbenutzer stattdessen seine Anmeldeinformationen verliert oder sein Passwort unwissentlich geändert wird, kann ein Krimineller mit dieser gestohlenen Identität Chaos anrichten, insbesondere wenn das Opfer privilegierten Zugriff hat.
CSRF-Angriffe sind ziemlich komplex und basieren auf mehreren Ebenen, um erfolgreich zu sein. Mit anderen Worten, viele Dinge müssen zugunsten des Angreifers kaputt gehen, damit es funktioniert. Trotzdem sind sie ein äußerst beliebter Angriffsvektor, da ein erfolgreicher Angriff Geld direkt an einen Hacker überweisen oder ihn so einrichten kann, dass er sich ungestraft auf einer Website bewegen kann. Wenn alles in die Richtung eines Hackers geht, erfährt der Zielbenutzer möglicherweise nicht einmal, dass er Opfer eines Angriffs geworden ist.
Die gute Nachricht ist, dass, weil so viel richtig laufen muss, damit ein CSRF-Angriff funktioniert, es eine ganze Reihe großartiger Abwehrtechniken gibt, die sie aufhalten können.
Zu diesem Zweck werden wir drei wichtige Aspekte von CSRF-Angriffen erörtern:
- So funktionieren sie
- Warum sie so gefährlich sind
- Wie Sie Abwehrmechanismen einrichten können, um sie vor der Erkältung zu schützen.
Wie funktionieren CSRF-Angriffe?
Da erfolgreiche CSRF-Angriffe die Fähigkeit haben, direkt Geld, Waren oder Anmeldeinformationen von Zielnutzern zu stehlen, sind sie trotz des hohen Arbeitsaufwands, der zu ihrer Erstellung erforderlich ist, beliebt. Und weil sie oft auf verschiedenen Plattformen versucht werden, haben sie sich im Laufe der Jahre eine Vielzahl von Namen und Spitznamen angeeignet. Möglicherweise hören Sie CSRF-Angriffe, die als XSRF, Sea Surf, Session Riding, Cross-Site Reference Forgery oder Hostile Linking bezeichnet werden. Microsoft bezeichnet sie in den meisten seiner Dokumentation gerne als One-Click-Angriffe. Aber es sind alles CSRF-Angriffe, und die Techniken, um sie abzuwehren, sind identisch.
Ein CSRF-Angriff kann auftreten, 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 auf einer Website oder Anwendung authentifiziert sein muss. Der Angriff wird normalerweise von einer sekundären Website oder einer E-Mail aus gestartet. Oft verwenden Angreifer Social-Engineering-Techniken, um Benutzer dazu zu bringen, auf einen Link in einer E-Mail zu klicken, der sie zu einer gefährdeten Website mit dem Angriffsskript führt.
Die kompromittierte Website enthält ein Skript, das den aktiven Browser anweist, Befehle auszuführen, die normalerweise bösartig sind, wie das Ändern des Passworts eines Benutzers oder die Überweisung von Geld auf ein vom Angreifer kontrolliertes Konto. Solange der Benutzer authentifiziert ist, geht die Website davon aus, dass die Befehle vom autorisierten Benutzer ausgegeben werden. Warum sollte es das nicht tun? Der Benutzer hat sich bereits authentifiziert und alle Passwörter eingegeben, die für den Zugriff auf die Website erforderlich sind. Sie befinden sich möglicherweise sogar innerhalb eines Geofences und befinden sich direkt an ihrem Büroterminal. Wenn sie ihr Passwort ändern oder Geld überweisen möchten, gibt es keinen Grund, nicht zu glauben, dass sie es sind, die die Anfrage gestellt haben.
Wenn man die Elemente des Angriffs aufschlüsselt, ist klar, warum dieser Angriff für den Angreifer so schwierig durchzuführen ist. Zunächst muss der Benutzer aktiv bei der Site authentifiziert werden, auf der der Angriff stattfindet. Wenn eine E-Mail mit einem Angriffsskript eingeht, nachdem ein Benutzer seine Browsersitzung beendet oder sich abgemeldet hat, schlägt der Angriff fehl.
Der Angreifer ist außerdem gezwungen, auf der Zielseite viele Auskundungen durchzuführen, um zu wissen, welche Skripte diese Site akzeptiert. Angreifer können den Bildschirm eines Opfers nicht sehen, und jegliches Feedback von der Website geht an das Opfer, nicht an den Angreifer. Sofern der Angreifer nicht in der Lage ist, Beweise dafür zu sehen, dass sein Angriff funktioniert, z. B. wenn plötzlich Geld auf seinem Konto erscheint, wird er nicht einmal sofort wissen, ob der Angriff erfolgreich war.
Angesichts der schwierigen, aber nicht unmöglichen Parameter, dass der Benutzer zum Zeitpunkt des Angriffs angemeldet ist und weiß, welche Skripts die Zielseite akzeptiert, kann der Code zur Ausführung eines CSRF-Angriffs extrem einfach sein, obwohl er je nach Website selbst variiert.
Nehmen wir an, eine Bank- oder Finanzanwendung verwendet GET-Anfragen, um Geld zu überweisen, wie folgt:
HOLEN SIE SICH 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 Zielbenutzer jedoch eine E-Mail erhalten hat, vielleicht eine, die als von einem Kollegen getarnt ist, könnte ein CSRF-Angriffsskript in die Klickaktion eingebettet werden:
<a href="http://bank.com/transfer.do?acct=ShadyLady15&amount=100000">Können Sie diesen Quartalsbericht schnell durchlesen? <a></a></a>
Wenn der Zielbenutzer auf den Social-Engineering-Link hereinfiel und darauf klickte, während die Browsersitzung mit der Finanzanwendung noch geöffnet war, forderte sein Browser die Anwendung auf, 100.000$ an das Konto von ShadyLady15 zu senden.
Das Skript könnte sogar in einem unsichtbaren Bild versteckt sein, das der Benutzer nicht sehen würde, das aber dennoch den Browser veranlassen könnte, die Anfrage zu stellen, wie folgt:
<img src="http://bank.com/transfer.do?acct=ShadyLady15&amount=100000" width="0" height="0" border="0">
Das Ergebnis ist dasselbe. ShadyLady15 erhält 100.000$, ohne dass jemand den Angriff bemerkt.
Warum ist CSRF so gefährlich?
CSRF-Angriffe sind heute aus dem gleichen Grund beliebt, aus dem Ransomware-Angriffe weiterhin die Runde machen. Es gibt nur sehr wenige Sprünge zwischen Angreifern und dem Geld eines Opfers. Bei einem Ransomware-Angriff werden Systeme verschlüsselt und Benutzer werden um Geld für die Entschlüsselung dieser Daten erpresst. Bei einem CSRF-Angriff sind es noch weniger Schritte. Wenn sie arbeiten, schicken die Opfer einfach Geld an die Angreifer, ohne es zu wissen.
Neben direkten Angriffen auf das Geld eines Opfers oder die Finanzen eines Unternehmens können erfolgreiche CSRF-Angriffe dazu verwendet werden, ein Netzwerk mithilfe gültiger Benutzer zu kompromittieren. Stellen Sie sich vor, ein Angreifer könnte einen CSRF-Exploit verwenden, um das Passwort eines Administrators zu ändern. Sie könnten dieses Passwort sofort verwenden, um Daten zu stehlen, Sicherheitslücken im Netzwerk zu öffnen oder Hintertüren zu installieren.
Obwohl es eine Menge Arbeit und bis zu einem gewissen Grad Glück ist, kann ein erfolgreicher CSRF-Angriff für Hacker unabhängig von ihrem ultimativen Ziel wie ein Lottogewinn sein. Bei einem Angriff auf ein Netzwerk wäre für fast jede andere Art von Angriff monatelange, langsame Aufklärungsarbeit erforderlich, um unter dem Radar der SIEM- und Cybersicherheitsteams zu bleiben. Im Gegensatz dazu können bei einem einzelnen CSRF-Angriff einige Schritte entlang der Cyber-Kill-Chain übersprungen werden, sodass sie ihrem ultimativen Ziel sehr nahe kommen.
Wie stoppe ich CSRF-Angriffe?
Im Gegensatz zu den meisten Sicherheitslücken liegt der Fehler bei CSRF-Angriffen nicht wirklich im Code, sondern in einem Exploit, den Angreifer erstellt haben, um einen Browser zu zwingen, Anfragen zu stellen, die ein Benutzer nicht möchte und von denen er möglicherweise nicht einmal weiß. Aber sie können besiegt werden.
Eine der besten Methoden besteht darin, Entwickler dazu zu bringen, der Identität eines Benutzers ein CSRF-Token hinzuzufügen, wenn eine neue Sitzung generiert wird. Es sollte aus einer Reihe eindeutiger und zufälliger Zeichen bestehen und für Benutzer unsichtbar sein. Fügen Sie als Nächstes die CSRF-Token-Anfrage als verstecktes Feld zu Formularen hinzu, die vom Server überprüft werden, wenn eine neue Anfrage eingereicht wird. Angreifer, die Anfragen über den Browser eines Benutzers einreichen, wissen nicht einmal von dem versteckten Token-Feld, geschweige denn, sie können herausfinden, um welches es sich handelt, sodass alle ihre Anfragen fehlschlagen.
Eine noch einfachere Methode, die nicht viel Programmierung erfordert, besteht darin, vertraulichen Dingen wie Passwortänderungsanfragen oder Geldüberweisungsaufträgen eine Captcha-Herausforderung hinzuzufügen. Es kann so einfach sein, einen Benutzer zu bitten, auf eine Schaltfläche zu klicken, um zu bestätigen, dass es sich bei dem Anforderer nicht um einen Roboter oder in diesem Fall um ein CSRF-Skript handelt. Angreifer werden nicht in der Lage sein, eine Antwort auf die Herausforderung zu schreiben, und Benutzer, die plötzlich eine CAPTCHA-Aufforderung erhalten, ohne zuvor etwas wie eine Geldtransferanfrage zu stellen, wissen, dass etwas nicht stimmt. Alternativ kann die Generierung eines Einmalkennworts mithilfe eines Drittanbieter-Tokens, z. B. eines Smartphones, verwendet werden, je nachdem, wie stark ein Unternehmen die Arbeit im Namen der Sicherheit verlangsamen möchte.
Schließlich haben viele Browser wie Microsoft Edge oder Google Chrome jetzt, obwohl es nicht unumstößlich ist Politik des gleichen Ursprungs Es gibt Einschränkungen, um Anfragen von allen außer dem lokalen Benutzer zu blockieren. Wenn Sie Benutzer dazu zwingen, mit Ihrer Website über die aktuellsten Versionen dieser Browser zu interagieren, kann dies dazu beitragen, eine weitere CSRF-Sicherheitsebene aufzubauen, ohne die Entwicklungsteams überhaupt zu belasten.
CSRF die Tür zuschlagen
Bei einem so hohen Auszahlungspotenzial werden CSRF-Angriffe wahrscheinlich nie vollständig verschwinden, aber wir hoffen, dass Sie erfahren haben, warum sie so hartnäckig sind und wie Sie sie endgültig von Ihrem Netzwerk fernhalten können.
Weitere Informationen finden Sie im OWASP Cross-Site Request Forgery Prevention Cheat Sheet, das als lebendes Dokument dient, das die Entwicklung dieser Sicherheitslücke dokumentiert. Wenn Sie Ihr Sicherheitswissen wirklich erweitern möchten, können Sie lernen, wie Sie diese und viele weitere Bedrohungen abwehren können, indem Sie die Sicherer Codekrieger Blog.
Denken Sie, Sie sind bereit, Ihr neues Defensivwissen auf die Probe zu stellen? Spiel ein bisschen mit dem kostenlose Demo der Secure Code Warrior-Plattform heute.
CSRF-Angriffe sind ziemlich komplex und basieren auf mehreren Ebenen, um erfolgreich zu sein. Mit anderen Worten, viele Dinge müssen zugunsten des Angreifers kaputt gehen, damit es funktioniert. Trotzdem sind sie ein äußerst beliebter, lukrativer Angriffsvektor.
Jaap Karan Singh ist Secure Coding Evangelist, Chief Singh und Mitbegründer von Secure Code Warrior.
Secure Code Warrior für Ihr Unternehmen da, um Ihnen zu helfen, Code während des gesamten Softwareentwicklungszyklus zu sichern und eine Kultur zu schaffen, in der Cybersicherheit an erster Stelle steht. Ganz gleich, ob Sie AppSec-Manager, Entwickler, CISO oder jemand anderes sind, der sich mit Sicherheit befasst, wir können Ihrem Unternehmen helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Eine Demo buchen
Jaap Karan Singh ist Secure Coding Evangelist, Chief Singh und Mitbegründer von Secure Code Warrior.
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 Anmeldeinformationen direkt von einem Benutzer zu stehlen. Dies bedeutet nicht, dass Webseitenbetreiber Sicherheitslücken im CSRF-Code ignorieren sollten, da letztlich für den Ersatz gestohlener Gelder im Falle eines rein monetären Angriffs die Hosting-Website mit dem unsicheren Code verantwortlich sein kann. Und wenn der Zielbenutzer stattdessen seine Anmeldeinformationen verliert oder sein Passwort unwissentlich geändert wird, kann ein Krimineller mit dieser gestohlenen Identität Chaos anrichten, insbesondere wenn das Opfer privilegierten Zugriff hat.
CSRF-Angriffe sind ziemlich komplex und basieren auf mehreren Ebenen, um erfolgreich zu sein. Mit anderen Worten, viele Dinge müssen zugunsten des Angreifers kaputt gehen, damit es funktioniert. Trotzdem sind sie ein äußerst beliebter Angriffsvektor, da ein erfolgreicher Angriff Geld direkt an einen Hacker überweisen oder ihn so einrichten kann, dass er sich ungestraft auf einer Website bewegen kann. Wenn alles in die Richtung eines Hackers geht, erfährt der Zielbenutzer möglicherweise nicht einmal, dass er Opfer eines Angriffs geworden ist.
Die gute Nachricht ist, dass, weil so viel richtig laufen muss, damit ein CSRF-Angriff funktioniert, es eine ganze Reihe großartiger Abwehrtechniken gibt, die sie aufhalten können.
Zu diesem Zweck werden wir drei wichtige Aspekte von CSRF-Angriffen erörtern:
- So funktionieren sie
- Warum sie so gefährlich sind
- Wie Sie Abwehrmechanismen einrichten können, um sie vor der Erkältung zu schützen.
Wie funktionieren CSRF-Angriffe?
Da erfolgreiche CSRF-Angriffe die Fähigkeit haben, direkt Geld, Waren oder Anmeldeinformationen von Zielnutzern zu stehlen, sind sie trotz des hohen Arbeitsaufwands, der zu ihrer Erstellung erforderlich ist, beliebt. Und weil sie oft auf verschiedenen Plattformen versucht werden, haben sie sich im Laufe der Jahre eine Vielzahl von Namen und Spitznamen angeeignet. Möglicherweise hören Sie CSRF-Angriffe, die als XSRF, Sea Surf, Session Riding, Cross-Site Reference Forgery oder Hostile Linking bezeichnet werden. Microsoft bezeichnet sie in den meisten seiner Dokumentation gerne als One-Click-Angriffe. Aber es sind alles CSRF-Angriffe, und die Techniken, um sie abzuwehren, sind identisch.
Ein CSRF-Angriff kann auftreten, 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 auf einer Website oder Anwendung authentifiziert sein muss. Der Angriff wird normalerweise von einer sekundären Website oder einer E-Mail aus gestartet. Oft verwenden Angreifer Social-Engineering-Techniken, um Benutzer dazu zu bringen, auf einen Link in einer E-Mail zu klicken, der sie zu einer gefährdeten Website mit dem Angriffsskript führt.
Die kompromittierte Website enthält ein Skript, das den aktiven Browser anweist, Befehle auszuführen, die normalerweise bösartig sind, wie das Ändern des Passworts eines Benutzers oder die Überweisung von Geld auf ein vom Angreifer kontrolliertes Konto. Solange der Benutzer authentifiziert ist, geht die Website davon aus, dass die Befehle vom autorisierten Benutzer ausgegeben werden. Warum sollte es das nicht tun? Der Benutzer hat sich bereits authentifiziert und alle Passwörter eingegeben, die für den Zugriff auf die Website erforderlich sind. Sie befinden sich möglicherweise sogar innerhalb eines Geofences und befinden sich direkt an ihrem Büroterminal. Wenn sie ihr Passwort ändern oder Geld überweisen möchten, gibt es keinen Grund, nicht zu glauben, dass sie es sind, die die Anfrage gestellt haben.
Wenn man die Elemente des Angriffs aufschlüsselt, ist klar, warum dieser Angriff für den Angreifer so schwierig durchzuführen ist. Zunächst muss der Benutzer aktiv bei der Site authentifiziert werden, auf der der Angriff stattfindet. Wenn eine E-Mail mit einem Angriffsskript eingeht, nachdem ein Benutzer seine Browsersitzung beendet oder sich abgemeldet hat, schlägt der Angriff fehl.
Der Angreifer ist außerdem gezwungen, auf der Zielseite viele Auskundungen durchzuführen, um zu wissen, welche Skripte diese Site akzeptiert. Angreifer können den Bildschirm eines Opfers nicht sehen, und jegliches Feedback von der Website geht an das Opfer, nicht an den Angreifer. Sofern der Angreifer nicht in der Lage ist, Beweise dafür zu sehen, dass sein Angriff funktioniert, z. B. wenn plötzlich Geld auf seinem Konto erscheint, wird er nicht einmal sofort wissen, ob der Angriff erfolgreich war.
Angesichts der schwierigen, aber nicht unmöglichen Parameter, dass der Benutzer zum Zeitpunkt des Angriffs angemeldet ist und weiß, welche Skripts die Zielseite akzeptiert, kann der Code zur Ausführung eines CSRF-Angriffs extrem einfach sein, obwohl er je nach Website selbst variiert.
Nehmen wir an, eine Bank- oder Finanzanwendung verwendet GET-Anfragen, um Geld zu überweisen, wie folgt:
HOLEN SIE SICH 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 Zielbenutzer jedoch eine E-Mail erhalten hat, vielleicht eine, die als von einem Kollegen getarnt ist, könnte ein CSRF-Angriffsskript in die Klickaktion eingebettet werden:
<a href="http://bank.com/transfer.do?acct=ShadyLady15&amount=100000">Können Sie diesen Quartalsbericht schnell durchlesen? <a></a></a>
Wenn der Zielbenutzer auf den Social-Engineering-Link hereinfiel und darauf klickte, während die Browsersitzung mit der Finanzanwendung noch geöffnet war, forderte sein Browser die Anwendung auf, 100.000$ an das Konto von ShadyLady15 zu senden.
Das Skript könnte sogar in einem unsichtbaren Bild versteckt sein, das der Benutzer nicht sehen würde, das aber dennoch den Browser veranlassen könnte, die Anfrage zu stellen, wie folgt:
<img src="http://bank.com/transfer.do?acct=ShadyLady15&amount=100000" width="0" height="0" border="0">
Das Ergebnis ist dasselbe. ShadyLady15 erhält 100.000$, ohne dass jemand den Angriff bemerkt.
Warum ist CSRF so gefährlich?
CSRF-Angriffe sind heute aus dem gleichen Grund beliebt, aus dem Ransomware-Angriffe weiterhin die Runde machen. Es gibt nur sehr wenige Sprünge zwischen Angreifern und dem Geld eines Opfers. Bei einem Ransomware-Angriff werden Systeme verschlüsselt und Benutzer werden um Geld für die Entschlüsselung dieser Daten erpresst. Bei einem CSRF-Angriff sind es noch weniger Schritte. Wenn sie arbeiten, schicken die Opfer einfach Geld an die Angreifer, ohne es zu wissen.
Neben direkten Angriffen auf das Geld eines Opfers oder die Finanzen eines Unternehmens können erfolgreiche CSRF-Angriffe dazu verwendet werden, ein Netzwerk mithilfe gültiger Benutzer zu kompromittieren. Stellen Sie sich vor, ein Angreifer könnte einen CSRF-Exploit verwenden, um das Passwort eines Administrators zu ändern. Sie könnten dieses Passwort sofort verwenden, um Daten zu stehlen, Sicherheitslücken im Netzwerk zu öffnen oder Hintertüren zu installieren.
Obwohl es eine Menge Arbeit und bis zu einem gewissen Grad Glück ist, kann ein erfolgreicher CSRF-Angriff für Hacker unabhängig von ihrem ultimativen Ziel wie ein Lottogewinn sein. Bei einem Angriff auf ein Netzwerk wäre für fast jede andere Art von Angriff monatelange, langsame Aufklärungsarbeit erforderlich, um unter dem Radar der SIEM- und Cybersicherheitsteams zu bleiben. Im Gegensatz dazu können bei einem einzelnen CSRF-Angriff einige Schritte entlang der Cyber-Kill-Chain übersprungen werden, sodass sie ihrem ultimativen Ziel sehr nahe kommen.
Wie stoppe ich CSRF-Angriffe?
Im Gegensatz zu den meisten Sicherheitslücken liegt der Fehler bei CSRF-Angriffen nicht wirklich im Code, sondern in einem Exploit, den Angreifer erstellt haben, um einen Browser zu zwingen, Anfragen zu stellen, die ein Benutzer nicht möchte und von denen er möglicherweise nicht einmal weiß. Aber sie können besiegt werden.
Eine der besten Methoden besteht darin, Entwickler dazu zu bringen, der Identität eines Benutzers ein CSRF-Token hinzuzufügen, wenn eine neue Sitzung generiert wird. Es sollte aus einer Reihe eindeutiger und zufälliger Zeichen bestehen und für Benutzer unsichtbar sein. Fügen Sie als Nächstes die CSRF-Token-Anfrage als verstecktes Feld zu Formularen hinzu, die vom Server überprüft werden, wenn eine neue Anfrage eingereicht wird. Angreifer, die Anfragen über den Browser eines Benutzers einreichen, wissen nicht einmal von dem versteckten Token-Feld, geschweige denn, sie können herausfinden, um welches es sich handelt, sodass alle ihre Anfragen fehlschlagen.
Eine noch einfachere Methode, die nicht viel Programmierung erfordert, besteht darin, vertraulichen Dingen wie Passwortänderungsanfragen oder Geldüberweisungsaufträgen eine Captcha-Herausforderung hinzuzufügen. Es kann so einfach sein, einen Benutzer zu bitten, auf eine Schaltfläche zu klicken, um zu bestätigen, dass es sich bei dem Anforderer nicht um einen Roboter oder in diesem Fall um ein CSRF-Skript handelt. Angreifer werden nicht in der Lage sein, eine Antwort auf die Herausforderung zu schreiben, und Benutzer, die plötzlich eine CAPTCHA-Aufforderung erhalten, ohne zuvor etwas wie eine Geldtransferanfrage zu stellen, wissen, dass etwas nicht stimmt. Alternativ kann die Generierung eines Einmalkennworts mithilfe eines Drittanbieter-Tokens, z. B. eines Smartphones, verwendet werden, je nachdem, wie stark ein Unternehmen die Arbeit im Namen der Sicherheit verlangsamen möchte.
Schließlich haben viele Browser wie Microsoft Edge oder Google Chrome jetzt, obwohl es nicht unumstößlich ist Politik des gleichen Ursprungs Es gibt Einschränkungen, um Anfragen von allen außer dem lokalen Benutzer zu blockieren. Wenn Sie Benutzer dazu zwingen, mit Ihrer Website über die aktuellsten Versionen dieser Browser zu interagieren, kann dies dazu beitragen, eine weitere CSRF-Sicherheitsebene aufzubauen, ohne die Entwicklungsteams überhaupt zu belasten.
CSRF die Tür zuschlagen
Bei einem so hohen Auszahlungspotenzial werden CSRF-Angriffe wahrscheinlich nie vollständig verschwinden, aber wir hoffen, dass Sie erfahren haben, warum sie so hartnäckig sind und wie Sie sie endgültig von Ihrem Netzwerk fernhalten können.
Weitere Informationen finden Sie im OWASP Cross-Site Request Forgery Prevention Cheat Sheet, das als lebendes Dokument dient, das die Entwicklung dieser Sicherheitslücke dokumentiert. Wenn Sie Ihr Sicherheitswissen wirklich erweitern möchten, können Sie lernen, wie Sie diese und viele weitere Bedrohungen abwehren können, indem Sie die Sicherer Codekrieger Blog.
Denken Sie, Sie sind bereit, Ihr neues Defensivwissen auf die Probe zu stellen? Spiel ein bisschen mit dem kostenlose Demo der Secure Code Warrior-Plattform heute.
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 Anmeldeinformationen direkt von einem Benutzer zu stehlen. Dies bedeutet nicht, dass Webseitenbetreiber Sicherheitslücken im CSRF-Code ignorieren sollten, da letztlich für den Ersatz gestohlener Gelder im Falle eines rein monetären Angriffs die Hosting-Website mit dem unsicheren Code verantwortlich sein kann. Und wenn der Zielbenutzer stattdessen seine Anmeldeinformationen verliert oder sein Passwort unwissentlich geändert wird, kann ein Krimineller mit dieser gestohlenen Identität Chaos anrichten, insbesondere wenn das Opfer privilegierten Zugriff hat.
CSRF-Angriffe sind ziemlich komplex und basieren auf mehreren Ebenen, um erfolgreich zu sein. Mit anderen Worten, viele Dinge müssen zugunsten des Angreifers kaputt gehen, damit es funktioniert. Trotzdem sind sie ein äußerst beliebter Angriffsvektor, da ein erfolgreicher Angriff Geld direkt an einen Hacker überweisen oder ihn so einrichten kann, dass er sich ungestraft auf einer Website bewegen kann. Wenn alles in die Richtung eines Hackers geht, erfährt der Zielbenutzer möglicherweise nicht einmal, dass er Opfer eines Angriffs geworden ist.
Die gute Nachricht ist, dass, weil so viel richtig laufen muss, damit ein CSRF-Angriff funktioniert, es eine ganze Reihe großartiger Abwehrtechniken gibt, die sie aufhalten können.
Zu diesem Zweck werden wir drei wichtige Aspekte von CSRF-Angriffen erörtern:
- So funktionieren sie
- Warum sie so gefährlich sind
- Wie Sie Abwehrmechanismen einrichten können, um sie vor der Erkältung zu schützen.
Wie funktionieren CSRF-Angriffe?
Da erfolgreiche CSRF-Angriffe die Fähigkeit haben, direkt Geld, Waren oder Anmeldeinformationen von Zielnutzern zu stehlen, sind sie trotz des hohen Arbeitsaufwands, der zu ihrer Erstellung erforderlich ist, beliebt. Und weil sie oft auf verschiedenen Plattformen versucht werden, haben sie sich im Laufe der Jahre eine Vielzahl von Namen und Spitznamen angeeignet. Möglicherweise hören Sie CSRF-Angriffe, die als XSRF, Sea Surf, Session Riding, Cross-Site Reference Forgery oder Hostile Linking bezeichnet werden. Microsoft bezeichnet sie in den meisten seiner Dokumentation gerne als One-Click-Angriffe. Aber es sind alles CSRF-Angriffe, und die Techniken, um sie abzuwehren, sind identisch.
Ein CSRF-Angriff kann auftreten, 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 auf einer Website oder Anwendung authentifiziert sein muss. Der Angriff wird normalerweise von einer sekundären Website oder einer E-Mail aus gestartet. Oft verwenden Angreifer Social-Engineering-Techniken, um Benutzer dazu zu bringen, auf einen Link in einer E-Mail zu klicken, der sie zu einer gefährdeten Website mit dem Angriffsskript führt.
Die kompromittierte Website enthält ein Skript, das den aktiven Browser anweist, Befehle auszuführen, die normalerweise bösartig sind, wie das Ändern des Passworts eines Benutzers oder die Überweisung von Geld auf ein vom Angreifer kontrolliertes Konto. Solange der Benutzer authentifiziert ist, geht die Website davon aus, dass die Befehle vom autorisierten Benutzer ausgegeben werden. Warum sollte es das nicht tun? Der Benutzer hat sich bereits authentifiziert und alle Passwörter eingegeben, die für den Zugriff auf die Website erforderlich sind. Sie befinden sich möglicherweise sogar innerhalb eines Geofences und befinden sich direkt an ihrem Büroterminal. Wenn sie ihr Passwort ändern oder Geld überweisen möchten, gibt es keinen Grund, nicht zu glauben, dass sie es sind, die die Anfrage gestellt haben.
Wenn man die Elemente des Angriffs aufschlüsselt, ist klar, warum dieser Angriff für den Angreifer so schwierig durchzuführen ist. Zunächst muss der Benutzer aktiv bei der Site authentifiziert werden, auf der der Angriff stattfindet. Wenn eine E-Mail mit einem Angriffsskript eingeht, nachdem ein Benutzer seine Browsersitzung beendet oder sich abgemeldet hat, schlägt der Angriff fehl.
Der Angreifer ist außerdem gezwungen, auf der Zielseite viele Auskundungen durchzuführen, um zu wissen, welche Skripte diese Site akzeptiert. Angreifer können den Bildschirm eines Opfers nicht sehen, und jegliches Feedback von der Website geht an das Opfer, nicht an den Angreifer. Sofern der Angreifer nicht in der Lage ist, Beweise dafür zu sehen, dass sein Angriff funktioniert, z. B. wenn plötzlich Geld auf seinem Konto erscheint, wird er nicht einmal sofort wissen, ob der Angriff erfolgreich war.
Angesichts der schwierigen, aber nicht unmöglichen Parameter, dass der Benutzer zum Zeitpunkt des Angriffs angemeldet ist und weiß, welche Skripts die Zielseite akzeptiert, kann der Code zur Ausführung eines CSRF-Angriffs extrem einfach sein, obwohl er je nach Website selbst variiert.
Nehmen wir an, eine Bank- oder Finanzanwendung verwendet GET-Anfragen, um Geld zu überweisen, wie folgt:
HOLEN SIE SICH 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 Zielbenutzer jedoch eine E-Mail erhalten hat, vielleicht eine, die als von einem Kollegen getarnt ist, könnte ein CSRF-Angriffsskript in die Klickaktion eingebettet werden:
<a href="http://bank.com/transfer.do?acct=ShadyLady15&amount=100000">Können Sie diesen Quartalsbericht schnell durchlesen? <a></a></a>
Wenn der Zielbenutzer auf den Social-Engineering-Link hereinfiel und darauf klickte, während die Browsersitzung mit der Finanzanwendung noch geöffnet war, forderte sein Browser die Anwendung auf, 100.000$ an das Konto von ShadyLady15 zu senden.
Das Skript könnte sogar in einem unsichtbaren Bild versteckt sein, das der Benutzer nicht sehen würde, das aber dennoch den Browser veranlassen könnte, die Anfrage zu stellen, wie folgt:
<img src="http://bank.com/transfer.do?acct=ShadyLady15&amount=100000" width="0" height="0" border="0">
Das Ergebnis ist dasselbe. ShadyLady15 erhält 100.000$, ohne dass jemand den Angriff bemerkt.
Warum ist CSRF so gefährlich?
CSRF-Angriffe sind heute aus dem gleichen Grund beliebt, aus dem Ransomware-Angriffe weiterhin die Runde machen. Es gibt nur sehr wenige Sprünge zwischen Angreifern und dem Geld eines Opfers. Bei einem Ransomware-Angriff werden Systeme verschlüsselt und Benutzer werden um Geld für die Entschlüsselung dieser Daten erpresst. Bei einem CSRF-Angriff sind es noch weniger Schritte. Wenn sie arbeiten, schicken die Opfer einfach Geld an die Angreifer, ohne es zu wissen.
Neben direkten Angriffen auf das Geld eines Opfers oder die Finanzen eines Unternehmens können erfolgreiche CSRF-Angriffe dazu verwendet werden, ein Netzwerk mithilfe gültiger Benutzer zu kompromittieren. Stellen Sie sich vor, ein Angreifer könnte einen CSRF-Exploit verwenden, um das Passwort eines Administrators zu ändern. Sie könnten dieses Passwort sofort verwenden, um Daten zu stehlen, Sicherheitslücken im Netzwerk zu öffnen oder Hintertüren zu installieren.
Obwohl es eine Menge Arbeit und bis zu einem gewissen Grad Glück ist, kann ein erfolgreicher CSRF-Angriff für Hacker unabhängig von ihrem ultimativen Ziel wie ein Lottogewinn sein. Bei einem Angriff auf ein Netzwerk wäre für fast jede andere Art von Angriff monatelange, langsame Aufklärungsarbeit erforderlich, um unter dem Radar der SIEM- und Cybersicherheitsteams zu bleiben. Im Gegensatz dazu können bei einem einzelnen CSRF-Angriff einige Schritte entlang der Cyber-Kill-Chain übersprungen werden, sodass sie ihrem ultimativen Ziel sehr nahe kommen.
Wie stoppe ich CSRF-Angriffe?
Im Gegensatz zu den meisten Sicherheitslücken liegt der Fehler bei CSRF-Angriffen nicht wirklich im Code, sondern in einem Exploit, den Angreifer erstellt haben, um einen Browser zu zwingen, Anfragen zu stellen, die ein Benutzer nicht möchte und von denen er möglicherweise nicht einmal weiß. Aber sie können besiegt werden.
Eine der besten Methoden besteht darin, Entwickler dazu zu bringen, der Identität eines Benutzers ein CSRF-Token hinzuzufügen, wenn eine neue Sitzung generiert wird. Es sollte aus einer Reihe eindeutiger und zufälliger Zeichen bestehen und für Benutzer unsichtbar sein. Fügen Sie als Nächstes die CSRF-Token-Anfrage als verstecktes Feld zu Formularen hinzu, die vom Server überprüft werden, wenn eine neue Anfrage eingereicht wird. Angreifer, die Anfragen über den Browser eines Benutzers einreichen, wissen nicht einmal von dem versteckten Token-Feld, geschweige denn, sie können herausfinden, um welches es sich handelt, sodass alle ihre Anfragen fehlschlagen.
Eine noch einfachere Methode, die nicht viel Programmierung erfordert, besteht darin, vertraulichen Dingen wie Passwortänderungsanfragen oder Geldüberweisungsaufträgen eine Captcha-Herausforderung hinzuzufügen. Es kann so einfach sein, einen Benutzer zu bitten, auf eine Schaltfläche zu klicken, um zu bestätigen, dass es sich bei dem Anforderer nicht um einen Roboter oder in diesem Fall um ein CSRF-Skript handelt. Angreifer werden nicht in der Lage sein, eine Antwort auf die Herausforderung zu schreiben, und Benutzer, die plötzlich eine CAPTCHA-Aufforderung erhalten, ohne zuvor etwas wie eine Geldtransferanfrage zu stellen, wissen, dass etwas nicht stimmt. Alternativ kann die Generierung eines Einmalkennworts mithilfe eines Drittanbieter-Tokens, z. B. eines Smartphones, verwendet werden, je nachdem, wie stark ein Unternehmen die Arbeit im Namen der Sicherheit verlangsamen möchte.
Schließlich haben viele Browser wie Microsoft Edge oder Google Chrome jetzt, obwohl es nicht unumstößlich ist Politik des gleichen Ursprungs Es gibt Einschränkungen, um Anfragen von allen außer dem lokalen Benutzer zu blockieren. Wenn Sie Benutzer dazu zwingen, mit Ihrer Website über die aktuellsten Versionen dieser Browser zu interagieren, kann dies dazu beitragen, eine weitere CSRF-Sicherheitsebene aufzubauen, ohne die Entwicklungsteams überhaupt zu belasten.
CSRF die Tür zuschlagen
Bei einem so hohen Auszahlungspotenzial werden CSRF-Angriffe wahrscheinlich nie vollständig verschwinden, aber wir hoffen, dass Sie erfahren haben, warum sie so hartnäckig sind und wie Sie sie endgültig von Ihrem Netzwerk fernhalten können.
Weitere Informationen finden Sie im OWASP Cross-Site Request Forgery Prevention Cheat Sheet, das als lebendes Dokument dient, das die Entwicklung dieser Sicherheitslücke dokumentiert. Wenn Sie Ihr Sicherheitswissen wirklich erweitern möchten, können Sie lernen, wie Sie diese und viele weitere Bedrohungen abwehren können, indem Sie die Sicherer Codekrieger Blog.
Denken Sie, Sie sind bereit, Ihr neues Defensivwissen auf die Probe zu stellen? Spiel ein bisschen mit dem kostenlose Demo der Secure Code Warrior-Plattform heute.
Klicken Sie auf den untenstehenden Link und laden Sie das PDF dieser Ressource herunter.
Secure Code Warrior für Ihr Unternehmen da, um Ihnen zu helfen, Code während des gesamten Softwareentwicklungszyklus zu sichern und eine Kultur zu schaffen, in der Cybersicherheit an erster Stelle steht. Ganz gleich, ob Sie AppSec-Manager, Entwickler, CISO oder jemand anderes sind, der sich mit Sicherheit befasst, wir können Ihrem Unternehmen helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Bericht ansehenEine Demo buchen
Jaap Karan Singh ist Secure Coding Evangelist, Chief Singh und Mitbegründer von Secure Code Warrior.
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 Anmeldeinformationen direkt von einem Benutzer zu stehlen. Dies bedeutet nicht, dass Webseitenbetreiber Sicherheitslücken im CSRF-Code ignorieren sollten, da letztlich für den Ersatz gestohlener Gelder im Falle eines rein monetären Angriffs die Hosting-Website mit dem unsicheren Code verantwortlich sein kann. Und wenn der Zielbenutzer stattdessen seine Anmeldeinformationen verliert oder sein Passwort unwissentlich geändert wird, kann ein Krimineller mit dieser gestohlenen Identität Chaos anrichten, insbesondere wenn das Opfer privilegierten Zugriff hat.
CSRF-Angriffe sind ziemlich komplex und basieren auf mehreren Ebenen, um erfolgreich zu sein. Mit anderen Worten, viele Dinge müssen zugunsten des Angreifers kaputt gehen, damit es funktioniert. Trotzdem sind sie ein äußerst beliebter Angriffsvektor, da ein erfolgreicher Angriff Geld direkt an einen Hacker überweisen oder ihn so einrichten kann, dass er sich ungestraft auf einer Website bewegen kann. Wenn alles in die Richtung eines Hackers geht, erfährt der Zielbenutzer möglicherweise nicht einmal, dass er Opfer eines Angriffs geworden ist.
Die gute Nachricht ist, dass, weil so viel richtig laufen muss, damit ein CSRF-Angriff funktioniert, es eine ganze Reihe großartiger Abwehrtechniken gibt, die sie aufhalten können.
Zu diesem Zweck werden wir drei wichtige Aspekte von CSRF-Angriffen erörtern:
- So funktionieren sie
- Warum sie so gefährlich sind
- Wie Sie Abwehrmechanismen einrichten können, um sie vor der Erkältung zu schützen.
Wie funktionieren CSRF-Angriffe?
Da erfolgreiche CSRF-Angriffe die Fähigkeit haben, direkt Geld, Waren oder Anmeldeinformationen von Zielnutzern zu stehlen, sind sie trotz des hohen Arbeitsaufwands, der zu ihrer Erstellung erforderlich ist, beliebt. Und weil sie oft auf verschiedenen Plattformen versucht werden, haben sie sich im Laufe der Jahre eine Vielzahl von Namen und Spitznamen angeeignet. Möglicherweise hören Sie CSRF-Angriffe, die als XSRF, Sea Surf, Session Riding, Cross-Site Reference Forgery oder Hostile Linking bezeichnet werden. Microsoft bezeichnet sie in den meisten seiner Dokumentation gerne als One-Click-Angriffe. Aber es sind alles CSRF-Angriffe, und die Techniken, um sie abzuwehren, sind identisch.
Ein CSRF-Angriff kann auftreten, 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 auf einer Website oder Anwendung authentifiziert sein muss. Der Angriff wird normalerweise von einer sekundären Website oder einer E-Mail aus gestartet. Oft verwenden Angreifer Social-Engineering-Techniken, um Benutzer dazu zu bringen, auf einen Link in einer E-Mail zu klicken, der sie zu einer gefährdeten Website mit dem Angriffsskript führt.
Die kompromittierte Website enthält ein Skript, das den aktiven Browser anweist, Befehle auszuführen, die normalerweise bösartig sind, wie das Ändern des Passworts eines Benutzers oder die Überweisung von Geld auf ein vom Angreifer kontrolliertes Konto. Solange der Benutzer authentifiziert ist, geht die Website davon aus, dass die Befehle vom autorisierten Benutzer ausgegeben werden. Warum sollte es das nicht tun? Der Benutzer hat sich bereits authentifiziert und alle Passwörter eingegeben, die für den Zugriff auf die Website erforderlich sind. Sie befinden sich möglicherweise sogar innerhalb eines Geofences und befinden sich direkt an ihrem Büroterminal. Wenn sie ihr Passwort ändern oder Geld überweisen möchten, gibt es keinen Grund, nicht zu glauben, dass sie es sind, die die Anfrage gestellt haben.
Wenn man die Elemente des Angriffs aufschlüsselt, ist klar, warum dieser Angriff für den Angreifer so schwierig durchzuführen ist. Zunächst muss der Benutzer aktiv bei der Site authentifiziert werden, auf der der Angriff stattfindet. Wenn eine E-Mail mit einem Angriffsskript eingeht, nachdem ein Benutzer seine Browsersitzung beendet oder sich abgemeldet hat, schlägt der Angriff fehl.
Der Angreifer ist außerdem gezwungen, auf der Zielseite viele Auskundungen durchzuführen, um zu wissen, welche Skripte diese Site akzeptiert. Angreifer können den Bildschirm eines Opfers nicht sehen, und jegliches Feedback von der Website geht an das Opfer, nicht an den Angreifer. Sofern der Angreifer nicht in der Lage ist, Beweise dafür zu sehen, dass sein Angriff funktioniert, z. B. wenn plötzlich Geld auf seinem Konto erscheint, wird er nicht einmal sofort wissen, ob der Angriff erfolgreich war.
Angesichts der schwierigen, aber nicht unmöglichen Parameter, dass der Benutzer zum Zeitpunkt des Angriffs angemeldet ist und weiß, welche Skripts die Zielseite akzeptiert, kann der Code zur Ausführung eines CSRF-Angriffs extrem einfach sein, obwohl er je nach Website selbst variiert.
Nehmen wir an, eine Bank- oder Finanzanwendung verwendet GET-Anfragen, um Geld zu überweisen, wie folgt:
HOLEN SIE SICH 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 Zielbenutzer jedoch eine E-Mail erhalten hat, vielleicht eine, die als von einem Kollegen getarnt ist, könnte ein CSRF-Angriffsskript in die Klickaktion eingebettet werden:
<a href="http://bank.com/transfer.do?acct=ShadyLady15&amount=100000">Können Sie diesen Quartalsbericht schnell durchlesen? <a></a></a>
Wenn der Zielbenutzer auf den Social-Engineering-Link hereinfiel und darauf klickte, während die Browsersitzung mit der Finanzanwendung noch geöffnet war, forderte sein Browser die Anwendung auf, 100.000$ an das Konto von ShadyLady15 zu senden.
Das Skript könnte sogar in einem unsichtbaren Bild versteckt sein, das der Benutzer nicht sehen würde, das aber dennoch den Browser veranlassen könnte, die Anfrage zu stellen, wie folgt:
<img src="http://bank.com/transfer.do?acct=ShadyLady15&amount=100000" width="0" height="0" border="0">
Das Ergebnis ist dasselbe. ShadyLady15 erhält 100.000$, ohne dass jemand den Angriff bemerkt.
Warum ist CSRF so gefährlich?
CSRF-Angriffe sind heute aus dem gleichen Grund beliebt, aus dem Ransomware-Angriffe weiterhin die Runde machen. Es gibt nur sehr wenige Sprünge zwischen Angreifern und dem Geld eines Opfers. Bei einem Ransomware-Angriff werden Systeme verschlüsselt und Benutzer werden um Geld für die Entschlüsselung dieser Daten erpresst. Bei einem CSRF-Angriff sind es noch weniger Schritte. Wenn sie arbeiten, schicken die Opfer einfach Geld an die Angreifer, ohne es zu wissen.
Neben direkten Angriffen auf das Geld eines Opfers oder die Finanzen eines Unternehmens können erfolgreiche CSRF-Angriffe dazu verwendet werden, ein Netzwerk mithilfe gültiger Benutzer zu kompromittieren. Stellen Sie sich vor, ein Angreifer könnte einen CSRF-Exploit verwenden, um das Passwort eines Administrators zu ändern. Sie könnten dieses Passwort sofort verwenden, um Daten zu stehlen, Sicherheitslücken im Netzwerk zu öffnen oder Hintertüren zu installieren.
Obwohl es eine Menge Arbeit und bis zu einem gewissen Grad Glück ist, kann ein erfolgreicher CSRF-Angriff für Hacker unabhängig von ihrem ultimativen Ziel wie ein Lottogewinn sein. Bei einem Angriff auf ein Netzwerk wäre für fast jede andere Art von Angriff monatelange, langsame Aufklärungsarbeit erforderlich, um unter dem Radar der SIEM- und Cybersicherheitsteams zu bleiben. Im Gegensatz dazu können bei einem einzelnen CSRF-Angriff einige Schritte entlang der Cyber-Kill-Chain übersprungen werden, sodass sie ihrem ultimativen Ziel sehr nahe kommen.
Wie stoppe ich CSRF-Angriffe?
Im Gegensatz zu den meisten Sicherheitslücken liegt der Fehler bei CSRF-Angriffen nicht wirklich im Code, sondern in einem Exploit, den Angreifer erstellt haben, um einen Browser zu zwingen, Anfragen zu stellen, die ein Benutzer nicht möchte und von denen er möglicherweise nicht einmal weiß. Aber sie können besiegt werden.
Eine der besten Methoden besteht darin, Entwickler dazu zu bringen, der Identität eines Benutzers ein CSRF-Token hinzuzufügen, wenn eine neue Sitzung generiert wird. Es sollte aus einer Reihe eindeutiger und zufälliger Zeichen bestehen und für Benutzer unsichtbar sein. Fügen Sie als Nächstes die CSRF-Token-Anfrage als verstecktes Feld zu Formularen hinzu, die vom Server überprüft werden, wenn eine neue Anfrage eingereicht wird. Angreifer, die Anfragen über den Browser eines Benutzers einreichen, wissen nicht einmal von dem versteckten Token-Feld, geschweige denn, sie können herausfinden, um welches es sich handelt, sodass alle ihre Anfragen fehlschlagen.
Eine noch einfachere Methode, die nicht viel Programmierung erfordert, besteht darin, vertraulichen Dingen wie Passwortänderungsanfragen oder Geldüberweisungsaufträgen eine Captcha-Herausforderung hinzuzufügen. Es kann so einfach sein, einen Benutzer zu bitten, auf eine Schaltfläche zu klicken, um zu bestätigen, dass es sich bei dem Anforderer nicht um einen Roboter oder in diesem Fall um ein CSRF-Skript handelt. Angreifer werden nicht in der Lage sein, eine Antwort auf die Herausforderung zu schreiben, und Benutzer, die plötzlich eine CAPTCHA-Aufforderung erhalten, ohne zuvor etwas wie eine Geldtransferanfrage zu stellen, wissen, dass etwas nicht stimmt. Alternativ kann die Generierung eines Einmalkennworts mithilfe eines Drittanbieter-Tokens, z. B. eines Smartphones, verwendet werden, je nachdem, wie stark ein Unternehmen die Arbeit im Namen der Sicherheit verlangsamen möchte.
Schließlich haben viele Browser wie Microsoft Edge oder Google Chrome jetzt, obwohl es nicht unumstößlich ist Politik des gleichen Ursprungs Es gibt Einschränkungen, um Anfragen von allen außer dem lokalen Benutzer zu blockieren. Wenn Sie Benutzer dazu zwingen, mit Ihrer Website über die aktuellsten Versionen dieser Browser zu interagieren, kann dies dazu beitragen, eine weitere CSRF-Sicherheitsebene aufzubauen, ohne die Entwicklungsteams überhaupt zu belasten.
CSRF die Tür zuschlagen
Bei einem so hohen Auszahlungspotenzial werden CSRF-Angriffe wahrscheinlich nie vollständig verschwinden, aber wir hoffen, dass Sie erfahren haben, warum sie so hartnäckig sind und wie Sie sie endgültig von Ihrem Netzwerk fernhalten können.
Weitere Informationen finden Sie im OWASP Cross-Site Request Forgery Prevention Cheat Sheet, das als lebendes Dokument dient, das die Entwicklung dieser Sicherheitslücke dokumentiert. Wenn Sie Ihr Sicherheitswissen wirklich erweitern möchten, können Sie lernen, wie Sie diese und viele weitere Bedrohungen abwehren können, indem Sie die Sicherer Codekrieger Blog.
Denken Sie, Sie sind bereit, Ihr neues Defensivwissen auf die Probe zu stellen? Spiel ein bisschen mit dem kostenlose Demo der Secure Code Warrior-Plattform heute.
Inhaltsverzeichnis
Jaap Karan Singh ist Secure Coding Evangelist, Chief Singh und Mitbegründer von Secure Code Warrior.
Secure Code Warrior für Ihr Unternehmen da, um Ihnen zu helfen, Code während des gesamten Softwareentwicklungszyklus zu sichern und eine Kultur zu schaffen, in der Cybersicherheit an erster Stelle steht. Ganz gleich, ob Sie AppSec-Manager, Entwickler, CISO oder jemand anderes sind, der sich mit Sicherheit befasst, wir können Ihrem Unternehmen helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Eine Demo buchenHerunterladenRessourcen für den Einstieg
Themen und Inhalte der Securecode-Schulung
Unsere branchenführenden Inhalte werden ständig weiterentwickelt, um der sich ständig ändernden Softwareentwicklungslandschaft unter Berücksichtigung Ihrer Rolle gerecht zu werden. Themen, die alles von KI bis XQuery Injection abdecken und für eine Vielzahl von Rollen angeboten werden, von Architekten und Ingenieuren bis hin zu Produktmanagern und QA. Verschaffen Sie sich einen kleinen Einblick in das Angebot unseres Inhaltskatalogs nach Themen und Rollen.
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: Beat the Boss KI-Missionen jetzt auf Abruf verfügbar
Cybermon 2025 Beat the Boss ist jetzt das ganze Jahr über in SCW verfügbar. Setzt fortschrittliche KI/LLM-Sicherheitsanforderungen ein, um die sichere KI-Entwicklung in einem großen Maßstab zu stärken.
Cyber-Resilienz-Gesetz erklärt: Was das für die Entwicklung von Secure by Design-Software bedeutet
Erfahren Sie, was der EU Cyber Resilience Act (CRA) verlangt, für wen er gilt und wie sich Entwicklungsteams mit sicheren Methoden, der Vorbeugung von Sicherheitslücken und dem Aufbau von Fähigkeiten für Entwickler darauf vorbereiten können.
Enabler 1: Definierte und messbare Erfolgskriterien
Enabler 1 eröffnet unsere zehnteilige Reihe „Enabler of Success“ und zeigt, wie sichere Codierung mit Geschäftsergebnissen wie Risikominderung und Geschwindigkeit verbunden werden kann, um eine langfristige Programmreife zu erreichen.
