Softwareschrott: string-parsing

Ein weiteres Problem, das ich immer wieder sehe, ist dass Programme/Routinen/Bibliotheken untereinander Daten austauschen, indem sie ihre Daten in Strings verpacken, diese übertragen und die andere Seite dann diese Strings anfängt wieder zu zerlegen.

Der offensichtliche Grund, warum das böse ist, ist die Geschwindigkeit. Natürlich braucht ein Programm länger wenn es eine XML-Struktur parsen soll, statt wenn es gesagt bekommt "mache XYZ, deine Parameter liegen an den Adressen 123, 345 und 0815". Vlt. ist das aber auch gleich ein Grund warum das warum dennoch so oft falsch verwendet wird, da das für uns Menschen relativ schwer vorstellbar klingt. Immerhin hat im einen Fall das Programm einen Text vorliegen, in dem bereits alle Daten enthalten sind und im anderen Fall muss es erst die Daten an anderen Stellen zusammensuchen.
Für einen Menschen wäre da natürlich die sinnvollere Wahl die Daten gleich mitzuliefern, da wir verdammt langsam darin sind Daten zu suchen, beim Lesen aber die Unterscheidung zwischen Daten und Anweisung weitestgehend Verzögerungsfrei vornehmen können.

In der Tat beherrscht auch eine CPU diese Fähigkeit. Wenn Maschinencode vorliegt, weiß unsere CPU sofort bei jedem Befehl wie lang er ist und ob auf diesen noch Daten folgen und wie lang diese wieder sind. Bei Strings jedoch, fällt das schwerer. Ein String hat nunmal als einzige Verwaltungsdaten seine Gesamtlänge, keiner weiß von wo bis wo Anweisungen stehen und von wo bis wo Daten stehen. Schlimmer noch: Die Daten könnten Text beinhalten der mit einer Anweisung identisch ist. Eine einfache Textsuche nach allem was wie eine Anweisung aussieht und den ganzen Rest dann als Daten zu behandeln, funktioniert also auch nicht.

Die übliche Vorgehensweise ist also Trenn-Symbole einzuführen. Ein sehr beliebtes Symbol wäre z.B. ', ', da es dem was wir Menschen uns notieren, sehr entgegen kommt. Doch was wenn wir einen solchen Text, wie diesen Artikel als Daten übertragen will? Die Zeichenfolge ', ' kommt hier mehr als häufig vor, also müssten wir diese Maskieren, um auch sie übertragbar zu machen.
Also ersetzen wir in diesem Text jedes vorkommen von ',' durch '\,' und ignorieren diese Stellen beim Parsen. Was jedoch wenn '\,' schon in den Daten vorgekommen wäre? (Wir müssen \ auch Maskieren) Was wenn jemand '\\\\,\\\,\\,\,' in den Text geschrieben hat?

Bereits hier wird klar dass es evtl. einfacher gewesen wäre Befehle auf Buchstaben zu begrenzen und statt den Daten nur Zahlen mit Start- und End-Adressen zu übertragen, an denen die Daten wirklich liegen (oder Adressen mit festen Längen, oder der Beschränkung dass Trennzeichen in Adressen einfach nicht vorkommen können).

Jetzt übertragen wir aber nicht nur einfach Daten in Strings serialisiert, sondern wir verpacken diese Daten auch gerne mehrfach. Z.B. kann von diversen "HTML-Richtext-Editoren" gerne komplexer HTML-Code erzeugt werden, der CSS-Definitionen in Maskierter Form enthällt, dieser wird wieder maskiert, über HTTP übertragen, von PHP demaskiert, anders maskiert, über SQL übertragen, in eine Datenbank eingelagert und irgendwann wird das alles wieder rückgängig gemacht und der CSS-Code von einem Browser interpretiert, der rausfinden muss was Selektor, was Bild-URL und was Farbwert in diesem Text darstellen soll.

Bei derartig komplex verschachtelten Elementen geht natürlich alles verloren was jemals an Vorteilen da gewesen sein sollte. Das typische Argument "das ist einfacher", kann man sich völlig schenken, menschenlesbar ist auch etwas anderes als

  "<div style=\\\"background-image: url('/foobar.jpg');\\\">\n"

In der Tat hab ich auch schon häufiger erlebt als mir lieb sein kann, dass Entwickler einfach nur noch verschiedene Codierungs-Funktionen und Dekodierungs-Funktionen auf bestehende Teststrings anwenden statt per Überlegung darauf zu schließen was es sein könnte. Ja, auch ich selbst befand mich schon häufiger in einer Situation in der ich ausprobieren musste weil ich nur irgendwelchen Schrägstrichsalat auf dem Teller hatte, den ich sonst nichtmehr auseinander sortiert bekommen hätte.

Wen wundert es da noch dass bei solchen Vorgängen auch gerne mal was durcheinander kommt? Und tatsächlich: XSS, Injections jeder Art und ähnlicher Blödsinn, sind langsam die häufigsten Fehlerquellen für jegliches Sicherheitsproblem oder für obskure Problemmeldungen ("Ich kann meinen 50-Seitigen Beitrag nicht speichern! Er bring immer was von SQL-Fehler!").

All das hätte man mit einem vernünftigem Übertragungsweg verhindern können oder wenigstens abschwächen können wenn man sich zentral auf eine Art escaping einigen könnte. Aber stattdessen muss ja heutzutage jeder Kot-Schreiber da draußen seine eigene Variante eines Parsers bauen.. meistens irgendwas in der Größenordnung von $foo = $explode($param, ', ');