Templates aus Datenbank lesen und ausgeben

[3DMax]

Original geschrieben von Shurakai
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.

das hieße somit auch, alle datenbankbasierte login-syteme o.ä müsste man dann auf flatfiles umstellen?
sorry, dein argument kann mich nicht so recht überzeugen.

[Shurakai]

Seit wann benutzen Loginsysteme eval?

[3DMax]

Original geschrieben von Shurakai
Seit wann benutzen Loginsysteme eval?

nein, du hast behauptet, db-systeme sind potentiell unsicher. warum soll ich also bei einem login auf eine unsicheres system setzen, das meinte ich.

[Shurakai]

Wenn du das von dir zitierte mal richtig durchliest, steht da, dass Datenbanksysteme in der Regel mehr mit Userinteraktion benutzt (Daten holen, Daten einfügen, Daten updaten, überall schön mit Daten aus _POST, _GET, _COOKIE, _SERVER in den Queries) werden. Schließlich organisiert man über die DB alle Daten der Seite.

Weil man nun also mehr Abfragen der Datenbank als Zugriffe auf das Filesystem hat - natürlich nicht alle mit Fremddaten - gibt es also auch mehr Möglichkeiten, eine Sicherheitslücke in einer Query zu haben. Wenn ich diese finde und richtig ausnutze, ist es schneller möglich, einfach alle Datensätze zu manipulieren und meinen eigenen Code einzufügen. Natürlich kann ich das auch tabellenübergreifend, wenn die Sicherheitslücke groß genug ist, ich bin also nicht nur auf Queries mit Templates beschränkt. (Oder was auch immer man benutzt)


Ich glaube nicht, dass es soviele Filesystem-Zugriffe gibt, die auch noch eine entsprechend große Sicherheitslücke haben, um eine höhere Gefahr als das oben genannte darzustellen. Deshalb würde ich sagen: Finger weg von Daten aus der DB mit eval(). Das ist meine Ansicht.

[onemorenerd]

Letztenendes ist eval() nur eine Hülle, ein Wrapper um einen PHP-Interpreter. Das macht es noch nicht gefährlich. Als PHP-Befehl kann eval() ja nur im Kontext eines PHP-Interpreters wirken. Man kann nicht aus dem aktuellen Kontext ausbrechen. In der Hinsicht ist allow_url_fopen viel gefährlicher.

Allerdings wird eval() oft unbedacht eingesetzt; aus Bequemlichkeit oder um schnell fertig zu sein. Wer so programmiert, denkt wenig an Sicherheit. Daher die häufigen Schlagzeilen in der Vergangenheit.

Und wer darüber nachdenkt, merkt schnell, dass man überprüfen muß, was eval() übergeben bekommt. Völlig egal, ob der Input aus einer DB oder einer Datei kommt, meine Herren!
Um zu wissen, was ein PHP-Codestring bewirkt, wenn er ausgeführt wird, muß man ihn ausführen. Halteproblem; also kein Lösungsweg.
Erlaubt man nur ganz bestimmte PHP-Codes, bei denen man schon vorher weiß, was sie bewirken, braucht man eval() nicht mehr.

Fazit: Ein eval() im Code ist ein Indiz für schlechten Code, ein schlechtes Konzept oder beides.

[3DMax]

Original geschrieben von Shurakai
Ich glaube nicht, dass es soviele Filesystem-Zugriffe gibt, die auch noch eine entsprechend große Sicherheitslücke haben, um eine höhere Gefahr als das oben genannte darzustellen. Deshalb würde ich sagen: Finger weg von Daten aus der DB mit eval(). Das ist meine Ansicht.

ja, ich habe dich schon verstanden. die db bietet neben des filesystems einen weiteren angriffspunkt - ist auch alles richtig.

nur, wenn jemand kontrolle über meine db erhält und seine eigenen scripte einspeisen kann, ist eh alles zu spät. genau so, wenn z.b. bei ebay jemand kontodaten auslesen könnte oder passwörter manipulieren kann oder zugriff auf das admin-interface erhält, das meinte ich.
je komplexer ein system, desto mehr angriffspunkte bietet es. lösung wäre statisches html

[combie]

Um PHP Code zu importieren, sind include und seine Brüder, erfunden worden!!
Darum sollte man sie auch zu diesem Zwecke benutzen.
Zusätzlich, sind Fehlermeldungen bei eval() erheblich schwerer zuzuordnen.

Alternativ zu eval(): http://www.technischedaten.de/pmwiki...ysqlUrlWrapper

Und ich teile die Sicherheitsbedenken meiner Vorredner!!!