Wir haben beschlossen, die groß angelegte Forschungsarbeit von 2015 zu wiederholen und die Sicherheit der Webressourcen der weltweit führenden Banken zu analysieren. Seitdem hat sich das Online-Banking nicht nur weiter verbreitet, sondern sogar verbreitet. Es ist zwar schnell und bequem, aber wie sicher? Befolgen Banken Best Practices?

Wie beim letzten Mal haben wir im Rahmen der Recherche normale HTTP- und DNS-Anfragen gesendet, ohne die Banken zu stören. Das heißt, alle Daten werden wie ein normaler Benutzer beim Besuch einer Ressource gesammelt. Für die Analyse haben wir 200 russische und 400 ausländische Banken ausgewählt. Unterbrochene Auszüge aus der Studie. Der vollständige Text ist auf unserer Website zu finden.

Dieses Mal haben wir das Forschungsfeld erweitert, indem wir den Umfang um Online-Ressourcen ausländischer Banken erweitert haben. Auf diese Weise können Sie die Einstellung zur Websicherheit in Russland und anderen Ländern der Welt vergleichen.

Mit Blick auf die Zukunft müssen wir leider feststellen, dass die klassischen Methoden zur Erhöhung des Sicherheitsniveaus von Banken häufig ignoriert werden, obwohl sie keine globalen finanziellen und technischen Ressourcen erfordern. Gelegenheiten zu verpassen ist freiwillig, aber es ist völlig anders, sie falsch zu verwenden. Im Fall der Inhaltssicherheitsrichtlinie verfügt beispielsweise ein Fünftel aller berücksichtigten Ressourcen über Einstellungen, und bei fast jeder von ihnen sind Konfigurationsfehler aufgetreten. Im Rahmen der Studie haben wir versucht, im Detail zu überlegen, wie man mit diesen Einstellungen richtig arbeitet und welche Fehler am häufigsten gemacht werden.

Forschungszweck

Das Hauptziel der Studie ist die Bewertung des Sicherheitsniveaus öffentlich verfügbarer Bankressourcen: der offiziellen Website und der RBS gemäß den Best Practices für die Einrichtung von Webressourcen. Wir haben eine Reihe von Punkten ausgewählt, deren Einhaltung überprüft werden kann, ohne technische Schäden zu verursachen und ohne die Bank zu stören. Es ist wichtig zu beachten, dass alle von uns gesammelten Informationen gemeinfrei sind und die Bearbeitung dieser Daten keine gründlichen Kenntnisse erfordert: Wenn Sie möchten, kann jeder interessierte Benutzer zu solchen Ergebnissen kommen.

Gegenstand der Studie

Zum Testen nahmen wir die TOP-200-Banken in Russland. Die vollständige Liste finden Sie unter: http://www.banki.ru/banks/ratings/ (aktuelle Daten Stand März 2019).

Im ersten Schritt haben wir alle offiziellen Websites und Internetressourcen des RB für Einzelpersonen und juristische Personen identifiziert. Anschließend wurden für jede Bank Prüfungen unter Verwendung mehrerer Standardanforderungen unter Verwendung der HTTP / HTTPS / DNS-Protokolle durchgeführt, ähnlich den üblichen Anforderungen von Bankkunden. Gruppierte Liste:

1. SSL-Einstellungen - bieten die Möglichkeit, einen der vielen mit SSL verbundenen Angriffe zu implementieren.
2. DNS-Einstellungen - Mit diesen Einstellungen können Sie Informationen zu Unternehmens-Subdomänen abrufen.

Das Folgende ist eine Beschreibung und die Ergebnisse einiger Überprüfungen. Besonderes Augenmerk legen wir auf den Abschnitt zur Inhaltssicherheitspolitik: In diesem Abschnitt haben wir versucht, die wichtigsten Fehler hervorzuheben und zu erläutern, wie sie vermieden werden können. Eine vollständige Beschreibung und die Ergebnisse aller Kontrollen sind in der Studie enthalten .

Testen

SSL / TLS

Einer der wichtigsten Punkte ist die Überprüfung der SSL / TLS-Einstellungen von Diese kryptografischen Protokolle sind heute die beliebteste Methode für den sicheren Datenaustausch über das Internet. Die größte potenzielle Bedrohung ist die Verwendung von Verkehrsüberwachungsangriffen.
Folgende Prüfungen wurden ausgewählt:

Bewertung

SSL / TLS verfügt über eine Vielzahl von Einstellungen und Funktionen, die in gewissem Maße die Sicherheit der Verbindung selbst und ihrer Teilnehmer insgesamt beeinträchtigen. Um eine Gesamtbewertung dieser Einstellung durchzuführen, haben wir die von Qualys (www.ssllabs.com) bereitgestellten Funktionen verwendet. Auf der Grundlage zahlreicher Parameter kann eine allgemeine Bewertung von A bis F erstellt werden, wobei „A +“ das beste Ergebnis ist, das in Bezug auf die Sicherheit erzielt werden kann. Nur sehr wenige Unternehmen, selbst die größten Internetunternehmen, haben es. Dementsprechend ist "F" das schlechteste Ergebnis. Es kann abgerufen werden, wenn der Server einer kritischen Sicherheitsanfälligkeit ausgesetzt ist, veraltete Protokolle unterstützt und andere Probleme aufweist. Wie bei der Bewertung „A +“ ist das schlechteste Ergebnis selten und wird hauptsächlich mit unprofessionellen Mitarbeitern in Verbindung gebracht.

Der Prozentsatz der Bewertungen unter "A" wird auf der Karte angezeigt. Je höher dieser Prozentsatz ist, desto schlechter ist die Situation mit der Websicherheit im Land.

HTTP-Header

Mit den Headern in der Antwort des Webservers können Sie das Verhalten des Browsers in bestimmten Situationen bestimmen. Ihre Anwesenheit hilft, einige Angriffe zu vermeiden oder ihr Verhalten zu erschweren, während das Hinzufügen eines Headers keine komplexen Aktionen oder Einstellungen erfordert. Einige Einstellungen, z. B. CSP, zeichnen sich jedoch durch zu viele Optionen aus, deren falsche Verwendung die Illusion von Sicherheit hervorrufen oder sogar die Funktionalität einer Site beschädigen kann. Wir haben die folgenden Überschriften überprüft:

Wenn die ersten zehn Überschriften „positiv“ sind und es wünschenswert (richtig!) Ist, sie zu verwenden, dann „teilen“ die letzten drei dem Angreifer mit, welche Technologien verwendet werden. Natürlich sollten solche Überschriften verworfen werden.

Bewertung

Die richtige Kombination von HTTP-Headern ermöglicht es Ihnen, die Sicherheit der Site zu gewährleisten, während das Einrichten überhaupt nicht schwierig ist. Wir haben Daten zur Verwendung von HTTP-Headern gesammelt und darauf basierend eine Sicherheitsbewertung für Webressourcen erstellt.
Für die Einhaltung der folgenden Parameter haben wir Punkte vergeben oder vergeben:

Bewertung von „D“ bis „A +“, wobei „A +“ das beste Ergebnis ist, das in Bezug auf die Sicherheit erzielt werden kann. Das schlechteste Ergebnis war jedoch ziemlich selten, wie das beste.

Bewertungsverteilung

Der Prozentsatz der Bewertungen unter "A" wird auf der Karte angezeigt. Je höher dieser Prozentsatz ist, desto schlimmer ist die Situation mit der Websicherheit im Land.

Inhaltssicherheitsrichtlinie

Eine „Content Protection Policy“ oder CSP ist eine der wichtigsten Möglichkeiten, um die mit der Ausnutzung von XSS-Angriffen verbundenen Risiken zu verringern. Mit diesem Tool kann der Site-Administrator festlegen, welche Webressourcen auf den Seiten verwendet werden dürfen - Schriftarten, Stile, Bilder, JS-Skripte, SWF-Dateien usw. Welche Browser CSP unterstützen, erfahren Sie hier .

Dank CSP können Sie vollständig verhindern, dass der Browser beispielsweise Flash-Objekte lädt oder die weiße Liste der Domänen anpasst. In diesem Fall zeigt der Browser nur die SWFs an, die sich in der zulässigen Domäne befinden. Ein weiterer Vorteil, den die CSP-Richtlinie bietet, ist die Möglichkeit, sich schnell über das Auftreten von neuem XSS in der Größe einer kontrollierten Ressource zu informieren. Bei Verwendung der Option "report-uri" sendet der Browser des Angreifers oder des Opfers einen Bericht an die angegebene URL, sobald der CSP ausgelöst wird.

Unter den Hauptfehlern im Zusammenhang mit der CSP-Richtlinie können die folgenden Kategorien unterschieden werden:

1. Falsche Konfiguration
   
   • Fehlende Anweisungen (script-src | object-src | default-src | base-uri)
   • Redundante Optionen (unsafe-inline | unsafe-eval | https: | data: | *)
2. Schwächen der Hosts und Whitelisting
   
   • Möglichkeit, beliebige JS-Dateien zu laden
   • Rückrufe
   • Skript-Gadgets in Angular- und ähnlichen Template-Engines
3. JS-freie Angriffe ("scriptless")
   
   • Leckage durch nicht geschlossene Tags
   • Implementieren Sie Phishing-Formulare

Detailliertere Informationen, konkrete Fehlerbeispiele und Möglichkeiten zu deren Vermeidung finden Sie im Volltext der Studie .

Das Hauptziel von CSP besteht darin, die Wahrscheinlichkeit zu verringern, dass XSS-Angriffe ausgenutzt werden, aber wie Untersuchungen gezeigt haben, schaffen es nur wenige, diese Richtlinie korrekt zu konfigurieren: Nur 3% verwenden CSP.
Die Grafik zeigt die häufigsten Fehler in den überprüften CSP-Sites.

Strenge Transportsicherheit

Mit der Sicherheitsrichtlinie HSTS (HTTP Strict Transport Security) können Sie eine sichere Verbindung herstellen, anstatt das HTTP-Protokoll zu verwenden. Verwenden Sie dazu den Strict-Transport-Security-Header, der den Browser zwingt, die Verwendung von HTTPS zu erzwingen. Dies verhindert einige MITM-Angriffe, insbesondere Angriffe mit einem geringeren Schutzgrad und Diebstahl von Cookies. Das Prinzip des Mechanismus ist wie folgt: Wenn Sie eine Site zum ersten Mal mit dem HTTP (S) -Protokoll besuchen, erhält der Browser den Header "Strict-Transport-Security" und merkt sich, dass Sie beim erneuten Versuch, eine Verbindung zu dieser Site herzustellen, nur HTTPS verwenden müssen.
Dies verhindert ein Szenario, in dem ein Angreifer, der HTTP-Anforderungen abfängt, den Benutzer auf die Klonseite umleitet, um seine Daten abzurufen.

Prozentsatz der Banken, die den HTTP-Header Strict-Transport-Security verwenden

Cookie setzen

Nachdem der Server die HTTP-Anfrage erhalten hat, kann er den Set-Cookie-Header zusammen mit der Antwort senden.
Cookies mit dem Secure-Flag werden nur dann an den Server gesendet, wenn die Anforderung über SSL und HTTPS erfolgt. Wichtige Daten sollten jedoch niemals in einem Cookie übertragen oder gespeichert werden, da sein Mechanismus sehr anfällig ist und das Secure-Flag keine zusätzlichen Verschlüsselungs- oder Sicherheitsmaßnahmen bietet. Auf Cookies mit dem HTTPonly-Flag kann über JavaScript nicht über die API-Eigenschaften von Document.cookie zugegriffen werden. Dies hilft, den Diebstahl des Cookies vom Client im Falle eines XSS-Angriffs zu vermeiden. Dieses Flag sollte für Cookies gesetzt werden, auf die nicht über JavaScript zugegriffen werden muss. Insbesondere wenn Cookies nur zur Unterstützung der Sitzung verwendet werden, werden sie in JavaScript nicht benötigt und Sie können das HTTPOnly-Flag verwenden. Ohne die Flags HTTPOnly und Secure im HTTP-Antwortheader können Sie eine Webanwendungssitzung und Cookies stehlen oder verarbeiten.

Sichere und HTTPonly-Flags in diesem Header werden nicht häufiger als auf jeder zweiten offiziellen Website der Bank in Bosnien und Herzegowina, Japan, China, Brasilien, Bulgarien, Luxemburg, Finnland, Israel, Frankreich, Großbritannien und Spanien gefunden.
Unter DBO für physikalische. Personen - China, Irland, Israel und Japan.
Unter RBS für jur. Personen - Bosnien und Herzegowina, Brasilien und China.

Die Statistiken der russischen Banken lauten wie folgt:
Offizielle Website der Bank - 42%;
RBS für physische. Personen - 37%;
RBS für legal Personen - 67%.

Server-Header

In diesem Header wird angegeben, auf welcher Software der Webserver ausgeführt wird. Dies kann beispielsweise die folgende Bedeutung haben:

Server:Apache/2.4.12 (Unix) mod_wsgi/3.5 Python/2.7.5 OpenSSL/1.0.1l 

Die Offenlegung dieser Informationen stellt keine direkte Bedrohung dar, kann jedoch die Zeit des Angriffs verkürzen. Anstatt nach einer bestimmten Sicherheitsanfälligkeit zu suchen, können Sie sofort nach Daten für eine bestimmte Version der Software suchen. Beispielsweise wurden während der Studie die folgenden Daten gefunden:

Die Studie ergab, dass 64% der Websites von Banken eine Serverversion melden, während 24% dieser Server anfällig sind.

Fazit

Nachdem wir eine allgemeine Vorstellung von der Sicherheit der Webressourcen der Bank erhalten hatten, kamen wir zu dem Hauptfazit: Viele Banken vernachlässigen sogar die gängigsten und am einfachsten umzusetzenden Tipps zur Verbesserung der Sicherheit ihrer Webressourcen.

Die entdeckten Sicherheitslücken und Fehler ermöglichen es Angreifern, Angriffe auf Ressourcen ohne großen Aufwand auszuführen. Die Folgen dieser Angriffe sind jedoch sehr schwerwiegend: Bargeldverluste von Kunden, finanzielle und Reputationsverluste der Bank, auch langfristig. Nur wenige vertrauen ihr Geld einer Bank an, deren Ruf durch Sicherheitsvorfälle getrübt wird.

Das Befolgen der Standardpraxis zur Erhöhung des Sicherheitsniveaus - Suchen und Schließen von Schwachstellen - zahlt sich natürlich aus und minimiert Risiken. Die meisten Entwickler von Banking-Webanwendungen vergessen jedoch die einfachsten Empfehlungen und Methoden, die das Risiko erheblich verringern oder die Ausnutzung von Sicherheitsanfälligkeiten erschweren können (z. B. das Ausblenden von Informationen über die verwendete Software oder die Installation von CSP aus den Server-Headern). Die Vorteile der Verwendung solcher Technologien sind nicht sofort sichtbar, aber möglicherweise überhaupt nicht offensichtlich: Wenn ein Angreifer auf sie gestoßen ist, kann er keinen Angriff ausführen, und seine Aktionen bleiben für die für die Sicherheit Verantwortlichen außer Sicht.

Nachdem wir die Webressourcen russischer Banken aus verschiedenen Blickwinkeln untersucht hatten, stellten wir fest, dass in ihnen immer noch bekannte Schwachstellen und Sicherheitsprobleme vorhanden sind. So können sich Angreifer auf die erfolgreiche Umsetzung von Angriffen auf diese Finanzinstitute verlassen. Und je mehr Probleme auftreten, desto höher sind die finanziellen und Reputationsrisiken der Banken.
Die Situation in der Welt insgesamt ist nicht besonders unterschiedlich. Unter den deutlich hinterherhinkenden Sicherheitsaspekten sind Online-Banking-Ressourcen der folgenden Länder zu finden: China, Japan, Brasilien, Israel, Spanien. Paradoxerweise achten ausländische Banken in den meisten Fällen mehr auf die Sicherheit ihrer Hauptseiten als auf das Bankensystem. Es ist anzumerken, dass der Anteil der Analyse ausländischer Banken an der Studie nicht so umfangreich ist und vielmehr eine Einarbeitung darstellt.