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 là pour aider votre entreprise à sécuriser le code tout au long du cycle de développement logiciel et à créer une culture où la cybersécurité est une priorité. Que vous soyez responsable de la sécurité des applications, développeur, responsable de la sécurité des systèmes d'information ou toute autre personne impliquée dans la sécurité, nous pouvons aider votre entreprise à réduire les risques liés à un code non sécurisé.
Réserver une démonstration
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.
Veuillez cliquer sur le lien ci-dessous et télécharger le PDF de cette ressource.
Secure Code Warrior là pour aider votre entreprise à sécuriser le code tout au long du cycle de développement logiciel et à créer une culture où la cybersécurité est une priorité. Que vous soyez responsable de la sécurité des applications, développeur, responsable de la sécurité des systèmes d'information ou toute autre personne impliquée dans la sécurité, nous pouvons aider votre entreprise à réduire les risques liés à un code non sécurisé.
Consulter le rapportRéserver une démonstration
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.
Table des matières
Jaap Karan Singh ist Secure Coding Evangelist, Chief Singh und Mitbegründer von Secure Code Warrior.
Secure Code Warrior là pour aider votre entreprise à sécuriser le code tout au long du cycle de développement logiciel et à créer une culture où la cybersécurité est une priorité. Que vous soyez responsable de la sécurité des applications, développeur, responsable de la sécurité des systèmes d'information ou toute autre personne impliquée dans la sécurité, nous pouvons aider votre entreprise à réduire les risques liés à un code non sécurisé.
Réserver une démonstrationTéléchargerRessources pour débuter
Thèmes et contenus de la formation Securecode
Nos contenus de pointe sont constamment développés afin de s'adapter à l'évolution constante du paysage du développement logiciel, en tenant compte de votre rôle. Les thèmes abordés couvrent tous les domaines, de l'IA à l'injection XQuery, et sont proposés pour une multitude de rôles, des architectes et ingénieurs aux chefs de produit et responsables assurance qualité. Nous vous invitons à découvrir un aperçu de notre catalogue de contenus classés par thème et par rôle.
La Chambre de commerce établit la norme en matière de sécurité à grande échelle axée sur les développeurs
La Chambre de commerce néerlandaise explique comment elle a intégré le codage sécurisé dans le développement quotidien grâce à des certifications basées sur les rôles, à l'évaluation comparative du Trust Score et à une culture de responsabilité partagée en matière de sécurité.
%20(1).avif)
.avif)
Modélisation des menaces avec l'IA : transformer chaque développeur en modélisateur de menaces
Vous repartirez mieux équipé pour aider les développeurs à combiner les idées et les techniques de modélisation des menaces avec les outils d'IA qu'ils utilisent déjà pour renforcer la sécurité, améliorer la collaboration et créer des logiciels plus résilients dès le départ.
Ressources pour débuter
Cybermon est de retour : les missions KI « Beat the Boss » sont désormais disponibles sur demande.
Cybermon 2025 Beat the Boss est désormais disponible toute l'année dans SCW. Il utilise des exigences de sécurité IA/LLM avancées pour renforcer le développement sécurisé de l'IA à grande échelle.
Explication de la loi sur la cyber-résilience : implications pour le développement de logiciels sécurisés dès la conception
Découvrez les exigences de la loi européenne sur la cyber-résilience (CRA), à qui elle s'applique et comment les équipes de développement peuvent s'y préparer en adoptant des méthodes sécurisées, en prévenant les failles de sécurité et en renforçant les compétences des développeurs.
Facteur 1 : Critères de réussite définis et mesurables
Le catalyseur n° 1 inaugure notre série en dix parties intitulée « Les catalyseurs de la réussite » et démontre comment un codage sécurisé peut être associé à des résultats commerciaux tels que la réduction des risques et la rapidité afin d'atteindre une maturité programmatique à long terme.
