Wie Reverse Proxies die Sicherheit Ihrer Webanwendung verbessern

Es ist kein Geheimnis, dass Unternehmen in der heutigen Zeit zunehmend Webanwendungen nutzen. Mit Webanwendungen lassen sich Unternehmensabläufe bequem rationalisieren, die Effizienz steigern und somit Kosten für Aufgaben sparen, die sonst manuell erledigt werden müssten. Trotz ihrer wachsenden Beliebtheit sind Webanwendungen anfällig für Risiken und Cyberangriffe. Dieser Artikel gibt einen Einblick

Es ist kein Geheimnis, dass Unternehmen in der heutigen Zeit zunehmend Webanwendungen nutzen. Mit Webanwendungen lassen sich Unternehmensabläufe rationalisieren, die Effizienz steigern und damit Kosten für Aufgaben sparen, die sonst manuell erledigt werden müssten.

Webanwendungen sind trotz ihrer wachsenden Beliebtheit anfällig für Risiken und Cyberangriffe. Dieser Artikel gibt einen Einblick in die wichtigsten Angriffe, denen eine Webanwendung ausgesetzt ist. Anschließend erfahren Sie, wie Sie einen Reverse-Proxy einbauen können, um die Bedrohungen zu minimieren.

Doch bevor wir uns mit den Sicherheitsaspekten befassen, sollten wir einen Blick auf die Architektur einer typischen Webanwendung werfen.

Überblick über die Architektur von Webanwendungen

Web-Anwendung

In den meisten Fällen bestehen Webanwendungen aus Webservern und Webseiten. Webserver nehmen Anfragen von Clients (Ihren Webbrowsern) entgegen, die ein Webserver verarbeitet und die Antwort an den Client zurückschickt.  

Während die Serverseite mit dynamischen Programmiersprachen wie PHP, Python, ASP.NET usw. kodiert wird, wird die Clientseite mit HTML, CSS und JavaScript kodiert. Die Kommunikation zwischen Client und Server erfolgt über das HTTP-Protokoll.

Weitere Informationen über die Struktur von Webanwendungen finden Sie in diesem Artikel. Die folgende Abbildung zeigt eine typische Client-Server-Kommunikation.

Die gesamte Kommunikation scheint in dem obigen Diagramm einfach zu sein, da die Anfragen zwischen dem Client und dem Server hin und her gehen. Dies ist jedoch nicht immer der Fall.

Leider sind Webanwendungen mit dem oben beschriebenen Design anfällig für Cyberangriffe durch Außenstehende zwischen dem Client und dem Server.

Werfen wir einen Blick auf einige der interessantesten Statistiken zu Cyberangriffen, bevor wir uns mit der Art dieser Angriffe befassen.

Was sind die wichtigsten Bedrohungen für eine Webanwendung?

Spannende Statistiken über Cyberangriffe

Laut den Daten von Positive Technologies zu Schwachstellen in Webanwendungen aus dem Jahr 2018 entfallen 28 % aller angegriffenen Webanwendungen auf die Finanz- und Bankbranche. Die Studie zeigt auch, dass 14 % der Cyberangriffe auf Online-Anwendungen in der Telekommunikations- und Fertigungsbranche und 11 % auf Anwendungen im Transportwesen abzielen.

Andere Branchen, die Risiken ausgesetzt sind, sind staatliche Einrichtungen (11 %), IT, E-Commerce und die Massenmedien.

Was die Art der Angriffe betrifft, so stellt ein anderer Bericht von F5 fest, dass Cross-Site-Scripting (von 4 % auf 54 %) und SQL-Injection (SQLi)-Angriffe (von 15 % auf 76 %) zunehmen. 

Aus diesen Statistiken lässt sich schließen, dass einige strenge Maßnahmen erforderlich sind, um Webanwendungen vor Sicherheitslücken zu schützen. Einige der Sicherheitsmängel sind auf Probleme bei der Codierung zurückzuführen, während andere Gründe auf eine unzureichende Infrastruktur der Webanwendung zurückzuführen sein könnten. Hier kommt die Web Application Firewall (WAF) ins Spiel, die Schwachstellen minimieren kann, indem sie Pakete filtert, den HTTP-Verkehr blockiert und unerlaubte Protokolle erstellt. 

Wir werden dies weiter unten näher untersuchen. Zuvor noch ein kurzer Überblick über die wichtigsten Sicherheitsbedrohungen.

SQL-Injektion (SQLi)

SQLi -SQL-Injection ist eine Sicherheitslücke im Internet, die es dem Angreifer ermöglicht, SQL-Abfragen einer Anwendung an die Datenbank zu manipulieren. Auf diese Weise erhalten sie Zugang zu potenziell wertvollen Informationen, die für andere nicht ohne weiteres zugänglich sind. 

Ein einfaches, sehr bekanntes Beispiel wäre die Ausnutzung von unsanierten Benutzereingaben zum Vorteil des Hackers. Nehmen wir an, dass es ein Textfeld gibt, das die Benutzer-ID abfragt. Auf der Grundlage der Benutzer-ID ruft die Abfrage dann alle Informationen ab, die zu diesem Benutzer gehören.

Nehmen wir also an, der Benutzer hätte in das Textfeld die folgenden Angaben eingegeben:

Benutzer-ID: 228 oder 1=1

Die resultierende Abfrage wäre dann die folgende:

SELECT * FROM Benutzer WHERE UserId = 228 OR 1=1;

Dann werden alle Daten in der Tabelle des Benutzers abgerufen, einschließlich der Kennwörter, wenn die Tabelle Kennwortdaten enthält.

Für weitere Informationen über SQLi können Sie hier nachlesen.

Cross-Site Scripting (XSS)

XSS tritt auf, wenn ein Benutzer ein bösartiges Skript hauptsächlich in Javascript über nicht sanitisierte Eingabefelder einschleust. Normalerweise sendet ein Angreifer dieses bösartige Skript an einen Benutzer, der nicht verdächtigt wird. Der Browser des Endbenutzers weiß nicht, dass dieses Skript schädlich ist und führt es aus. 

Infolgedessen kann dieses bösartige Skript auf alle Daten zugreifen, die mit Cookies, Sitzungs-Tokens oder anderen sensiblen Informationen verbunden sind. Außerdem können diese Skripte den HTML-Code einer Webseite umschreiben.

Fehlerhafte Authentifizierung und Sitzungsverwaltung

Angenommen, ein Benutzer muss sich mit seinen Anmeldedaten bei einer Webanwendung anmelden. In diesem Fall erzeugt der proprietäre Algorithmus der Website eine eindeutige Sitzungs-ID für die gesamte Kommunikation zwischen dem Benutzer und dem Webserver für diese Sitzung.

Wenn die Webentwickler die Daten, die zwischen dem Benutzer und dem Webserver hin- und hergehen, nicht verschlüsselt haben, ist die Wahrscheinlichkeit groß, dass ein Eindringling sie stehlen und als Benutzer auftreten kann. Dieses Szenario tritt vor allem dann auf, wenn Sie sich über das öffentliche WLAN in Cafés ins Internet einloggen.

Weitere Einzelheiten finden Sie in diesem Artikel.

Welche Methoden gibt es, um Webangriffe zu verhindern?

Web-Anwendungs-Firewall

WAF ist eine Verteidigungsmaßnahme der Schicht 7 im OSI-Modell, die am Eingangspunkt des Zielservers platziert werden kann, wie in der folgenden Abbildung dargestellt. Sie schützt das interne Netzwerk des Servers vor Angriffen und verbirgt die Netzwerktopologie des Servers.

Damit die WAF funktioniert, müssen Sie zusätzliche Konfigurationen auf dem Server vornehmen. Wie die Firewalls filtert die WAF ein- und ausgehenden HTTP-Verkehr, der für das interne Netzwerk des Servers gefährlich erscheint, wenn er nicht den Regeln entspricht, die Sie in der WAF festgelegt haben.

WAF ist auch eine Art von Reverse Proxy, auf den wir im nächsten Abschnitt eingehen werden.

Umgekehrter Proxy

Die Aufgabe eines Proxy-Servers ist es, Ihre IP-Adresse zu verbergen und sie durch die des Proxy-Servers zu ersetzen. Ein Reverse-Proxy tut dasselbe und erhöht die Sicherheit des Webservers, indem er ihn und die interne Netzwerktopologie des Servers verbirgt.

Der Client kennt nur die Adresse des Proxy-Servers, so dass der eigentliche Server für den Client verborgen bleibt.

Im Idealfall können Sie einen Reverse-Proxy als Web Application Firewall (WAF) verwenden, die wir oben beschrieben haben. Sie können WAF für Webanwendungen auf Geräten mit konfiguriertem Reverse-Proxy implementieren. Dadurch wird der Anwendungsbereich der WAF bei der Verbesserung der Sicherheit größer. Der Angreifer kann auch den tatsächlichen Standort des Webservers nicht sehen.

Weitere grundlegende Informationen über Reverse-Proxys finden Sie in diesem Artikel. Im nächsten Abschnitt werden wir uns mit der Verwendung eines Reverse-Proxys befassen, um die Anwendungsrisiken zu mindern. Zuvor wollen wir Ihnen jedoch einen Überblick darüber geben, was ein Reverse-Proxy leistet.

Wie funktioniert der Reverse Proxy?

Alle Reverse-Proxys führen die folgenden grundlegenden Operationen aus:

1. Der Client-Browser sendet eine HTTP-Anfrage an eine öffentliche URL. Nehmen wir an, die URL sei www.host.com auf Port 80.
2. Dann wird der Hostname wie üblich über den Reverse-Proxy-Server aufgelöst. Dieser Reverse-Proxy-Server lauscht auf diese Adresse und empfängt die Anfrage.
3. Danach untersucht der Reverse-Proxy die URL, um festzustellen, wohin er die Anfrage weiterleiten muss. Normalerweise kann ein Reverse-Proxy jede URL-Komponente verwenden, um zu entscheiden, wohin er die Anfrage weiterleiten soll. Er kann zum Beispiel Host, Protokoll, Pfad, Port oder Query String verwenden. Normalerweise ist der Pfad die Hauptkomponente, die über die Weiterleitung entscheidet.
   1. Die Einstellungen der Reverse-Proxy-Konfiguration bestimmen die Ausgangs-URL, an die die Anfrage gesendet wird. Diese ausgehende URL ist in der Regel der Back-End-Server, der für die Bereitstellung der Inhalte verantwortlich ist. Der Reverse-Proxy-Server kann die Teile der Anfrage umschreiben. Er kann z. B. Routensegmente ändern oder hinzufügen.
   2. Der nächste Schritt ist die Überarbeitung des Request Headers; der Reverse Proxy muss neben der Neuzuordnung der URL auch einige der HTTP-Header-Informationen aktualisieren, um den internen Webserver anzugeben. Der "Host:"-Header enthält zum Beispiel den Hostnamen, von dem aus die URL angefordert wird.
   3. Um die URL-Zuordnung abzuschließen, könnte http://www.host.com in http://realhost.com:8080.As umgewandelt werden, wie Sie sehen können, wurde der Hostname in realhost geändert. Dann wurde auch die Portnummer auf 8080 geändert.

4. Schließlich sendet der Reverse Proxy die Anfrage an den eigentlichen Server, der die Anfrage bearbeitet.
5. Nachdem der Server die Anfrage bearbeitet hat, sendet er die Antwort an den Reverse Proxy.
6. Der umgekehrte Proxy tut dann Folgendes:
   1. Sie ändert die Antwort, damit sie korrekt an den Client gesendet werden kann. Dazu gehört das Feld "Location:", das den Speicherort der Datei auf dem Server enthält.
   2. Der Reverse-Proxy ordnet die Kopfzeilen neu zu und sendet schließlich die Antwort an den Client.

Wie Sie Ihre Webanwendung mit Reverse Proxy sichern

Da unser Ziel darin besteht, die oben genannten Cyberangriffe abzuwehren, muss der Reverse Proxy neben den oben genannten Schritten noch weitere Funktionen erfüllen.

Validierung des Inhalts der Anfrage

Wenn ein Client eine Anfrage an den Server sendet, säubert der Reverse Proxy die Eingabe, indem er sie mit seiner Signaturdatenbank vergleicht. Die Programmierer entwickeln diese Signaturen mit hochentwickelten regulären Ausdrücken. Die Entscheidung des Reverse-Proxys, die Anfrage mit der Benutzereingabe zuzulassen, basiert ausschließlich auf dem Ansatz der Blocklist-Filter und Whitelist-Filter.

Blacklist-Filter-Ansatz

Der Blacklist-Filter speichert die bekannten schädlichen Anfragen. Er vergleicht dann jede Anfrage mit den Einträgen in der Liste. Stellt er eine Übereinstimmung fest, lehnt er die Anfrage ab. Verschiedene Varianten desselben Angriffs müssen separat in der Liste erfasst werden. Mit Hilfe von Blacklists können Sie nur die bekannten Angriffe verhindern, wobei die Vollständigkeit der Blacklist zu ihrer Wirksamkeit beiträgt. 

Whitelist-Filter-Ansatz

Ein Whitelist-Filter erfasst die gesamte Sammlung gültiger Anfragen für eine bestimmte Website. Dadurch verhindert die Whitelist Angriffe, da nur bekannte Anfragen den Server erreichen können. Die Erstellung einer Whitelist ist jedoch zeitaufwändig und erfordert die Kenntnis aller zulässigen Anfragen, die ein Benutzer an einen Server senden kann. 

Außerdem kann es überwältigend sein, alle gültigen Anfragen an Hunderttausende von Datenbankanbietern im Falle einer SQL-Injection zu erstellen.

Jede Änderung an einer gesicherten Webanwendung würde eine Aktualisierung der Whitelist erforderlich machen. Das Führen einer Whitelist erhöht daher den Verwaltungsaufwand. 

Validierung des Inhalts der Antwort

Bevor der Reverse Proxy die Antwort des Servers an den Kunden zurückschickt, überprüft er sie. In der Regel wird dazu eine schwarze Liste verwendet. Der Blacklist-Filter kann bekannte Antworten vor Clients verbergen, die sie nicht sehen müssen. Fehlermeldungen sind ein Beispiel für diese Art von Daten; der Reverse-Proxy kann den Fehler durch eine allgemeine Fehlermeldung ersetzen, die keine sensiblen Daten enthält.

Protokollierung von Anfrage und Antwort

Der Reverse-Proxy kann die Anfrage auch für eine spätere Prüfung protokollieren. Am besten ist es, die Protokollierung nur für die Anfragen zu konfigurieren, die der Reverse-Proxy zunächst blockiert hat. Sie sollten die Protokolle in den ersten Phasen der Installation sorgfältig prüfen. Dies ist wichtig, um sicherzustellen, dass der Reverse-Proxy keine echten Anfragen blockiert.

Schlussfolgerung

In diesem Artikel hoffen wir, dass Sie die Schwachstellen in einer Webanwendung verstehen und wie Sie einen Reverse-Proxy verwenden können, um diese Bedrohungen zu beseitigen. Der Reverse-Proxy kann nämlich nicht alle möglichen Schwachstellen von Webanwendungen beseitigen.

Es wäre jedoch eine großartige Strategie, um die meisten Bedrohungen, denen Sie in einer Webanwendung begegnen, zu entschärfen. Abschließend hoffen wir, dass Sie die in diesem Artikel gelernten Konzepte anwenden werden, wenn Sie Sicherheitsbedenken in Ihrer Webanwendung haben.