Webanwendungen sind häufig das Ziel von böswilligen Angreifern. Diese Anwendungen sind öffentlich zugänglich - oder zumindest ihre Anmeldeseiten - und es ist für einen entschlossenen Angreifer nicht schwer, Websites mit Sicherheitslücken zu finden. Angreifer versuchen oft, Sicherheitslücken auf den Anmeldeseiten einer Webanwendung auszunutzen, um eine übermäßige Belastung zu verursachen und die Website möglicherweise zum Absturz zu bringen.
Eine solche Schwachstelle befindet sich in der Seite mit den Sicherheitsfragen, die Teil vieler Anmeldevorgänge ist. In diesem Beitrag gehen wir auf dieses Szenario ein, untersuchen, warum es ein Problem darstellt, und geben Hinweise, wie dieses Sicherheitsrisiko gemindert werden kann.
Die Anmeldeseite mit einer leeren Sicherheitsfrage
Sicherheitslücken bei der Anmeldung sind häufiger, als Sie vielleicht denken. Beim Anmeldevorgang für viele Websites und Anwendungen wird der traditionelle Schritt Benutzername/Passwort durch eine zusätzliche Verifizierung ergänzt, um die Sicherheit zu erhöhen. Stellen Sie sich einen zweistufigen Anmeldevorgang vor. Im ersten Schritt werden Sie von der Website nach einer Kombination aus Benutzernamen und Kennwort gefragt. Wenn Sie diese Daten korrekt eingeben, werden Sie im zweiten Schritt aufgefordert, eine Sicherheitsfrage zu beantworten (die Sie bei der Einrichtung Ihres Kontos festgelegt haben).
Dieser zweite Schritt wird in der Regel aus einer Seitenvorlage erstellt, die die Sicherheitsfrage auf der Grundlage des Benutzers einfügt, der den ersten Schritt erfolgreich abgeschlossen hat. Der gesamte zweistufige Anmeldeablauf funktioniert im Wesentlichen wie folgt:
- Alice besucht die Anmeldeseite unter https://www.example.com/login.
- Alice gibt eine Kombination aus Benutzernamen und Passwort ein.
- Der Server prüft die übermittelten Anmeldedaten.
- Da die Anmeldedaten korrekt waren, leitet der Server den Browser auf die Folgeseite https://www.example.com/login2 weiter und fügt ein eindeutiges Token in den Request Header ein, um zu überprüfen, ob Alice den ersten Schritt des Anmeldevorgangs bestanden hat.
- Der Server rendert diese Seite auf der Grundlage einer Vorlage und fügt die abgefragte Sicherheitsfrage für Alice zusammen mit der Texteingabe für eine Antwort und einer Schaltfläche zum Absenden ein.
- Alice gibt die Antwort auf ihre Sicherheitsfrage ein.
- Der Server prüft, ob Alice ihre Sicherheitsfrage richtig beantwortet hat, und meldet sie dann an.
Konzentrieren wir uns auf die zweite Seite des Flusses, auf https://www.example.com/login2. Stellen Sie sich vor, was passieren könnte, wenn Sie diese Seite direkt in Ihrem Browser besuchen, ohne den ersten Schritt zu durchlaufen.
In einem Szenario ist es möglich, dass der Server prüft, ob es kein gültiges Token in der Kopfzeile der Anfrage gibt (was bedeutet, dass Sie den ersten Schritt des Anmeldevorgangs nicht erfolgreich durchlaufen haben), und Sie einfach an https://www.example.com/login zurückleitet, um von vorne zu beginnen.
In einem anderen möglichen Szenario rendert der Server die Seite jedoch weiterhin auf der Grundlage der Vorlage. Da es nicht möglich ist, eine entsprechende Sicherheitsfrage für den Benutzer zu finden (da es kein Token gibt, das dem Server mitteilt, um welchen halbwegs authentifizierten Benutzer es sich handelt), könnte die resultierende Seite wie folgt aussehen:
Sie werden mit einer peinlichen Seite mit Sicherheitsfragen zurückgelassen, die... keine Sicherheitsfrage enthält. So viel zu einer sinnlosen Seite.
Sinnlos, ja. Aber harmlos? Seien Sie sich da nicht so sicher.
Die Auswirkungen auf die Sicherheit
Was würde passieren, wenn Sie (oder eine Person, die bösartiger ist als Sie) eine Antwort auf diese "Sicherheitsfrage" einreichen? Der Server wird CPU-Zyklen aufwenden, um Ihre Antwort auszuwerten. Er wird die Texteingabe verarbeiten, nach dem eindeutigen Token in der Kopfzeile der Anfrage suchen und möglicherweise sogar eine Datenbankabfrage durchführen, um Ihre Antwort zu überprüfen.
Eine Anmeldeseite mit einer leeren Sicherheitsfrage mag unbedeutend erscheinen(was ist falsch an ein paar verschwendeten CPU-Zyklen hier und da?), aber sie kann zu ernsthaften Sicherheitsproblemen führen.
- Vergeudete Backend-Verarbeitungsressourcen: Die Verarbeitung sinnloser Formularübermittlungen verbraucht Netzwerk- und Computerressourcen - und möglicherweise auch Datenbankressourcen.
- Möglichkeit von Denial-of-Service-Angriffen (DoS): Ein Angreifer könnte ein Botnetz einrichten, um wiederholt Formularübertragungen zu senden und so das System zu überlasten.
- Erhöhte Anfälligkeit: Ein erfolgreicher DoS-Angriff könnte Ihr gesamtes System zum Absturz bringen.
Wenn Angreifer diese Schwachstelle ausnutzen können, um die Rechenleistung eines Servers zu verschwenden, könnten sie möglicherweise die Dienste für legitime Benutzer unterbrechen und das System für weitere Angriffe anfällig machen.
Also doch nicht so harmlos.
Sehen wir uns an, wie man Schwachstellen wie diese beheben kann, um die Sicherheit und Zuverlässigkeit Ihrer Anwendungen zu gewährleisten.
Wie man sich verteidigt
Für dieses spezielle Szenario sollte der Server, der den login2-Endpunkt bearbeitet, das Vorhandensein eines gültigen Tokens in der Kopfzeile der Anfrage überprüfen. Ohne ein ordnungsgemäßes Token sollte keine weitere Verarbeitung stattfinden, und der Benutzer sollte zum ersten Schritt des Anmeldevorgangs weitergeleitet werden. Auf diese Weise minimieren Sie die Ressourcen, die für die Bearbeitung der Anfrage benötigt werden, ähnlich wie bei einem 404 oder 401.
Dieses Szenario verdeutlicht jedoch ein allgemeineres Sicherheitsproblem, auf das Sie achten sollten: wiederholte Anfragen, die Ihren Server übermäßig belasten. Sicherlich kann die Ausnutzung einer sinnlosen Anmeldeseite mit einer leeren Sicherheitsfrage Ihren Server aufgrund der Menge der verwendeten Verarbeitungsressourcen schneller überlasten. Aber ein Botnet kann auch Ihre ganz normale Benutzername/Passwort-Anmeldeseite mit übermäßigen Anfragen belasten.
Um Ihre Webanwendungen vor dieser Art von Angriffen zu schützen, sollten Sie die folgenden Maßnahmen ergreifen:
- Verwenden Sie eine Web Application Firewall (WAF): Eine WAF kann DoS-Schutz bieten und bösartige Bots erkennen und blockieren, um das Risiko automatisierter Angriffe zu verringern. Linode's Marketplace of Apps enthält die Haltdos Community WAF, die Ihnen dabei helfen kann.
- Implementieren Sie eine Ratenbegrenzung: Begrenzen Sie, wie viele Anfragen eine einzelne IP-Adresse innerhalb eines bestimmten Zeitfensters stellen kann. Mit der Ratenbegrenzung verhindern Sie, dass Angreifer (und Bots) Ihr System mit Anfragen überfluten.
- Aktivieren Sie die Überwachung und Alarmierung: Tools zur kontinuierlichen Überwachung können nach verdächtigen Anfragemustern Ausschau halten und Sie in Echtzeit vor möglichen Angriffen warnen. Wenn Sie sofort benachrichtigt werden, können Sie reagieren und ein Problem schnell entschärfen.
Fazit
Wir haben uns den Fall einer Anmeldeseite mit einer leeren Sicherheitsfrage angesehen. Auf den ersten Blick sieht es aus wie eine seltsame Seite, die letztlich sinnlos ist. Aber Angreifer können Schwachstellen wie diese ausnutzen, um Ihre Ressourcen zu verschwenden und möglicherweise Ihr System zum Absturz zu bringen. Die Seite mit der Sicherheitsfrage ist nur ein Beispiel für eine solche Sicherheitslücke.
Wenn Sie Ihre Anwendungen mit Blick auf die Sicherheit entwickeln und sichere Kodierungspraktiken anwenden, haben Sie einen guten Start hingelegt. Ihre Anwendungen benötigen jedoch auch Sicherheitsmaßnahmen auf System- und Infrastrukturebene, z. B. die Verwendung einer WAF, Ratenbegrenzung, kontinuierliche Überwachung und Warnmeldungen. Mit den richtigen Sicherheitsmaßnahmen können Sie Ihr Risiko, Ziel solcher Angriffe zu werden, erheblich verringern.
Weitere Anleitungen und Tipps zur Sicherung Ihrer Anwendungen finden Sie in den Linode-Dokumenten, die eine umfangreiche Bibliothek mit sicherheitsrelevanten Anleitungen enthalten. Dort finden Sie hilfreiche Ressourcen, die Ihnen zeigen, wie Sie Ihre Systeme und Ihre Benutzer schützen können.
Kommentare