Statisches HTML gegen SQL-Injection

Vor einigen Wochen stieß ich eher per Zufall in einer Seite auf Cross-Site Scripting und SQL-Injection. Wie es so meine Art ist, verschickte ich entsprechende Hinweise, inkl. Beispiel, damit die Fehlersuche und -behebung einfacher wird. Die XSS-Lücke wurde sehr schnell behoben, aber die SQL-Injection war auch nach 4 Wochen noch möglich.

Nur weil es eine bekannte Seite ist, die sich auch dem Thema IT-Security verschrieben hat, erwähne ich dies hier. Ich könnte nun weiter ausholen und darlegen, warum mir diese Seite wichtiger ist als andere, aber damit würde ich den Seitenbetreiber evtl. in eine peinliche Lage bringen und Spott von Dritten braucht er nun ganz sicher nicht, es reicht vollkommen aus, wenn dieser von mir kommt. ;O)

Am Montag habe ich nachgefragt, worauf man denn warten würde und ob da erst ein Angreifer kommen muss, um diesen “bösen Hackerangriff” dann medienwirksam ausschlachten zu können. Ich weiß, eine provokante Frage, aber wer das Thema IT-Security auf seine Fahnen schreibt, der sollte auf Hinweise auch zügig reagieren und ggf. auf freche Fragen von mir gefasst sein. Mir geht es um die Sache, also die Sicherheit der Besucher der Seite, weshalb ich da auch gerne mehrfach nachhake, bis die Lücke geschlossen wird.

Die Antwort fand ich dann doch etwas befremdlich:

Das CMS wurde von einem Kollegen, der nicht mehr im … aktiv ist, selbst gebaut. Kosten der Einarbeitung und “Absicherung”: ca. 7 MT. Daher ist der Plan eine funktionsfähige statische Kopie zu ziehen und die dynamische Seiten abzuschalten. Allerdings müssen noch manche Inhalte eingepflegt werden. Im Anschluss werden die Inhalte auf ein anderes System, auf dem auch die http://www… läuft, gehoben.

Sieben Manntage, um eine Variable gegen SQL-Injection abzusichern? Es werden nur zwei Variablen verwendet und nur eine davon ist vulnerable. Wenn man eh auf ein etabliertes und vielfach bewährtes System umsteigen will, dann braucht man keine Einarbeitung in das alte CMS. Man braucht nur in dem Quellcode nach der entsprechenden Variable und deren Weiterverarbeitung fahnden. Wenn ich in einem CMS solch eine Lücke schließen soll, dann muss ich im schlimmsten Fall den kompletten Quellcode runter laden, um darin automatisiert suchen zu können und der Download dauert sehr viel länger, als die entsprechenden Stellen zu finden und zu fixen. In diesem Fall wäre der Fix recht einfach, da die Variable nur eine ein- oder zweistellige Zahl ist.

Da man wohl von den “7 MT” erschlagen wurde (Um nicht weiter nachzudenken? Man kann auch über den Preis einen Auftrag ablehnen!), hat man nun einfach (<g>) eine Kopie in HTML erzeugt. Die SQL-Injection ist nun nicht mehr möglich. Bravo! Aber… Naja… Verschiedene Links auf der Seite selber funktionieren nicht mehr und zeigen nur noch eine Leere Seite oder Fehlermeldung an und alle (!) Ergebnisse von Google führen auch nur zu einer leeren Seite. Aber egal — Google wird eh überbewertet und da kommen auch kaum Besucher her. Warum hat Google überhaupt Hunderte von Unterseiten in seinen Index aufgenommen? ;O)

Ich bin sicher, wenn ich nicht nachgefragt hätte, dann wäre auch die Umstellung auf statische HTML- und leere PHP-Seiten bzw. Fehlermeldungen (<g>) nicht erfolgt. Sicherheitslücken fixen ist ein “unnötiger” Kostenfaktor ohne jeden Gegenwert?! Die Lücke bestand sehr wahrscheinlich seit 2010, seit Bestehen der Seite. Bisher hat ja niemand (hoffentlich) die Lücke bemerkt und ausgenutzt, also warum jetzt fixen? Nur weil mal wieder der Einmann-CCC vorbeischaut und so penetrant nervt und die Schließung der Lücke fordert, sah man sich wohl gezwungen zu handeln. Keine Sorge, ich hätte nur weiter genervt, aber veröffentlicht hätte ich die Lücke nicht.