Neuer Artikel: Kontextwechsel erkennen und behandeln

Beim Durchlesen von Meldungen über Sicherheitsupdates fallen bei Webanwendungen wohl am häufigsten zwei Arten von Lücken auf: SQL‐Injection‐Lücken, bei denen es gelingt, von außen beliebigen SQL‐Code in Abfragen zu schleusen sowie XSS‐Lücken, bei denen ein Angreifer beliebiges Javascript in eine Seite schmuggeln kann, das dann das Verhalten der Seite modifiziert — und zum Beispiel Zugangsdaten an den Angreifer abzweigt. Beide Arten von Lücken sind jedoch nur eine Manifestation des gleichen Problems: Der Nichtbeachtung eines Kontextwechsels.

Ein Kontextwechsel tritt immer dann auf, wenn man Daten mit der Syntax einer Computersprache als solche kennzeichen will. Wenn man beispielsweise einen Text (die Daten) in HTML (die Computersprache) einfügen will, dann muss man bestimmte Zeichen des Textes maskieren — zum Beispiel < als &lt;. Sicherheitslücken entstehen nun, wenn man Kontextwechsel nicht an jeder Stelle erkennt und entsprechend behandelt. Der Artikel will an Hand von PHP und MySQL aufzeigen, an welchen Stellen dies am häufigsten geschieht. Selbstverständlich lassen sich die grundsätzlichen Erkenntnisse aus dem Artikel auch auf andere Sprachen übertragen.

Doch nicht nur Sicherheitslücken sind ein Problem von nicht behandelten Kontextwechseln. Selbst wenn sich durch glückliche Umstände ein solcher Fehler nicht als Sicherheitslücke manifestiert: Es kann für den Benutzer unglaublich frustrierend sein, wenn zum Beispiel sein Nickname vom Programm nicht akzeptiert wird, weil dieser ein Apostroph enthält. Oder wenn der gesamte Name stillschweigend vor dem Apostroph abgeschnitten wird. Korrekt behandelte Kontextwechsel sind wichtig, damit die Daten eines Benutzers auch korrekt gespeichert und wiedergegeben werden können.

Wir möchten jedoch warnen: Auch wenn der Artikel sich mit einem sicherheitsrelevanten Thema beschäftigt, sind Kontextwechsel doch nur ein Teil des Puzzles. Allerdings sind sie ein sehr wichtiger Teil – weswegen der neue Artikel Kontextwechsel erkennen und behandeln vom Benutzer dedlfix aus dem SELFHTML Forum sich mit dem Thema auseinandersetzt.

1 Kommentar » Schreibe einen Kommentar

  1. Bei der oben genannten HTML‐Maskierung ist es ja noch einfach, da treten meist schnell Probleme auf, wenn man die Seite auf einem Unicode‐Rechner anguckt. Bei SQL‐Injection ist das schon etwas aufwändiger. Zumeist reicht es bei ID’s und allgemein Zahlen ja brutal zu prüfen und abzubrechen, wenn es kein Zahlenwert ist. Bei Textfeldern muß man wirklich aufpassen und mehrmal kontrollieren. Da sind mit auch schon der eine oder andere Schusseligkeitsfehler unterlafen, den ich zum Glück rechtzeitig gefunden habe. Startrekkie