Platzhalter sind in PHP "nicht wirklich sinnvoll"

[mermshaus]

@Google weiß alles

Okay, mal so als Denkanstoß:

Hier eine Liste der von mir bemerkten Tippfehler in myTemplateToPHP.sh, Version 1.1.2:

• Zeile 13: replacementrRight
• Zeile 16: replacementrRight
• Zeile 26: replacementrRight
• Zeile 49: Yoy, sedile

Eine Liste der bemerkten Logikfehler oder inhaltlichen Fehler:

• Zeile 15: XSS-Angriff möglich. htmlspecialchars benötigt den Parameter ENT_QUOTES (für Platzhalter in HTML-Attributen) und eigentlich auch noch eine encoding-Angabe (Hintergrund).
• Zeile 30: Überschreibt nachfolgend vermutlich die Eingabedatei, falls diese nicht auf .txt endet.
• Zeile 36: hasErrors könnte durch eine vorherige Eingabedatei den Wert 1 haben, wird hier aber auf 0 zurückgesetzt. Fehler werden dadurch potenziell verdeckt.
• Zeile 48: hasErrors könnte nicht initialisiert sein.

Bonus:

In die Ausgabe kann beliebiger PHP-Code injiziert werden.

• Für htmlSafeMode="yes":

  • Eingabe:

    foo {{ '])?> <?php var_dump(filemtime(__FILE__)); ?> <?=($tpl[' }} bar
    

  • Ausgabe:

    foo <?=htmlspecialchars( $tpl[' '])?> <?php var_dump(filemtime(__FILE__)); ?> <?=($tpl[' '] );?> bar
    

• Für htmlSafeMode="no":

  • Eingabe:

    foo {{ ']?> <?php var_dump(filemtime(__FILE__)); ?> <?=$tpl[' }} bar
    

  • Ausgabe:

    foo <?=$tpl[' ']?> <?php var_dump(filemtime(__FILE__)); ?> <?=$tpl[' '];?> bar
    

Statt var_dump(filemtime(__FILE__)); kann dort natürlich beliebiger Code stehen.

Das war jetzt ein Code Review mit den offensichtlichen Problemen in 52 Zeilen Code (inklusive Leerzeilen und Kommentare). Das dauerte länger als 3 Sekunden, war aber dafür vermutlich auch ergiebiger.

---

Wobei sich Template-Engines in Sachen Funktionsumfang wahrscheinlich auch konfigurieren lassen. Das weiß ich ohne Recherche nicht.

Tja. Irgendwie geht mit freier und quelloffener Software "alles". Wenn man hinsieht, dann ist sogar das bash-Skript (inzwischen) konfigurierbar.

Ja, wenn man bloß mal hinsehen würde, würde man sicher so einige Fehler entdecken. :)

(Nur am Rande und ohne Frotzelei, weil ich es richtig finde, das zu erwähnen: Auch dein Lizenztext enthält so einige grammatikalische Fehler. Den solltest du dir noch mal genau ansehen. Ich stimme ansonsten zu, dass die Lizenz eine Nutzung deines Codes leider quasi unmöglich macht, wenn man das Thema Lizenzen halbwegs ernst nimmt. Die Unwägbarkeiten sind nicht praktikabel und manche Aspekte sind unverständlich.)

Etwas stumpf formuliert: Je mehr eigenen Code man produziert, desto mehr eigenen Code muss man auch pflegen.

Der Widerspruch ebenso "stumpf" formuliert: (Annahme:) Ich benutze eine dieser wunderschönen Standardlösungen. Deren Code (der viel mehr ist als ich brauche - weil der ja viel mehr können muss) wird jetzt von Dritten gepflegt und, ach, auch dauernd erweitert. Jetzt kommt irgendwann mal die Situation, dass, nehmen wir ein bekanntes Beispiel (MySQL, OpenOffice) Oracle die Firma kauft und die Entwickler wild mit dem Armen rudernd und nicht zitierfähiges fluchend wegrennen oder aus anderen Gründen das Interesse verlieren oder eben auch richtig batzige Ideen haben wodurch ich dann mein gesamtes Projekt umschreiben muss (PHP-mysql(), python 2 zu 3, ...).

Das Risiko besteht allerdings immer bei so ziemlich allem. Die PHP-Entwickler könnten auch irgendwann mal auf die Idee kommen, beispielsweise die array_*-Funktionen auszutauschen. Zu inkompatiblen Änderungen an htmlspecialchars, die theoretisch durchaus auch dein Bash-Script betreffen würden, habe ich oben schon was verlinkt. Selbst die Bash-Syntax ist nicht in Stein gemeißelt. Oder die von sed. Oder die Frage, ob sed oder mktemp irgendwann nicht mehr paketiert sein könnten.

Nachträgliche Pflege ist im EDV-Umfeld ein Faktor, mit dem so oder so kalkuliert werden muss. Es gibt in der Hinsicht (leider?) den idealen Code nicht. Die Lebenszyklen sind endlich.

Oder die Entwicker der "Kann-alles-am-besten-Libary" fummeln unbemerkt von der Community eine Sicherheitslücke rein (Joomla, Wordpress, Typo, ...) und irgendwann sind die Daten aller Mitarbeiter meiner Firma im Darknet für "zweifuffzich" zu haben - allerdings veraltet, denn ich bin keiner mehr.

Nun ja… Das kann theoretisch auch jeder Entwickler eines Pakets einer Linux-Distribution tun. Ähnlich wie mein Kommentar zum letzten Aspekt. Das kann auch jeder Entwickler proprietärer Software tun. Nur ist es bei denen nicht mal theoretisch nachvollziehbar, weil der Code nicht offen einsehbar ist.

Es ist letztlich so, dass der Free-Software-Kosmos oder der Software-Kosmos generell auf Vertrauen basiert. Das kann man auch nicht so einfach rauskürzen, weil kein einzelner Mensch Millionen an Codezeilen überwachen kann. (Führt jetzt zu weit, aber ich werfe da mal den Begriff „bugdoor“ in den Raum.)

Dennoch gibt es bei dem Thema durchaus Aspekte in Sachen Gewährleistung und dergleichen. Ich weiß von Unternehmen, die auf der Grundlage durchaus die Nutzung externer Bibliotheken verbieten. Eine gewisse Paranoia oder Vorsicht ist da sicher nicht verkehrt. Die muss man aber gegenüber praktischen Aspekten abwägen. Zudem garantiert eben auch niemand, dass der „in house“-Code oder der Code, den man den Dienstleister hat machen lassen, qualitativ besser ist. Das ist letztlich auch eher der Punkt, dass die Kunden jemanden greifbar haben wollen, der eine Gewährleistungspflicht erfüllt und gegebenenfalls nachbessert.

Es ist ein offenes Geheimnis, dass der meiste Code… nicht so toll ist.

Ich vertrete hier den festen und begründeten Standpunkt, dass in vielen, besonders aber den einfachen Fällen die Nutzung eigener, minimalistischer Lösungen der billigere, performantere und risokofreiere Weg ist.

Ich will nicht darauf rumreiten, aber ich habe oben demonstriert, dass du im Schnitt alle 5-10 Zeilen (nicht mal SLOC-Zeilen) einen eindeutigen Fehler gemacht hast und dass du bei deinem Ansatz auch mindestens ein konzeptionelles Problem hast, weil du das Einfügen beliebigen PHP-Codes gestattest.

Das ist höchstens security through obscurity, weil sich niemand die Mühe macht, genau dein System anzugreifen, wenn man mit einem WordPress-Hack gleich – keine Ahnung – 75 Millionen Seiten attackieren könnte. Dein Code ist nicht unwahrscheinlich trotzdem viel schlechter als der von WordPress. (Ironischerweise ist das ein Konzept, was dennoch irgendwie sogar funktioniert. Aber sobald du ein einigermaßen lohnenswertes Ziel bist, trägt dir dann halt doch irgendein Hacker mal die Daten raus. Das potenzielle Risiko ist trotzdem immer vorhanden, es wird nur nicht realisiert. Wenn du auf dem Land wohnst, brauchst du dein Haus nicht abzuschließen, weil dir halt keiner an der Tür rüttelt.)

Und da man ja in PHP - weil es eine Skriptsprache ist - weit überwiegend nur "kleinere" Dinge erledigt (aus ein paar Daten Webseiten zusammenkrümelt) denke ich, dass diese "einfache Fälle" irgendwie die weit überwiegende Mehrheit der Fälle darstellen.

Da müsste ich jetzt eigentlich weiter ausholen. Ein Aspekt ist jedenfalls: Wenn du einen einfachen Fall hast, brauchst du auch keine kompilierten Templates.