Templates aus Datenbank lesen und ausgeben

**wahsaga** · 12.02.2007, 22:29

Re: Templates aus Datenbank lesen und ausgeben

Möchtest du dir vielleicht sprintf anschauen, anstatt diesen Nonsense weiterzuverfolgen?

**Screw Driver** · 13.02.2007, 09:35

Wieso Nonsens?

Ich habe in einer Datenbank Code liegen, dieser liegt in der Datenbank weil es Templates sind die auch PHP enthalten können. Diese muss ich somit ja als PHP behandeln?

**XGremliN** · 13.02.2007, 09:42

Templates enthalten keine LOGIK, sondern nur LAYOUT. Außerdem: eval() ist evil!

**Screw Driver** · 13.02.2007, 09:44

Dann sind es eben Module und keine Templates.

Überall muss ich eval is evil lesen und niemand begründet es oder sagt wie man es anders machen kann. sprintf sieht mir nicht danach aus als ob man es damit lösen kann.

**XGremliN** · 13.02.2007, 09:56

eval() ist evil, weil damit beliebiger Code ausgeführt werden kann. Beliebig heisst aber, dass auch von dir nicht gewollter Code ausgeführt werden kann. Somit tut sich da immer eine Sicherheitslücke auf.

Wenn du die Module in der DB liegen hast, kannst du sie doch auch in Dateien speichern und diese dann includen. Das ist imho schneller und sicherer als DB-Abfragen, wenn du die include's richtig absicherst natürlich.

**Wyveres** · 13.02.2007, 09:57

PHP-Code:


$string = 'Bierglas';

$name = 'Binding-Lager';

$str = '<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"

  "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">Das ist mein $string, 

voll mit $name.<br>';



echo $str;

eval ("\$str = \"$str\";");

echo $str;

Oo? autsch ... naja was auch immer.

PHP-Code:


$string = 'Bierglas';

$name = 'Binding-Lager';

$str = '<!DOCTYPE html PUBLIC \\"-\\/\\/W3C\\/\\/DTD XHTML 1.0 Strict\\/\\/EN\\"

  \\"http:\\/\\/www.w3.org\\/TR\\/xhtml1\\/DTD\\/xhtml1-strict.dtd\\">Das ist mein $string,

voll mit $name.<br>';

echo $str;

eval ("\$str = \"$str\";");

echo $str;

wenn du schon ausm handbuch dinge nachmachst, ja dann wenigstens richtig.

**Shurakai** · 13.02.2007, 10:46

Ich weiß nicht ob du hier mit Variableninterpolation nicht viel schneller zum Ziel kommst.....

**Slava** · 13.02.2007, 13:16

Original geschrieben von XGremliN
Wenn du die Module in der DB liegen hast, kannst du sie doch auch in Dateien speichern und diese dann includen. Das ist imho schneller und sicherer als DB-Abfragen, wenn du die include's richtig absicherst natürlich.

So ist es!
Was besseres kann ich auch nicht vorschlagen.

**Screw Driver** · 18.02.2007, 23:00

Original geschrieben von XGremliN
Wenn du die Module in der DB liegen hast, kannst du sie doch auch in Dateien speichern und diese dann includen. Das ist imho schneller und sicherer als DB-Abfragen, wenn du die include's richtig absicherst natürlich.

Das muss ich mir mal näher anschauen und mir dazu Gedanken machen. Danke auf alle Fälle aber, denn nun verstehe ich etwas besser wieso eval nicht so gut ist und wie man es besser machen könnte. So hilft einem das weiter.

**3DMax** · 18.02.2007, 23:20

Original geschrieben von Screw Driver
Danke auf alle Fälle aber, denn nun verstehe ich etwas besser wieso eval nicht so gut ist und wie man es besser machen könnte. So hilft einem das weiter.

nur mal so zum thema sicherheit meine meinung:
ob die scripte nun aus einer datenbank (auch vorausgesetzt, die db ist entsprechend abgesichert und nur du darfst dort scripte speichern) gezogen und eval() zum fraß vorgeschmissen werden, oder direkt aus dem filesystem geladen werden und der php-parser sie verwurstet, für mich macht das in punkto sicherheit keinen unterschied.

nur von wegen, eval ist evil, in diesem fall sehe ich das nicht so, mich kann ja jemand aufklären, wenn dem nicht so ist.

**Shurakai** · 19.02.2007, 01:34

Du kannst nicht garantieren, dass jemand nicht an deine Datenbank rankommt. Und weil du das nicht kannst, ist es dumm, Daten aus der Datenbank über eval() auszuwerten. Punkt.

Denn wenn jemand rankommt, dann führt er beliebigen Code aus und macht aus deinem Server / Webspace oder was-auch-immer du hast nen Warezserver / Spamschleuder oder was es sonst noch für Mist gibt.

**wahsaga** · 19.02.2007, 01:38

Original geschrieben von Shurakai
Du kannst nicht garantieren, dass jemand nicht an deine Datenbank rankommt. Und weil du das nicht kannst, ist es dumm, Daten aus der Datenbank über eval() auszuwerten. Punkt.

Du kannst nicht garantieren, dass niemand an dein Dateisystem herankommt (sei's per FTP oder sonstwie). Also wär's genauso dumm, Scripte im Dateisystem abzulegen - da können sie nämlich sogar ohne eval ausgeführt werden. Punkt :-)

**Screw Driver** · 19.02.2007, 01:40

@ wahsaga:
Und wie soll man es dann am schlauesten lösen? Du sagst immer was man nicht tun soll, aber gibst keine Antwort wie man es deiner Meinung nach am besten macht?

**Shurakai** · 19.02.2007, 01:44

Original geschrieben von wahsaga
Du kannst nicht garantieren, dass niemand an dein Dateisystem herankommt (sei's per FTP oder sonstwie). Also wär's genauso dumm, Scripte im Dateisystem abzulegen - da können sie nämlich sogar ohne eval ausgeführt werden. Punkt :-)

Das ist absolut korrekt. Allerdings unterstelle ich einfach mal, dass es in den meisten Fällen eher Sicherheitslücken in der Richtung Datenbank gibt bzw. es - wie auch immer - gelingt, das DB-PW aus der Config auszulesen als das FTP-Passwort zu erraten oder zu bekommen.

Natürlich kann man auch über "nette" Sicherheitslücken Kontrolle über das Dateisystem bekommen, aber ich schätze, dass das in der Regel schwieriger wird, weil Datenbanken - meistens - mehr mit Userinteraktion benutzt und dadurch angreifbarer sind.

Ich würde schon alleine aus diesem Grund die Finger von eval() lassen. Weitere sind mit Sicherheit die Arbeit, die Daten für eval() vorzubereiten sowie dass eval()-Funktionen ja eher langsamerer Natur sind

Templates aus Datenbank lesen und ausgeben