OT-Teil von: mysql table soll include einbinden

[ragtek]

Ich kenne dein CMS nicht. Erzähl doch mal, wie es funktioniert!
Kann der CMS-User in eine Textarea beliebigen PHP-Code schreiben, der wird dann in der DB gespeichert und beim Aufruf der Seite ge-eval't?
Junge junge, so ein Produkt würde ich niemandem empfehlen!

Das vB macht es zB so

Aber ja,
Ich würde den Code einmal aus der DB lesen und in eine Datei schreiben(cachen).
Das erspart doch die DB Abfrage.

[onemorenerd]

Das vB macht es zB so

Wußte ich gar nicht, habe vB aber auch noch nie verwendet oder weiterempfohlen. Werde ich auch nicht.

@fireweasel: Syntaxprüfung ist (wäre?) zwar nett, schützt aber nicht vor semantisch "böswilligem" Code. Das geht nur durch kontrolliertes Ausführen in einer Sandbox (z.B. VM). Im Webumfeld völlig abwegig.

[fireweasel]

Wußte ich gar nicht, habe vB aber auch noch nie verwendet oder weiterempfohlen. Werde ich auch nicht.

Parse error: syntax error, unexpected T_STRING in /home/medkaau/public_html/vb/index.php(565) : eval()'d code on line 2

Und dieser Angriff wurde nur entdeckt, weil auch der "pöse Hacker" seinen Quellcode vor dem Upload nicht auf Syntax-Fehler gecheckt hat.

@fireweasel: Syntaxprüfung ist (wäre?) zwar nett, schützt aber nicht vor semantisch "böswilligem" Code. Das geht nur durch kontrolliertes Ausführen in einer Sandbox (z.B. VM). Im Webumfeld völlig abwegig.

Wenn ich mich recht erinnere (das ist schon ein Weilchen her), bin ich davon ausgegangen, dass der PHP-Quellcode von einem Menschen eingegeben wird, der dem Webmaster wohlgesonnen ist, also ein Kollege, Mitarbeiter oder der Site-Betreiber selbst. Eingaben anderer Benutzer ist selbstverständlich grundsätzlich Böswilligkeit zu unterstellen. Hab mir den Quellcode des diskutierten CMS aber nicht näher angeschaut.

Ich bin zwar kein notorischer eval()-Gegner, aber wer diese Funktion anwendet, sollte ganz genau wissen, was er oder sie tut. Die meisten wissen das offensichtlich nicht.

[ragtek]

Nur um auf Pluginsysteme zurückzukommen.

Im Endeffekt ist es doch egal, ob ein System eval oder etwas anderes benutzt, das eigentliche Problem liegt wie immer beim Benutzer.

Es ist doch egal ob man ein System durch Dateiänderungen laut Anweisung, eval oder require_once verändert.
Über jede von den genannten Möglichkeiten kann böser Code eingeschleust werden

[onemorenerd]

Und dieser Angriff wurde nur entdeckt, weil auch der "pöse Hacker" seinen Quellcode vor dem Upload nicht auf Syntax-Fehler gecheckt hat.

Der Hacker hat vielleicht einfach eine Reihe bekannter Exploits durchprobiert bis er einen funktionierenden fand. Die Fehlermeldungen haben ihn dabei nicht gestört. Der Angriff wurde evtl. erst entdeckt, als das Kind schon im Brunnen lag und man des Kindes Tagebuch^WLogfiles las.
Es geht aber gar nicht ums gehackt werden. Das kann auch ohne eval passieren. Es geht vielmehr darum, dass man so einer eval-Fehlermeldung nichts hilfreiches abgewinnen kann. Ge-eval-ter Code lässt sich einfach schlecht debuggen.

Wenn ich mich recht erinnere (das ist schon ein Weilchen her), bin ich davon ausgegangen, dass der PHP-Quellcode von einem Menschen eingegeben wird, der dem Webmaster wohlgesonnen ist, also ein Kollege, Mitarbeiter oder der Site-Betreiber selbst.

In meiner Erinnerung waren es die Signaturen von Benutzern. Egal ... geht ja ums Prinzip. Und da ist das mit dem Vertrauen so eine Sache - weiß denn ein Site-Betreiber überhaupt, dass sein vB rum-eval-t?

[ragtek]

Weiß der "durchschnittliche" Seitenbetreiber überhaupt, wie seine Seite funktioniert?

Meiner Meinung nach, installieren viele fertige Pakete ala joomla, phpbb, konfigurieren diese und das war damit für sie.
Merkt man doch immer wieder in den Supportforen für die einzelnen Produkte

[onemorenerd]

Weiß der "durchschnittliche" Seitenbetreiber überhaupt, wie seine Seite funktioniert?

Weiß er nicht und kann/soll er auch nicht wissen.

Es ist doch egal ob man ein System durch Dateiänderungen laut Anweisung, eval oder require_once verändert.
Über jede von den genannten Möglichkeiten kann böser Code eingeschleust werden.

Dateiänderungen und require gehen Hand in Hand, wenn es um Code Injection geht. Der Unterschied zu eval ist, dass man sich vor unerlaubten Veränderungen der eigenen Dateien ziemlich einfach schützen kann. Man vernagelt den Dateisystemzugriff aus dem Netz und sichert alle Dateioperationen einer Applikation ab. Der Code, der durch eval gejagt wird, kommt nicht aus einer Datei. Der kommt aus einem nicht-dateibasierten Storage, z.B. einer DB oder live aus Benutzereingaben (run-once). In beiden Fällen muss man sicherstellen, dass der Code nicht schädlich ist. Das muss zwangsläufig direkt während der Ausführung geschehen, denn Code kann sich bei jeder Ausführung anders verhalten. Wirklich sicheres eval benötigt also eine Sandbox, sprich VM. Zu diesem Aufwand steht der Nutzen von eval in keinem gesunden Verhältnis.

[ragtek]

Ja, ich teile (fast komplett) deine Meinung, aber der Trend geht doch in eine andere Richtung (wo ich dagegeben bin, es gibt wie wir uns beide einig sind, zu viele Sicherheitsbedenken, aber der 0815 Benutzer will es meißt so).

Applikationen wie zB das Wordpress, das WBB3 erhalten automatische Updateprozesse und One Click Erweiterungsinstallation, die es ermöglichen, nur den Erweiterungennamen reinschreiben, und das Skript verbindet sich mit dem Server, lädt das Archiv runter, entpackt es und installiert alles unnötige.

Hier sind die Sicherheitsrisiken noch viel enormer.
Man stelle sich nur mal ein gehacktes Archiv vor....
Aber egal, ich glaube das es hier schon extrem in den Offtopicbereich ausartet...

[unset]

Ist doch egal, ist doch schon Offtopic.

Was das WP-Beispiel angeht: Ich persönlich nehme lieber ein Auto-Update-Konzept in Kauf, als das tausende ungepatchte WP-Versionen als Spamschleudern missbraucht werden. So gesehen kann man hier fragen, was passiert wenn die Debian-Repos Schadcode verteilen (was ja übrigens mindestens schon einmal passiert ist).

[ragtek]

Echt, das gab es schon mal? Garnicht mitgekriegt. Danke für den Hinweis.

Aber um auf dein Beispiel einzugehen.
Nun stell dir mal eine gehackte Version vor, die per Auto Update zu zig Tausenden Benutzern kommt=> noch größere Spamschleuder möglich

Da kämmen ja auch ganz andere Szenarien in Frage (mächtiges Botnet bis es nicht entdeckt wird)

Edit:
Aso, du meinst ein Debian Repo. Ich bezog mich auf WP...
Sorry

[unset]

Naja, das ist nun ein bisschen an den Haaren herbei gezogen. Ein solches würde jedem halbwegs fähigen Systembetreuer sofort auffallen. Im besagten Fall war es auch kein absichtlicher Schadcode, sondern - wenn ich mich recht erinnere - schlicht und ergreifend ein mangels Reviews eingeschlichener Bug, der allerdings dafür sorgte, dass Keys plötzlich sehr schwach wurden. Das wurde wohl auch ausgenutzt.

Edit: Und hier ist auch der Link: Debian -- Security Information -- DSA-1571-1 openssl

[onemorenerd]

So ein Auto-Update/Install-Prozess hat nichts mit eval zu tun. Da werden nur ein paar Files von irgendwoher gezogen, gespeichert und/oder in einer Plugintabelle registriert. Das funktioniert alles ohne eval und beweist einmal mehr, dass grenzenlose Flexibilität sehr gut ohne eval möglich ist.
PHP wird durch eval nicht mächtiger. Nur unsicherer.

Dass man Dateien von "irgendwoher" nicht trauen sollte, ist klar. Es gibt durchaus brauchbare Lösungen dafür - Identitätsprüfung, Zertifizierung, ... - aber letzenendes muss man immer irgend jemandem* vertrauen oder den Code vor der Installation selbst lesen.

*) Die Auto-Update-Mechanismen vieler Betriebssysteme funktionieren prinzipiell genau so. Der Updater connected sich zu einem unbekannten Server und lädt Dateien mit unbekanntem Inhalt. Millionen User vertrauen blind darauf, dass der ganze Prozess "sicher" ist. Überprüfen kann man das kaum.