Cisco Applied Mitigation Bulletin-
CSRF-Angriffe (Cross-Site Request Forgery) zielen in der Regel auf Webanwendungen ab. CSRF-Angriffe können das unbefugte Ändern von Benutzerinformationen oder das Extrahieren von benutzersensiblen Daten aus einer Webanwendung einschließen.
CSRF-Exploits nutzen Social Engineering, um einen Benutzer davon zu überzeugen, einen Link zu öffnen, der, wenn er von der betroffenen Web-Anwendung verarbeitet wird, zu einer beliebigen Codeausführung führen könnte. CSRF-Exploit-Code kann an einem Web-Speicherort (z. B. in einer gespeicherten CSRF-Instanz) in einem Einzelpixel-Bild gespeichert werden oder Bestandteil eines CSRF-Exploits sein. Bei der Verarbeitung kann der CSRF-Link es dem Angreifer ermöglichen, beliebige Anforderungen über die betroffene Webanwendung mit den Berechtigungen des Benutzers zu senden. Die Ursprünge von CSRF-Angriffen lassen sich mithilfe von Traceback-Methoden nur schwer identifizieren. Social Engineering-Methoden können die Identität des Angreifers verbergen, da der Server die Anfrage als legitime Anfrage des Benutzers behandelt.
Beispiel
Beispiele für CSRF-Angriffe sind zahlreich, am häufigsten ist jedoch eine Bankkontoübertragung. Angenommen, die Personalabteilung von Unternehmen X nutzt ein Webportal, das die Gehaltsinformationen der Mitarbeiter des Unternehmens aktualisiert. Um diesen Prozess auszuführen, muss die Personalabteilung folgende Schritte ausführen: sich bei der Webanwendung authentifizieren, zum Gehaltsbereich des Portals wechseln und ein Formular mit dem Namen des Mitarbeiters und der Höhe der Gehaltserhöhung ausfüllen. Nach Abschluss der vorherigen Schritte muss der Benutzer die Schaltfläche "Submit" (Senden) drücken, um das Formular zu verarbeiten und die Änderung durchzuführen. Angenommen, das eingereichte Formular wurde für einen Mitarbeiter namens John Doe eingereicht, der eine Gehaltserhöhung von 100 US-Dollar erhielt. Dadurch wird die folgende HTTP-POST-Anforderung generiert:
POST http://hr.companyX-internal.com/raisesalary.do HTTP/1.1 ... ... ... usr=JohnDoe&amount=100Je nach Anwendung kann ein Fall vorliegen, bei dem der Browser bereits über eine gültige authentifizierte Sitzung verfügt (Browser-Cookie). Wenn die Human Resources-Webanwendung über eine gültige Authentifizierungssitzung verfügt, wird die gleiche Aktion (z. B. Gehaltserhöhung) mit der folgenden HTTP GET-Anforderung ausgeführt:
GET http://hr.companyX-internal.com/raisesalary.do?usr=JohnDoe&amount=100 HTTP/1.1Die obige Anforderung kann durch einen Link und die Ausführung einer HTTP GET-Anforderung erfolgen. Der Browser muss nicht das Formular ausfüllen.
Die im obigen Beispiel beschriebene Human Resources Web-Anwendung ist anfällig für CSRF-Angriffe. Ein Benutzer (z. B. Karl Müller) könnte versuchen, sein Gehalt um 500 US-Dollar zu erhöhen, ohne Zugriff auf die Anwendung zu haben, könnte jedoch einen Mitarbeiter der Personalabteilung überzeugen, einen Link zu öffnen oder einen HTTP-Frame zu laden, der auf einen schädlichen Link umgeleitet wird (z. B. http://hr.companyX-internal.com/raisesalary.do?usr=JohnDoe&amount=500). Sobald der Mitarbeiter von der Personalanwendung authentifiziert wurde (z. B. zur Mittagszeit), kann der Mitarbeiter nur noch davon überzeugt werden, den Link zu besuchen.
-
CSRF-Angriffe (Cross-Site Request Forgery) zielen in der Regel auf Webanwendungen ab. Der Angreifer versucht, auf vertrauliche Informationen zuzugreifen und nicht autorisierte Änderungen an Benutzerdaten aus einer Web-Anwendung vorzunehmen, indem er einen Benutzer überzeugt, eine erstellte Web-Anwendungsanforderung auszuführen.
-
Schulung zur Benutzerschulung und Sicherheitsbewusstsein
Um das Risiko von CSRF-Angriffen zu reduzieren, wird empfohlen, Techniken für sicheres Surfen zu diskutieren. Angreifer verwenden webbasierte E-Mails als CSRF-Vektor, entweder durch eingebettetes Skripting oder durch schädliche Links, die zu einer CSRF-Ausnutzung führen. Eine Basisstrategie sollte Folgendes umfassen:
- Benutzern wird empfohlen, keine E-Mail-Nachrichten von verdächtigen oder unbekannten Quellen zu öffnen. Wenn Benutzer nicht überprüfen können, ob die in E-Mail-Nachrichten enthaltenen Links sicher sind, wird ihnen empfohlen, diese nicht zu öffnen.
- Es wird empfohlen, den Mauszeiger über den Link zu bewegen, um festzustellen, wohin der Link geleitet wird, bevor Sie auf den Link klicken bzw. diesen auswählen.
- Überprüfen Sie die Links auf verdächtig aussehende Zeichen.
- Es wird empfohlen, zwei verschiedene Browser zu verwenden. Einer sollte als vertrauenswürdiger Website-Browser und der andere für lässiges Surfen im Internet dienen. Wenn ein Link in einer E-Mail oder von einer Website eines sozialen Netzwerks ausgewählt wird, sollte der für gelegentliches Surfen im Internet verwendete Browser verwendet werden, um sicherzustellen, dass keine gültigen Cookies für einen CSRF-basierten Angriff vorhanden sind.
- Benutzer sollten vorsichtig sein, wenn Links vorhanden sind, für deren Authentifizierung ein Login erforderlich ist. (z. B. Banken oder die im obigen Beispiel beschriebene Personalwebsite)
- Seien Sie misstrauisch bei übermäßig langen Links.
- Greifen Sie nur auf Websites zu, die von bekannten und vertrauenswürdigen Standorten stammen. Wenn der Nutzer Bedenken hat, wenden Sie sich sofort an den Webmaster und das Unternehmen, das die Website hostet.
- Löschen Sie unerwünschte E-Mail-Nachrichten oder lesen Sie sie im Nur-Text-Format, um die Ausführung von schädlichem Code zu verhindern.
Sichere Entwicklungspraktiken für Webanwendungen
Die Verwendung sicherer Design- und Entwicklungsmethoden beim Design von Webanwendungen verringert das Risiko, dass Anwendungen erstellt werden, die anfällig für CSRF-Angriffe sind. Zu den sicheren Design- und Entwicklungspraktiken gehören:
- Hängen Sie für jede Benutzersitzung oder -anforderung unvorhersehbare Test-Token an. Mit dieser Methode wird sichergestellt, dass jede Anforderung überprüft wird, ob der Benutzer die Quelle und keine CSRF-Verbindung ist.
- Überprüfen Sie, ob eine Anforderung von der Site selbst oder von einer standortübergreifenden Anforderung ausgegeben wurde, indem Sie den HTTP-Referrer-Header überprüfen.
- Benutzerdefinierte HTTP-Header verwenden. Beispielsweise empfiehlt das Google Web Toolkit, einen X-CSRF-Cookie-Header an XMLHttpRequets anzufügen, der Schutz vor CSRF-Angriffen bieten kann.
Cisco Geräte
Aufgrund der Art der CSRF-Angriffe ist die Identifizierung der Absicht einer bestimmten URL (z. B. eine im obigen Beispiel beschriebene Gehaltserhöhung) schwierig. Daher ist die Identifizierung einer böswilligen Anforderung zwischen dem Benutzer und dem Server nicht immer möglich. Die besten Gegenmaßnahmen zur Eindämmung von CSRF-Angriffen sind sichere Verfahren für die Entwicklung von Webanwendungen und Benutzerschulungen. Cisco Sicherheitsprodukte (z. B. Cisco Ironport Web Security Appliances, Cisco ACE Web Application Firewall) können ein gewisses Maß an Schutz bieten, vor allem gegen Objekte, die schädliche Anfragen auslösen. Darüber hinaus können einige allgemeine Schutzmaßnahmen gegen Site-übergreifendes Scripting, die HTTP-Cookies und HTTP-Referrer-Header validieren, als Abwehr von CSRF-Angriffen dienen.
-
Den Unternehmen wird empfohlen, die potenziellen Auswirkungen dieser Schwachstelle anhand ihrer Standardprozesse zur Risikobewertung und -minderung zu ermitteln. Triage bezieht sich auf das Sortieren von Projekten und die Priorisierung von Bemühungen, die am wahrscheinlichsten erfolgreich sein werden. Cisco hat Dokumente bereitgestellt, die Unternehmen bei der Entwicklung einer risikobasierten Triage-Funktion für ihre Informationssicherheitsteams unterstützen. Risikoanalyse für Ankündigungen zu Sicherheitslücken sowie Risikoanalyse und -prototyping unterstützen Unternehmen bei der Entwicklung wiederholbarer Sicherheitsevaluierungs- und Reaktionsprozesse.
-
Vorsicht: Die Effektivität jeder Eindämmungstechnik hängt von spezifischen Kundensituationen wie Produktmix, Netzwerktopologie, Datenverkehrsverhalten und organisatorischem Auftrag ab. Prüfen Sie wie bei jeder Konfigurationsänderung die Auswirkungen dieser Konfiguration, bevor Sie die Änderung übernehmen.
CSRF lässt sich nicht ohne Weiteres von legitimen Webanfragen unterscheiden. Es gibt jedoch Cisco Produkte, die einen gewissen Schutz vor CSRF-Angriffen bieten können.
Das Cisco IronPort-Webreputations-Filtersystem umfasst Schutz vor Botsites, Erkennung von URL-Ausbrüchen und Exploit-Filterung, die Benutzer vor Exploits schützt, die über Cross Site Scripting (XSS), Cross Site Request Forgery (CSRF), SQL Injections oder unsichtbare iFrames verbreitet werden. Das Potenzial der Reputationstechnologie wird durch die auf Mustern basierenden Analyseverfahren des Systems und die Funktionen zum Scannen von Objekten abgeleitet. Weitere Informationen finden Sie auf der Website zur Cisco IronPort Web Reputation Technology.
Die Firewall-Richtlinie der ACE-Webanwendung kann verwendet werden, um Systeme vor Site-übergreifendem Skripting und Angriffen durch Anforderungsfälschung zu schützen, indem das Cookie- und Verweisfeld im HTTP-Header überprüft wird. Weitere Informationen finden Sie im Cisco ACE Web Application Firewall Getting Started Guide.
Das Cisco Intrusion Prevention System (IPS) bietet Schutz vor CSRF-Angriffen. Die folgende Liste enthält Informationen zu IPS-Signaturen (Cisco IPS Signature Update Version S704), die für aktuelle CSRF-Bedrohungen (März 2013) verwendet werden können:
- 1398/00 - Schwachstelle bei Website-übergreifendem Microsoft Outlook Web Access-Request Forgery
- 1881/0 - D-Link DSL-2640B Redpass.CGI Site-übergreifendes Forgery Schwachstelle
- 1930/00 - Sicherheitslücke bei websiteübergreifender WordPress-Anforderung für Fälschung
-
Dieses Dokument wird in der vorliegenden Form bereitgestellt und impliziert keine Garantie oder Gewährleistung, einschließlich der Gewährleistung der Marktgängigkeit oder Eignung für einen bestimmten Zweck. Die Nutzung der Informationen im Dokument oder den Materialien, die mit dem Dokument verknüpft sind, erfolgt auf Ihr eigenes Risiko. Cisco behält sich das Recht vor, dieses Dokument jederzeit zu ändern oder zu aktualisieren.
-
Weniger anzeigen
-
Vollständige Informationen zur Meldung von Sicherheitslücken in Cisco Produkten, zum Erhalt von Unterstützung bei Sicherheitsvorfällen und zur Registrierung für den Erhalt von Sicherheitsinformationen von Cisco finden Sie auf der weltweiten Cisco Website unter https://sec.cloudapps.cisco.com/security/center/resources/security_vulnerability_policy.html. Dies beinhaltet Anweisungen für Presseanfragen bezüglich der Sicherheitshinweise von Cisco. Alle Cisco Sicherheitsankündigungen finden Sie unter http://www.cisco.com/go/psirt.
-
Die Sicherheitslücke betrifft die folgenden Produktkombinationen.
Primäre Produkte Cisco Cisco Web Security Appliance (WSA) 7,1 (.0, .1, .2, .3, .4) | 7,5 (.0-000, .1-000) | 7,7 (.0-000) Cisco E-Mail Security Appliance (ESA) 7,1 (.0, .1, .2, .3, .4, .5) | 7,3 (.0, .1, .2) | 7,5 (.0, .1, .2) | 7,6 (.0, .1-000, .2) Cisco Content Security Management Appliance (SMA) 7,2 (.0, .1, .2) | 7,7 (.0, .1) | 7,9 (.0, .1)
Zugehörige Produkte
-
Dieses Dokument wird in der vorliegenden Form bereitgestellt und impliziert keine Garantie oder Gewährleistung, einschließlich der Gewährleistung der Marktgängigkeit oder Eignung für einen bestimmten Zweck. Die Nutzung der Informationen im Dokument oder den Materialien, die mit dem Dokument verknüpft sind, erfolgt auf Ihr eigenes Risiko. CISCO BEHÄLT SICH DAS RECHT VOR, WARNUNGEN JEDERZEIT ZU ÄNDERN ODER ZU AKTUALISIEREN.
Eine eigenständige Kopie oder Umschreibung des Texts in diesem Dokument, die die Verteilungs-URL auslässt, ist eine unkontrollierte Kopie und enthält möglicherweise keine wichtigen Informationen oder sachliche Fehler. Die Informationen in diesem Dokument sind für Endbenutzer von Cisco Produkten bestimmt.