Immer größere Datenmassen sicher zu speichern ist eine Herausforderung für jede IT-Infrastruktur. Schon mit Gigabit-Ethernet lassen sich aber ... (mehr)

Problem Web

Weil Webserver heute meist ausgewachsene Application Server sind, bieten sie eine ganze Reihe von Angriffspunkten. Das größte Problem dabei ist die Komplexität. Schon einfache Webanwendungen umfassen häufig den Code der Anwendung selbst, den Webserver, eine Datenbank und das Betriebssystem. Jede dieser Komponenten eignet sich als Ziel für einen Angriff, der sich Fehler in der Programmierung zu Nutze macht. Häufig ist es auch die Kombination von Fehlern der einzelnen Komponenten, die einen Einbruch ermöglicht.

Wer es sich einfach machen will, verwendet einen Scanner für Webanwendungen und lässt ihn auf den Server los. Automatisierte Tools wie Nessus oder Nikto suchen nach mehr als 3500 potenziell gefährlichen Dateien und Skripten. Finden sie nichts, kann ein Angreifer immer noch mit Programmen wie Webscarab manuell manipulierte Anfragen an den Server richten und die Antworten genau untersuchen. Einfach im Nebel zu stochern deckt häufiger interessante Probleme auf, als man denkt [8] .

Wenn Webanwendungen Daten speichern, tun sie das selten in Dateien, sondern verwenden richtige relationale Datenbanken wie MySQL und PostgreSQL. Blöderweise untersuchen viele Applikationen die von den Anwendern eingegebenen Daten nicht richtig, sondern schreiben sie einfach unverändert in die Datenbank. Aus diesem Umstand resultiert eine ganze Klasse von Angriffen, die SQL-Injection genannt werden. Entsprechende Fragmente davon sehen zum Beispiel so aus:

name' or '1' = '1
productid' and '1'='2

Der erste Angriff richtet sich gegen Programmteile, die eine Authentifizierung gegen Usernamen- oder Passwort-Tabellen in einer Datenbank durchführen. Er geht davon aus, dass die erste Zeile an ein SQL-Statement angehängt und ausgeführt wird. Die Webanwendung setzt diesen String ungeprüft in eine SQL-Abfrage der Art »WHERE login = '$name'« ein, was dadurch zu »WHERE login = 'name' or '1' = '1'« wird. Weil der zweite Teil »'1' = '1'« immer wahr ist, lässt sich so die Login-Prüfung umgehen.

Die zweite Zeile ermöglicht einem Angreifer zu testen, ob ein Webformular anfällig für SQL-Injections ist. Sie fragt nach der »productid« , verknüpft diese Abfrage aber mit der Zusatzbedingung »'1'='2'« , die immer falsch ist. Deshalb schlägt die Anfragen höchstwahrscheinlich fehl und produziert eine Fehlermeldung, die weiteren Aufschluss über die Datenbank liefert.

SQL-Injections mit Potenzial

Angreifer lieben SQL-Injections, weil sie damit die Authentifizierung einer Site komplett umgehen können. Je nach Konfiguration dringen sie vielleicht sogar gleich über die Datenbank tiefer ins System ein. Wenn eine Website ihre Inhalte aus der Datenbank bezieht, können Cracker dort ausführbaren Code einschleusen – zumindest im Fall einer Skriptsprache wie PHP –, der beim nächsten Mal abläuft, wenn jemand die Seite aufruft. So führen Angreifer beliebigen Code mindestens mit der User-ID des Datenbankbenutzers auf dem Server aus. Das SQL Injection Cheat Sheet verrät noch mehr Details dazu [9] .

Die Technik namens Cross Site Scripting (XSS) ist das perfekte Beispiel dafür, warum man Code und Daten nicht vermischen sollte. Als HTML nur eine Beschreibungssprache für Webseiten war, gab es solche Angriffe nicht.

comments powered by Disqus
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Ausgabe /2023