Eingaben und Ausgaben
Die häufigste Sicherheitsschwäche aktueller Anwendungen ist die fehlende korrekte Verarbeitung von Daten, die von externen Quellen, insbesondere Benutzereingaben, empfangen werden. Sie sollten sich Eingaben immer genau ansehen, um sicherzustellen, dass sie vor der Verwendung überprüft wurden. Wenn die Benutzereingaben nicht auf mögliche Angriffe analysiert werden, kann dies zu einem Datenverlust oder einer Offenlegung von Daten, zu Rechteerweiterungen oder sogar zur Ausführung von schädlichem Code auf den Computern anderer Benutzer führen.
Das Schlimme an dieser Situation ist, dass dieses Szenario ein leicht zu lösendes Problem ist. In dieser Lerneinheit wird der Umgang mit Daten behandelt: wann sie empfangen werden, wann sie auf dem Bildschirm angezeigt werden und wann sie für die spätere Verwendung gespeichert werden.
Warum müssen wir unsere Eingaben überprüfen?
Angenommen, Sie erstellen eine Schnittstelle, damit Benutzer*innen auf Ihrer Website ein Konto erstellen können. Die Profildaten umfassen einen Namen, eine E-Mail-Adresse und einen Spitznamen, der allen Benutzer*innen angezeigt wird, die die Website besuchen. Was geschieht, wenn ein neuer Benutzer ein Profil erstellt und einen Spitznamen eingibt, der einige SQL‑Befehle enthält? Wenn böswillige Benutzer*innen so etwas wie den folgenden Auszug eingeben, geschieht z. B. Folgendes:
Eve'); DROP TABLE Users;--
Wenn wir diesen Wert blind in eine Datenbank aufnehmen, könnte er die SQL-Anweisung ändern und Befehle ausführen, die wir unbedingt vermeiden möchten. Dieses Beispiel wird auch als „Angriff durch Einschleusung von SQL-Befehlen“ bezeichnet. Es ist einer von vielen Exploits, die ausgeführt werden können, wenn Benutzereingaben nicht ordnungsgemäß verarbeitet werden. Wie lässt sich dieses Situation verbessern? In dieser Lerneinheit wird vermittelt, wann Eingaben überprüft werden müssen, wie Ausgaben codiert werden und wie parametrisierte Abfragen erstellt werden (um den oben genannten Exploit zu verhindern). Diese Techniken sind die drei wichtigsten Verteidigungstechniken gegen schädliche Eingaben in Ihre Anwendungen.
Wann muss ich Eingaben überprüfen?
Die Antwort ist immer. Sie müssen jede Eingabe in Ihre Anwendung überprüfen. Dazu gehören Parameter in der URL, Eingaben der Benutzer*innen, Daten aus der Datenbank, Daten von einer API und alle Eingaben, die Benutzer*innen manipulieren könnten. Verwenden Sie immer einen Ansatz mit einer Positivliste, d. h. Sie akzeptieren nur „bekannt gute“ Eingaben, anstatt eine Sperrliste zu akzeptieren, (wo Sie speziell nach schlechten Eingaben suchen), da es unmöglich ist, sich eine vollständige Liste der potenziell gefährlichen Eingaben auszudenken. Erledigen Sie diese Aufgabe auf dem Server und nicht clientseitig (oder zusätzlich zum Client), um sicherzustellen, dass Ihre Verteidigung nicht umgangen werden kann. Behandeln Sie alle Daten als nicht vertrauenswürdig. Dadurch schützen Sie sich von den meisten gängigen Sicherheitslücken von Web-Apps.
Das ASP.NET-Framework bietet hervorragende Unterstützung für das Überprüfen von Eingaben auf dem Client und dem Server.
Wenn Sie ein anderes Webframework verwenden, stehen Ihnen im OWASP-Spickzettel für die Prüfung von Eingaben einige großartige Techniken für die Prüfung von Eingaben zur Verfügung.
Ausschließliches Verwenden von parametrisierten Abfragen
SQL-Datenbanken werden häufig zum Speichern von Daten verwendet, z. B. könnte Ihre Anwendung Benutzerprofilinformationen in einer Datenbank speichern. Sie sollten niemals Inline-SQL- oder andere Datenbankabfragen in Ihrem Code mithilfe von unformatierten Benutzereingaben erstellen und direkt an die Datenbank senden. Dieses Verhalten ist wie oben bereits erwähnt äußerst gefährlich.
Erstellen Sie beispielsweise einen Code nie wie im folgenden Inline-SQL-Beispiel:
string userName = Request.QueryString["username"]; // receive input from the user BEWARE!
...
string query = "SELECT * FROM [dbo].[users] WHERE userName = '" + userName + "'";
Hier werden Textzeichenfolgen verkettet, um die Abfrage zu erstellen. Des Weiteren wird die Eingabe des Benutzers übernommen und eine dynamische SQL-Abfrage generiert, um den Benutzer zu suchen. Wenn ein böswilliger Benutzer dies erkennen würde oder nur verschiedene Eingabeformate ausprobieren würde, um eine Schwachstelle zu finden, könnte das Ergebnis ein schwerwiegender Zwischenfall sein. Verwenden Sie stattdessen parametrisierte SQL-Anweisungen oder gespeicherte Prozeduren, z.B.:
-- Lookup a user
CREATE PROCEDURE sp_findUser
(
@UserName varchar(50)
)
SELECT * FROM [dbo].[users] WHERE userName = @UserName
Mit dieser Methode können Sie dann die Prozedur sicher über den Code aufrufen und die Zeichenfolge userName übergeben, ohne befürchten zu müssen, dass sie als Teil der SQL-Anweisung behandelt wird.
Codieren aller Ausgaben
Alle Ausgaben, die Sie entweder visuell oder in einem Dokument bereitstellen, sollten immer codiert und mit Escapezeichen versehen werden. So sind Sie geschützt, falls etwas bei der Bereinigung übersehen wurde oder der Code versehentlich etwas generiert, was in böswilliger Absicht verwendet werden könnte. Dieses Entwurfsprinzip stellt sicher, dass alles als Ausgabe angezeigt und nicht versehentlich als etwas interpretiert wird, das ausgeführt werden sollte. Dies ist eine weitere gängige Angriffstechnik, die als „Cross-Site Scripting“ (XSS) bezeichnet wird.
Da die XSS-Prävention eine häufige Anwendungsanforderung ist, ist diese Sicherheitstechnik ein weiterer Bereich, in dem ASP.NET die Arbeit für Sie übernimmt. Standardmäßig sind alle Ausgaben bereits codiert. Wenn Sie ein anderes Webframework verwenden, können Sie Ihre Optionen für die Ausgabecodierung auf der Website mit den Informationen im OWASP-Spickzettel für den XSS-Schutz überprüfen.
Zusammenfassung
Das Bereinigen und Überprüfen Ihrer Eingaben ist eine unerlässliche Anforderung, um sicherzustellen, dass die Eingaben gültig sind sowie sicher verwendet und gespeichert werden können. Die meisten modernen Webframeworks verfügen über integrierte Features, die einige dieser Arbeitsschritte automatisieren können. Sie können in der Dokumentation Ihres bevorzugten Frameworks nachsehen, welche Features vorhanden sind. Für Webanwendungen passiert dies zwar am häufigsten, aber bedenken Sie, dass auch andere Arten von Anwendungen genauso anfällig sein können. Sie sollten nicht glauben, dass Sie sicher sind, weil es sich bei Ihrer neuen Anwendung um eine Desktop-App handelt. Sie müssen dennoch Benutzereingaben richtig verarbeiten, um sicherzustellen, dass niemand über die App Ihre Daten oder den Ruf Ihres Unternehmens beschädigt.