HTML5 aus Hackersicht
Kommentare

SQL-Injection-Angriff auf den Client
Mit HTML5 kommt die SQL-Datenbank als lokaler Speicher für Anwendungsdaten auch auf dem Client zum Einsatz, und natürlich bringt sie ihre typische Schwachstelle gleich

SQL-Injection-Angriff auf den Client

Mit HTML5 kommt die SQL-Datenbank als lokaler Speicher für Anwendungsdaten auch auf dem Client zum Einsatz, und natürlich bringt sie ihre typische Schwachstelle gleich mit. Während Sie sich über die SQL-Datenbank zum komfortablen Speichern von Daten freuen, freut sich ein Angreifer über die eventuell mögliche SQL Injection zum komfortablen Ausspähen und Manipulieren von Daten.

Zu Ihrem Glück erleichtert das HTML5 Database API die Nutzung von Prepared Statements, mit denen Sie SQL-Injection-Schwachstellen effektiv verhindern können. Kommen Sie also bitte nicht auf die Idee, die SQL-Anfragen aus Strings mit vorgegebenen Code und Parametern zusammen zu setzen – jeden noch so kleinen Fehler würde ein Angreifer gnadenlos gegen Sie verwenden. Wenn Sie z.B. executeSql(„SELECT spalte FROM tabelle WHERE wert=“ + eingabe); verwenden, reicht dem Angreifer die Eingabe von ’nix‘ OR 1=1, um an alle Daten zu gelangen, denn das ergibt SELECT spalte FROM tabelle WHERE wert=’nix‘ OR 1=1.

Ein Klassiker auf dem Webserver, der nun den Webclient erreicht hat. Eigentlich geht es erst in der nächsten Folge um die Abwehr von Angriffen, aber hier möchte ich Ihnen die sichere Variante nicht vorenthalten:

executeSql("SELECT spalte FROM tabelle WHERE wert=?", [eingabe]);

Hier wird die Eingabe nicht als String, sondern als Literal aufgefasst:

SELECT spalte FROM tabelle WHERE wert="'nix' OR 1=1"

Falls Ihre Datenbanktabelle zufällig eine Spalte mit dem Wert ’nix‘ OR 1=1 enthält, wird sie ausgegeben, ansonsten sieht der Angreifer gar nichts.

Gefahren für die Clientdatenbank

Im Prinzip ist die lokale Datenbank sehr gut geschützt, denn für sie gilt die Same Origin Policy (siehe dazu auch den XSS-Artikel auf der Heft-CD): Jede Domain und jede Anwendung darf nur auf die eigenen Daten zugreifen. Dieser Schutz ist im Fall von HTTPS sogar besser als durch das ‚Secure‘ Flag für Cookies, da er automatisch funktioniert. Auf über HTTPS in der Datenbank gespeicherte Daten kann nur über HTTPS zugegriffen werden. Über HTTPS gesetzte Cookies werden dagegen auch über HTTP übertragen, sofern das ‚Secure‘ Flag nicht gesetzt wurde.

Aber schon eine XSS-Schwachstelle in einer Webanwendung reicht aus, um darüber auf die Datenbank der betroffenen Domain bzw. Webanwendung zuzugreifen. Weitere Möglichkeiten, dem Browser einen zulässigen Zugriff von der jeweiligen Domain bzw. Webanwendung vorzutäuschen, sind z. B. DNS-Hijacking, Beeinflussung der lokalen Namensauflösung (z. B. durch eine Manipulation der hosts-Datei) oder Man-in-the-Middle-Angriffe, z. B. über einen Proxy. Nicht zu vergessen Zugriffe durch andere auf dem Clientrechner laufende (Schad-)Programme, da die SQL-Datenbank auch nur eine Datei auf dem Client ist.

Außer dem Ausspähen der Datenbankinhalte ist auch deren Manipulation möglich. Wird den auf dem Client gespeicherten Daten bei der weiteren Verarbeitung auf dem Server vertraut, kann ein Angreifer darüber z. B. XSS- oder SQL-Code einschleusen.


Auf den kommenden Seiten erwarten euch…:

  • Hartnäckiger XSS-Wurmbefall
  • Lokal gespeicherter Schadcode
  • Cross-Origin Requests
  • Ein kleiner Abstecher: Clickjacking
  • Clickjacking the Like-Button = Likejacking
  • Clickjacking + HTML5 = Neue Angriffsmöglichkeiten
  • Ein praktischer Angriff: Cookiejacking
  • iframe: Sandkasten gegen JavaScript
  • Schöne neue Funktionen, schöne neue Möglichkeiten
  • Info zum Autor Carsten Eilers
  • Links und Literatur
Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -