Classic ASP hat einen schlechten Ruf in Sachen Sicherheit, und er ist verdient. SQL-Injection gehört zu den ältesten und gefährlichsten Schwachstellen im Web, und alter ASP-Code ist geradezu ein Sammelbecken dafür. Nicht weil ASP-Entwickler schlampig waren, sondern weil der damals übliche Programmierstil die Lücke praktisch eingebaut hat.
Die gute Nachricht: Das Problem ist gut verstanden, und man kann es im eigenen Bestand finden und schließen. Dieser Artikel zeigt, wie – aus der Perspektive desjenigen, der sein eigenes System absichern will.
Wie die Lücke überhaupt entsteht
Im Kern geht es um eine einzige schlechte Angewohnheit: Datenbankabfragen werden als Text zusammengesetzt, und in diesen Text fließen Eingaben des Nutzers direkt ein – ein Suchbegriff, eine Anmeldung, eine ID aus der URL. Die Anwendung baut sich so ihren SQL-Befehl Stück für Stück aus festen Teilen und Nutzereingaben zusammen.
Das Problem dabei: Die Datenbank kann nicht unterscheiden, was vom Programmierer gemeint war und was der Nutzer beigesteuert hat. Wenn jemand statt eines harmlosen Suchbegriffs etwas eingibt, das die Datenbank als zusätzlichen Befehl liest, führt sie ihn aus. So lassen sich im schlimmsten Fall Daten auslesen, verändern oder löschen, die eigentlich geschützt sein sollten.
In der ASP-Ära war genau dieser zusammengesetzte Stil die Norm. Deshalb steckt die Lücke in so vielen alten Anwendungen – oft an Dutzenden Stellen.
Warum „uns hat noch keiner angegriffen“ kein Argument ist
Viele Betreiber alter ASP-Anwendungen fühlen sich sicher, weil nie etwas passiert ist. Das ist ein Trugschluss. SQL-Injection-Lücken werden heute weitgehend automatisiert gesucht – nicht von Menschen, die gezielt Ihr Unternehmen ins Visier nehmen, sondern von Programmen, die das halbe Internet abklappern. Eine offene Lücke wird gefunden, weil sie offen ist, nicht weil jemand es speziell auf Sie abgesehen hat. Dass bisher nichts passiert ist, sagt nichts über die Verwundbarkeit aus.
So spürt man die Schwachstelle im eigenen Code auf
Die Suche folgt einem klaren Muster. Man verfolgt jeden Weg, auf dem Daten von außen ins System kommen, bis zu der Stelle, wo sie in einer Datenbankabfrage landen.
- Eingangspunkte erfassen. Wo nimmt die Anwendung Eingaben entgegen – Formulare, URL-Parameter, Cookies, hochgeladene Dateien?
- Den Datenpfaden folgen. Wohin wandert jede dieser Eingaben? Landet sie irgendwann in einem zusammengesetzten Datenbankbefehl?
- Die kritischen Stellen markieren. Überall dort, wo Nutzereingaben in eine Abfrage einfließen, ohne dass sie als reiner Wert behandelt werden, liegt potenziell eine Lücke.
In einem gewachsenen System ist das mühsam von Hand, aber systematisch machbar. Genau diese Kartierung der Datenpfade ist fester Bestandteil unseres Sicherheits-Audits bei jeder ASP-Migration.
Wie man die Lücke dauerhaft schließt
Die nachhaltige Lösung heißt: Eingaben und Befehle sauber trennen. Statt Nutzereingaben in den SQL-Text hineinzukleben, übergibt man sie der Datenbank als klar gekennzeichnete Parameter – als Werte, nicht als Befehlsbestandteile. Die Datenbank weiß dann eindeutig: Das hier ist ein Suchbegriff, kein zusätzlicher Befehl. Damit verpufft die Injection-Lücke an der Wurzel.
Dazu kommt konsequente Validierung: Eine ID, die eine Zahl sein muss, wird auch als Zahl geprüft, bevor sie irgendwo ankommt. Was nicht ins erwartete Format passt, wird abgewiesen.
Das klingt einfach, und an einer einzelnen Stelle ist es das auch. Die Herausforderung ist die Menge: In einer alten Anwendung muss jede einzelne Abfrage umgestellt werden, und es darf keine übersehen werden.
Warum die Migration die saubere Lösung ist
Man kann alte ASP-Anwendungen Stelle für Stelle nachbessern. Aber das ist Flickwerk auf einer Technologie, deren Grundlage – serverseitiges VBScript – Microsoft ohnehin schrittweise aus Windows entfernt. Nachhaltiger ist es, das Problem im Zuge einer Migration zu erledigen: Beim Überführen auf Laravel werden Datenbankzugriffe grundsätzlich über sichere, parametrisierte Mechanismen aufgebaut. Die Injection-Lücken verschwinden nicht durch einzelne Pflaster, sondern weil der neue Code von vornherein anders gebaut ist.
Bei uns ist das Sicherheits-Audit auf SQL-Injection und Cross-Site-Scripting deshalb verpflichtender Teil jeder Classic-ASP-Migration. Was mit der VBScript-Logik geschieht, ist auf der zugehörigen Seite beschrieben.
Der erste Schritt
Im Code-Assessment prüfen wir Ihre ASP-Anwendung gezielt auf solche Schwachstellen und sagen Ihnen, wie es um die Sicherheit Ihres Systems steht.
Häufige Fragen
Können wir die Lücken nicht einfach selbst stopfen? An einzelnen Stellen ja. Das Risiko liegt im Übersehen – eine einzige vergessene Abfrage genügt. Ein systematisches Audit stellt sicher, dass keine offen bleibt.
Reicht eine Firewall oder ein Filter nicht aus? Solche Schutzschichten helfen, sind aber keine Lösung der Ursache. Die Lücke sitzt im Code, und dort gehört sie geschlossen.
Bleibt unser System während der Absicherung nutzbar? Ja. Im Rahmen der schrittweisen Migration läuft die Anwendung weiter, während die Abfragen nach und nach auf sichere Mechanismen umgestellt werden.
Dieser Beitrag behandelt das Thema aus Verteidigungssicht und richtet sich an Betreiber, die ihre eigenen Systeme absichern wollen. Bei sensiblen Themen rund um IT-Sicherheit empfiehlt sich zusätzlich fachkundige Begleitung.