Redirect via Header verhindern

[Hopsel]

Hi alle!

Ich habe mal wieder ein kleines, nein, ein großes, Problem.

Auf einer Seite lagern mehrere PHP-Skripte, die von Usern erstellt werden. (Es handelt sich hierbei um ein CMS.)

Diese PHP-Skripte machen natürlich auch Ausgaben.
<?php echo 'Text'; ?>
führt zu der Ausgabe "Text".

Diesen "Text" benötige ich für weitere Verarbeitung und Speicherung.
Das funktioniert über die Ausgabepufferfunktionen von PHP auch sehr gut.

Problem: Wenn in einem Skript folgender Code vorkommt, wird natürlich auch mein Skript weitergeleitet:
header('Location: http://example.org');

Kann ich diese Weiterleitung verhindern?
Wenn nicht, kann ich sie wenigstens irgendwie erkennen ohne vorher den Code entsprechend zu parsen?

Wenn es keine andere Möglichkeit gibt, werde ich den Code wohl üder übel vorher durchsuchen müssen, ob eine Weiterleitung stattfindet.

MfG H☼psel

[Edgar Ehritt]

Tach Hopsel,

Auf einer Seite lagern mehrere PHP-Skripte, die von Usern erstellt werden. (Es handelt sich hierbei um ein CMS.) Diese PHP-Skripte machen natürlich auch Ausgaben.
<?php echo 'Text'; ?>
führt zu der Ausgabe "Text".

wenn ich das richtig verstehe, können User PHP-Code ausführen lassen? Was unternimmst Du zur Sicherung, das kein Schadcode ausgeführt wird?

Diesen "Text" benötige ich für weitere Verarbeitung und Speicherung.
Das funktioniert über die Ausgabepufferfunktionen von PHP auch sehr gut.

Problem: Wenn in einem Skript folgender Code vorkommt, wird natürlich auch mein Skript weitergeleitet:
header('Location: http://example.org');

Kann ich diese Weiterleitung verhindern?

Ja. Im einfachsten Fall reicht es vorm Ausführen des Nutzercodes z. B. mit echo " "; eine Ausgabe zu erzeugen. Dies kann abhängig von der Konfiguration zu unerwünschten Fehlermeldungen führen. D

Wenn nicht, kann ich sie wenigstens irgendwie erkennen ohne vorher den Code entsprechend zu parsen?

Jain. Du hast die Möglichkeit (worauf auch ein vernünftiges Sicherheitskonzept basieren sollte) mit der Tokenizer-Erweiterung der Nutzereingaben vor Ausführung zu analysieren (was parsen übrigens bedeutet).

Wenn es keine andere Möglichkeit gibt, werde ich den Code wohl üder übel vorher durchsuchen müssen, ob eine Weiterleitung stattfindet.

Je nach Einsatzgebiet sollte so aber das Sicherheitsrisiko minimiert werden.

Gruß aus Berlin!
eddi

[Hopsel]

Hi Edgar!

wenn ich das richtig verstehe, können User PHP-Code ausführen lassen? Was unternimmst Du zur Sicherung, das kein Schadcode ausgeführt wird?

Da habe ich mich etwas unglücklich ausgedrückt. Die "User" sind die Webdesigner/-entwickler, die mit dem CMS arbeiten und wollen natürlich auch, dass jedweder PHP-Code ausgeführt wird. Insofern ist das Thema "Sicherheit" in diesem Fall nicht meine Baustelle, sondern liegt ind er Verantwortung der Entwickler des CMS.

Kann ich diese Weiterleitung verhindern?
Ja. Im einfachsten Fall reicht es vorm Ausführen des Nutzercodes z. B. mit echo " "; eine Ausgabe zu erzeugen.

Gute Idee. =)
Leider wird diese Ausgabe aber von mir nicht gesteuert und ich kann den Header somit nicht beeinflussen.

Wenn nicht, kann ich sie wenigstens irgendwie erkennen ohne vorher den Code entsprechend zu parsen?
Jain. Du hast die Möglichkeit (worauf auch ein vernünftiges Sicherheitskonzept basieren sollte) mit der Tokenizer-Erweiterung der Nutzereingaben vor Ausführung zu analysieren (was parsen übrigens bedeutet).

Das werde ich so machen.

Danke für deine Ideen und Erläuterungen.

MfG H☼psel

[dedlfix]

Hi!

Die "User" sind die Webdesigner/-entwickler, die mit dem CMS arbeiten und wollen natürlich auch, dass jedweder PHP-Code ausgeführt wird. Insofern ist das Thema "Sicherheit" in diesem Fall nicht meine Baustelle, sondern liegt ind er Verantwortung der Entwickler des CMS.

Was kümmert es dich dann, ob da eine Weiterleitung enthalten ist oder nicht?

Lo!

[Hopsel]

Hi dedlfix!

Was kümmert es dich dann, ob da eine Weiterleitung enthalten ist oder nicht?

Mein Skript liest alle Inhalte, die über das CMS eingegeben werden, ein und speichert sie in einer DB-Tabelle. Dabei handelt es sich um eine Volltextsuche mit Cache für Suchanfragen.
Damit die Inhalte aber indexiert werden können, benötige ich die vollständigen Seiteninhalte.
Das CMS (Redaxo) gibt mir dabei die Artikel mit Hilfe der Ausgabepufferfunktionen zurück. Ist innerhalb eines solchen Artikels eine Weiterleitung, so wird diese ausgeführt und führt somit zum Skriptabbruch.

Ich suchte also nach einer Möglichkeit, die Inhalte zu bekommen ohne von solch einer Weiterleitung betroffen zu sein.
Mein erster Gedanke war daher, Weiterleitungen zu erkennen und solche Inhalte gar nicht erst in den Suchindex einzuschließen.
Das ließ sich aber nicht zufriedenstellend bewerkstelligen.

Die Lösung über file_get_contents ist deshalb optimal: Ich bekomme die Inhalte, ohne dass Weiterleitungen den weiteren Skriptablauf beeinflussen.

MfG H☼psel

[Auge]

Hallo

Was kümmert es dich dann, ob da eine Weiterleitung enthalten ist oder nicht?
Mein Skript liest alle Inhalte, die über das CMS eingegeben werden, ein und speichert sie in einer DB-Tabelle. Dabei handelt es sich um eine Volltextsuche mit Cache für Suchanfragen.
Damit die Inhalte aber indexiert werden können, benötige ich die vollständigen Seiteninhalte.
Das CMS (Redaxo) gibt mir dabei die Artikel mit Hilfe der Ausgabepufferfunktionen zurück. Ist innerhalb eines solchen Artikels eine Weiterleitung, so wird diese ausgeführt und führt somit zum Skriptabbruch.

Mal eine blöde Frage: Die Inhalte der Seiten stehen direkt in den Skripten (die eventuell auch weiterleiten) und nicht in eigenen (Text-)Dateien oder einer Datenbank?

Tschö, Auge

[Hopsel]

Hi Auge!

Mal eine blöde Frage: Die Inhalte der Seiten stehen direkt in den Skripten (die eventuell auch weiterleiten) und nicht in eigenen (Text-)Dateien oder einer Datenbank?

Die Inhalte stehen in einer Datenbank. Allerdings werden einzelne Seiten, auch Artikel genannt, aus Blöcken zusammengesetzt. Ich könnte sicherlich die Artikel selbst mit den Blöcken aus der Datenbank zusammensetzen. Allerdings wollte ich lieber auf eine leicht wartbare und übersichtliche Möglichkeit zurückgreifen.
Ich bin dabei daran gescheitert, dass das CMS selbst keine saubere Methode für meinen Spezialfall zur Verfügung stellt.

Da file_get_contents gut funktioniert und "allow_url_fopen" per Standard angeschaltet ist, bin ich mit dieser Lösung sehr zufrieden.

MfG H☼psel

[Edgar Ehritt]

Re:

Allerdings wollte ich lieber auf eine leicht wartbare und übersichtliche Möglichkeit zurückgreifen.

Und was friemest Du da dann mit Datenbanken rum? *scnr*

Gruß aus Berlin!
eddi

[Edgar Ehritt]

Re:

Was kümmert es dich dann, ob da eine Weiterleitung enthalten ist oder nicht?
Mein Skript liest alle Inhalte, die über das CMS eingegeben werden, ein und speichert sie in einer DB-Tabelle. Dabei handelt es sich um eine Volltextsuche mit Cache für Suchanfragen.
Damit die Inhalte aber indexiert werden können, benötige ich die vollständigen Seiteninhalte.

Das hat aber nichts damit zu tun, dass einer der Nutzer einen HTTP-Header (willentlich) setzt.

Das CMS (Redaxo) gibt mir dabei die Artikel mit Hilfe der Ausgabepufferfunktionen zurück. Ist innerhalb eines solchen Artikels eine Weiterleitung, so wird diese ausgeführt und führt somit zum Skriptabbruch.

Nach RFC 2616; 10.3.2, 10.3.3 und 10.3.8 soll zwar immer ein kleiner Text begleitend ausgegeben werden, jedoch dürfte dessen Inhalt für eine Suche ohne Relevanz sein. So das Script abbricht, ist es schlampig programmiert. Weiterhin ist mir aber auch nicht klar, warum Ausführung von PHP-Code nötig sein soll, wenn für eine Suche der Ausgabepuffer indiziert wird, der möglicherweise auf Konditionen unterschiedlichen Besuchern basiert. Im Cache ginge die Kondition jedenfalls verloren. So sehe ich nach meinem Verständnis file_get_contents() keineswegs als "optimal".

Gruß aus Berlin!
eddi

[Hopsel]

Hi Edgar!

Ein dickes Dankeschön, dass du dich so intensiv mit meinem Problem auseinandersetzt.

Damit die Inhalte aber indexiert werden können, benötige ich die vollständigen Seiteninhalte.
Das hat aber nichts damit zu tun, dass einer der Nutzer einen HTTP-Header (willentlich) setzt.

Ähm. Nein. Ich kann aber nicht beeinflussen welcher Code von Nutzern in das CMS geschrieben wird.

Das CMS (Redaxo) gibt mir dabei die Artikel mit Hilfe der Ausgabepufferfunktionen zurück. Ist innerhalb eines solchen Artikels eine Weiterleitung, so wird diese ausgeführt und führt somit zum Skriptabbruch.
Nach RFC 2616; 10.3.2, 10.3.3 und 10.3.8 soll zwar immer ein kleiner Text begleitend ausgegeben werden, jedoch dürfte dessen Inhalt für eine Suche ohne Relevanz sein.

Außerdem ist es vollkommen irrelevant für mein Skript.
Das benötigt die Inhalte der Seiten, egal, um welche es sich handelt.

So das Script abbricht, ist es schlampig programmiert.

Ich versuch noch mal Schritt für Schritt zu erklären, wie das Alles abläuft.

1. Ein Artikel wird aus mehreren Blöcken zusammengestellt.
2. Ein Block enthält z. B. folgenden Code:
   header('Location: http://example.org');
3. Mein Skript bekommt über eine CMS-interne Funktion den Inhalt des Artikels.
   Diese Funktion arbeitet mit der Ausgabepufferung von PHP:
   -> Die Weiterleitung wird ausgeführt
5. Mein Skript wird nicht mehr ausgeführt, da die Weiterleitung erfolgte.

Da ich für meine Volltextsuche allerdings die Inhalte aller Artikel benötige, können eben auch solche "schwarze Schafe" enthalten sein.
Jetzt ist es beim Aufbau des Suchindex´ natürlich suboptimal (eher inakzeptabel), wenn das Skript dabei abbricht und die Indexierung nicht fortgeführt wird.

Da mir das CMS keine Funktion anbietet, an den Quellcode der Artikel in Textform zu gelangen, suchte ich eine Möglichkeit, Weiterleitungen zu verhindern. (Im übrigen kann die Indexierung ja auch nicht über den Quellcode, der u. a. auch PHP-Code enthalten kann, erfolgen, sondern muss ja mit der eigentlichen Frontendausgabe arbeiten.)

Ich hoffe, ich verstehe deine nachfolgende Antwort richtig und kann sie angemessen kommentieren.

Weiterhin ist mir aber auch nicht klar, warum Ausführung von PHP-Code nötig sein soll, wenn für eine Suche der Ausgabepuffer indiziert wird, der möglicherweise auf Konditionen unterschiedlichen Besuchern basiert.

Eine Suche in dynamischen Seiten, die auf unterschiedliche Parameter auch unterschiedlich reagieren, wird anders realisiert und erfordert die Indexierung von zusätzlichen DB-Spalten.

Im Cache ginge die Kondition jedenfalls verloren. So sehe ich nach meinem Verständnis file_get_contents() keineswegs als "optimal".

Das ist nicht das Problem. Die Artikel des CMS sind p. d. statisch.

Die Ausführung von PHP-Code innerhalb der Artikel ist nötig, weil die Suche ja die eigentlichen Inhalte indexieren soll.
Sie darf aber meine Indexierung nicht stoppen.

Stell dir vor, in einem Artikel wird ein Liste mit Informationen aus der Datenbank generiert. Soll jetzt der PHP-Code, der die Liste erzeugt oder die Liste selbst indexiert werden?

MfG H☼psel

[Edgar Ehritt]

Re:

Stell dir vor, in einem Artikel wird ein Liste mit Informationen aus der Datenbank generiert. Soll jetzt der PHP-Code, der die Liste erzeugt oder die Liste selbst indexiert werden?

Jetzt verstehe ich...
Stell Dir vor, dass sicher keiner Deiner Webdesinger so dämlich sein wird, eine Datenbankabfrage nach einem weiterleitenden header-Aufruf machen wird.

Ein dickes Dankeschön, dass du dich so intensiv mit meinem Problem auseinandersetzt.

So, und wer leckt mir jetzt den Honig um den Bart ab?

Gruß aus Berlin!
eddi

[Auge]

Hallo

Ich versuch noch mal Schritt für Schritt zu erklären, wie das Alles abläuft.

1. Ein Artikel wird aus mehreren Blöcken zusammengestellt.
2. Ein Block enthält z. B. folgenden Code:
      header('Location: http://example.org');
3. Mein Skript bekommt über eine CMS-interne Funktion den Inhalt des Artikels.

Spätestens an dieser Stelle ist dein Konzept fehlerhaft. Gut, selbst die Skripte, die vor der Ausgabe einer Seite zum Zuge kommen, stehen in der DB als zur Seite gehörig. Gesetzt den Fall, du würdest deine Inhalte nicht über die fertig geparste Seite sondern über die in der DB hinterlegten Seitenteile indizieren, kannst du prüfen, ob ein Bestandteil (Block) der Seite zum Code oder zum Inhalt gehört?

Da mir das CMS keine Funktion anbietet, an den Quellcode der Artikel in Textform zu gelangen, suchte ich eine Möglichkeit, Weiterleitungen zu verhindern. (Im übrigen kann die Indexierung ja auch nicht über den Quellcode, der u. a. auch PHP-Code enthalten kann, erfolgen, sondern muss ja mit der eigentlichen Frontendausgabe arbeiten.)

Das ist nicht das Problem. Die Artikel des CMS sind p. d. statisch.

Na offensichtlich sind sie das nicht, sonst bräuchte es keinen PHP-Code in ihnen.

Die Ausführung von PHP-Code innerhalb der Artikel ist nötig, weil die Suche ja die eigentlichen Inhalte indexieren soll.

Also sind die Seiten wirklich nicht statisch.

Stell dir vor, in einem Artikel wird ein Liste mit Informationen aus der Datenbank generiert. Soll jetzt der PHP-Code, der die Liste erzeugt oder die Liste selbst indexiert werden?

Warum ist der betreffende Code im Bereich der Ausgabe?

Tschö, Auge

[Hopsel]

Hi Auge!

Auch dir danke ich für deine Mühe.

Ich versuch noch mal Schritt für Schritt zu erklären, wie das Alles abläuft.

1. Ein Artikel wird aus mehreren Blöcken zusammengestellt.
2. Ein Block enthält z. B. folgenden Code:
      header('Location: http://example.org');
3. Mein Skript bekommt über eine CMS-interne Funktion den Inhalt des Artikels.
   Spätestens an dieser Stelle ist dein Konzept fehlerhaft.

Begründung?

Gut, selbst die Skripte, die vor der Ausgabe einer Seite zum Zuge kommen, stehen in der DB als zur Seite gehörig.

Richtig.

Gesetzt den Fall, du würdest deine Inhalte nicht über die fertig geparste Seite sondern über die in der DB hinterlegten Seitenteile indizieren, kannst du prüfen, ob ein Bestandteil (Block) der Seite zum Code oder zum Inhalt gehört?

Nein, Code ist (lies: produziert) Inhalt. Wie der Code aussieht, ist aus meiner Sicht irrelevant, da ich nur das Ergebnis, das der Code produziert, brauche.

Das ist nicht das Problem. Die Artikel des CMS sind p. d. statisch.
Na offensichtlich sind sie das nicht, sonst bräuchte es keinen PHP-Code in ihnen.

Statisch sind diese Artikel im Sinne der Suche schon. Ein einmal indexierter Artikel verändert sich nicht. Wenn doch, so wird er (= seine Ausgabe) neu indexiert ist für die Suche somit wieder statisch.
PHP-Code ist deshalb vollkommen uninteressant. Mich interessiert ja nur, was auch ein "normaler" Benutzer sieht, weil dass das einzige ist, in dem gesucht werden kann/soll.

Die Ausführung von PHP-Code innerhalb der Artikel ist nötig, weil die Suche ja die eigentlichen Inhalte indexieren soll.
Also sind die Seiten wirklich nicht statisch.

Während der Indexierung müssen die Seiten natürlich ausgeführt werden, um deren Ausgabe statisch im Suchindex zu hinterlegen.

Stell dir vor, in einem Artikel wird ein Liste mit Informationen aus der Datenbank generiert. Soll jetzt der PHP-Code, der die Liste erzeugt oder die Liste selbst indexiert werden?
Warum ist der betreffende Code im Bereich der Ausgabe?

Weil das CMS so funktioniert und auch gerade das eines seiner Stärken ist.
Entwickler, die damit arbeiten, haben vollkommene Freiheit, wie und was sie programmieren. Das CMS bietet nur das Grundgerüst.

Es handelt sich übrigens um http://redaxo.de@Redaxo, falls es dich interessiert.

MfG H☼psel

[Auge]

Hallo

1. Ein Artikel wird aus mehreren Blöcken zusammengestellt.
2. Ein Block enthält z. B. folgenden Code:
      header('Location: http://example.org');
3. Mein Skript bekommt über eine CMS-interne Funktion den Inhalt des Artikels.
   Spätestens an dieser Stelle ist dein Konzept fehlerhaft.
   Begründung?

Weil in diesem Moment Code ausgeführt wird, der dein Suchkonzept (zer)stört. Da beißt sich was.

Gesetzt den Fall, du würdest deine Inhalte nicht über die fertig geparste Seite sondern über die in der DB hinterlegten Seitenteile indizieren, kannst du prüfen, ob ein Bestandteil (Block) der Seite zum Code oder zum Inhalt gehört?
Nein, Code ist (lies: produziert) Inhalt. Wie der Code aussieht, ist aus meiner Sicht irrelevant, da ich nur das Ergebnis, das der Code produziert, brauche.

Leider bekommst du das gelegentlich (oder immer?) nicht.

Das ist nicht das Problem. Die Artikel des CMS sind p. d. statisch.
Na offensichtlich sind sie das nicht, sonst bräuchte es keinen PHP-Code in ihnen.
Statisch sind diese Artikel im Sinne der Suche schon. Ein einmal indexierter Artikel verändert sich nicht. Wenn doch, so wird er (= seine Ausgabe) neu indexiert ist für die Suche somit wieder statisch.
PHP-Code ist deshalb vollkommen uninteressant. Mich interessiert ja nur, was auch ein "normaler" Benutzer sieht, weil dass das einzige ist, in dem gesucht werden kann/soll.

Du siehst aber offensichtlich genau das nicht (ab und zu?).

Die Ausführung von PHP-Code innerhalb der Artikel ist nötig, weil die Suche ja die eigentlichen Inhalte indexieren soll.
Also sind die Seiten wirklich nicht statisch.
Während der Indexierung müssen die Seiten natürlich ausgeführt werden, um deren Ausgabe statisch im Suchindex zu hinterlegen.

Mal 'ne blöde Idee. Wie wäre es, die Seite über http anzufordern. So bekäme sie das Indexierungsskript wie irgendein Client zu Gesicht und müsste nur noch den HTML-Quelltext parsen.

Es handelt sich übrigens um http://redaxo.de@Redaxo, falls es dich interessiert.

Das habe ich schon registriert. Ich halte das Konzept im Zusammenhang mit deinem Suchskript für nicht passend (es könnte aber auch dein Skript sein). :-)

Tschö, Auge

[ChrisB]

Hi,

Mal 'ne blöde Idee. Wie wäre es, die Seite über http anzufordern.

Hey, nenn' meine Idee nicht blöd!!!1elf

SCNR ChrisB

[Auge]

Hallo

Mal 'ne blöde Idee. Wie wäre es, die Seite über http anzufordern.

Hey, nenn' meine Idee nicht blöd!!!1elf

Na denn eben nich! :-)

Tschö, Auge

[ChrisB]

Hi,

Problem: Wenn in einem Skript folgender Code vorkommt, wird natürlich auch mein Skript weitergeleitet:
header('Location: http://example.org');

Kann ich diese Weiterleitung verhindern?

Wenn du PHP > 5.3.0 hast, könntest du versuchen, mittels headers_ list und header_remove solche zu finden und wieder zu "deaktivieren".

Das dürfte natürlich auch nicht mehr funktionieren, wenn ein Nutzer in seinem Script wiederum den Buffer schon flusht.

Diesen "Text" benötige ich für weitere Verarbeitung und Speicherung.
Das funktioniert über die Ausgabepufferfunktionen von PHP auch sehr gut.

Benötigst du wirklich nur die Ausgabe dieser Nutzerscripte (und keinerlei PHP-Variablen, die sie bereitstellen)?
Dann könntest du sie über HTTP abrufen - file_get_contents, oder sonstwas. Dann können sie immer noch zu example.org umleiten - aber es beendet wenigstens *deine* Scriptinstanz nicht mehr.

MfG ChrisB

[Hopsel]

Hi ChrisB!

Problem: Wenn in einem Skript folgender Code vorkommt, wird natürlich auch mein Skript weitergeleitet:
header('Location: http://example.org');
Kann ich diese Weiterleitung verhindern?
Wenn du PHP > 5.3.0 hast, könntest du versuchen, mittels headers_ list und header_remove solche zu finden und wieder zu "deaktivieren".

Wieder was gelernt.
Ich werde diese Möglichkeit im Hinterkopf behalten.

Benötigst du wirklich nur die Ausgabe dieser Nutzerscripte (und keinerlei PHP-Variablen, die sie bereitstellen)?
Dann könntest du sie über HTTP abrufen - file_get_contents, oder sonstwas. Dann können sie immer noch zu example.org umleiten - aber es beendet wenigstens *deine* Scriptinstanz nicht mehr.

Ich weiß nicht, warum ich darauf nicht selbst gekommen bin.
Das ist auf jeden Fall genau das, was ich gesucht habe.

Dankeschön!

MfG H☼psel