$_POST von Fremden Server wird verarbeitet

[Malcolm Beck´s]

hi,

Ich habe auf meiner Seite ein Cache-verzeichnis für Smarty, jetzt habe ich mir auf der Admin-Seite ein Formular eingebaut, dass beim absenden das Cache-Verzeichnis leert, soweit so gut.

Jetzt habe ich gerade dieses Formular auf eine andere Domain hochgeladen und ins action meine Domain angegeben:

<form action="http://dj-tut.de/" method="post">  
<input type="submit" name="cache_bereinigen_" value="Cache clean" />  
<!-- Online heisst es natürlich anders -->  
</form>

Jetzt wird das Cache auch geleert, wenn dieses Formular nicht direkt von meiner eigenen Domain abgeschickt wird, warum?
Liegt das am safe_mode? Das ist bei mir deaktiviert und soll es auch bleiben.
Wie kann ich das abfangen, reicht hier eine überprüfung auf $_SERVER['REMOTE_ADDR'] oder gibt es da eine ini-Direktive oder eine andere Funktion für?

mfg

[Cheatah]

Hi,

Jetzt wird das Cache auch geleert, wenn dieses Formular nicht direkt von meiner eigenen Domain abgeschickt wird, warum?

weil HTTP kein "von" kennt.

Liegt das am safe_mode?

Nein, an HTTP.

Wie kann ich das abfangen, reicht hier eine überprüfung auf $_SERVER['REMOTE_ADDR'] oder gibt es da eine ini-Direktive oder eine andere Funktion für?

Es gibt kein "von". Da es sich aber um eine Funktion handelt, die (vermute ich) nur einem begrenzten Nutzerkreis zur Verfügung stehen soll, kannst Du den Referer überprüfen - zumindest kannst Du Dir selbst die Bedingung setzen, dass dieser korrekt sein muss, so dass Du nicht fälschlich abgelehnt wird. Natürlich kann jeder andere noch immer den Referer fälschen und somit "von" jedem x-beliebigen Ort aus den Request durchführen, so dass Du damit nicht das geringste gewonnen hast.

Du möchtest einen Login oder eine Authentifizierung einrichten.

Cheatah

[Malcolm Beck´s]

hi,

Es gibt kein "von". Da es sich aber um eine Funktion handelt, die (vermute ich) nur einem begrenzten Nutzerkreis zur Verfügung stehen soll, kannst Du den Referer überprüfen - zumindest kannst Du Dir selbst die Bedingung setzen, dass dieser korrekt sein muss, so dass Du nicht fälschlich abgelehnt wird. Natürlich kann jeder andere noch immer den Referer fälschen und somit "von" jedem x-beliebigen Ort aus den Request durchführen, so dass Du damit nicht das geringste gewonnen hast.

Das werde ich wohl machen, da es Tatsächlich nur für mich gedacht ist.

Gibt es denn Generell keine Server-Einstellung, die dieses verhalten unterbindet? Das wirkt auf mich wie eine Fehlfunktion, wenn Fremde Server auf meinem einen POST-Request absetzen können und dieser auch noch bearbeitet wird.

Du möchtest einen Login oder eine Authentifizierung einrichten.

Das problem ist, dass ich, um den Smarty-Cache zu leeren, mich auf der „index.php“ befinden muss, wenn ich die Funktion $smarty->clear_all_cache(); aufrufe; ich möchte mein Script für diese Kleinigkeit nicht unnötig überfrachten.

mfg

[dedlfix]

echo $begrüßung;

Das wirkt auf mich wie eine Fehlfunktion, wenn Fremde Server auf meinem einen POST-Request absetzen können und dieser auch noch bearbeitet wird.

In deinem Fall ist es kein fremder Server. Der Request-Steller ist immer ein Client und der Server ist deine Kiste. Und das Verhalten gehört so. Jeder "fremde" Client (meist Browser genannt) muss POST-Requests an beliebige Server absenden können.

» Du möchtest einen Login oder eine Authentifizierung einrichten.
[...] ich möchte mein Script für diese Kleinigkeit nicht unnötig überfrachten.

So ein Cache-Löschen ist ja keine sicherheitskritische Angelegenheit. Wenn er leer ist, wird er eben neu erstellt. Geht nur anfangs ein bisschen zu Lasten der Performance. Ruf doch die Funktion mit einem händisch angehängten Parameter auf verlinke diesen Aufruf nicht. Dann ruft es auch keiner versehentlich auf. Und wenn es doch einer rausfindet - was soll's ...

echo "$verabschiedung $name";

[Malcolm Beck´s]

hi,

So ein Cache-Löschen ist ja keine sicherheitskritische Angelegenheit. Wenn er leer ist, wird er eben neu erstellt. Geht nur anfangs ein bisschen zu Lasten der Performance. Ruf doch die Funktion mit einem händisch angehängten Parameter auf verlinke diesen Aufruf nicht. Dann ruft es auch keiner versehentlich auf. Und wenn es doch einer rausfindet - was soll's ...

Mir ging es bei dem versuch auch darum, zu testen, warum Diverse andere Server auf meinen Seiten Post-Requests absetzen.
Ich sehe oft in meinen logs, dass irgendwelche Seiten mit einmaligem betreten meiner Seiten auch gleichzeitig bei mir einen Post absetzen (wenn ein Formular vorhanden ist), ohne die Seite erstmal „Regulär (GET)“ aufzurufen.

Ich hatte mich gefragt, was dass bringen könnte und ob so ein Request überhaupt Akzeptiert/ bearbeitet wird.

Danke jedenfalls für die Erklärungen hier.

mfg

[Cheatah]

Hi,

um Missverständnissen vorzubeugen:

Mir ging es bei dem versuch auch darum, zu testen, warum Diverse andere Server auf meinen Seiten Post-Requests absetzen.

Nicht der Server setzt einen Request ab, sondern ein Client. Wenn tatsächlich eine auf einem Server laufende Software den Request abfeuert, so ist dieser in dem Moment ein Client - vermutlich meinst Du jedoch eher Fälle, wo tatsächlich ein "nicht-Server-Client" (also z.B. ein Browser) die Anforderung tätigt.

Und zu diesen noch einmal: Der Request hat *nichts* mit fremden Seiten zu tun! Er ist absolut unabhängig davon, egal ob die fremde Seite ein Formular mit einer Referenz zu Deinem Server aufweist oder nicht. Ob der Client Dir mitteilt, dass er gerade eine solche Seite darstellt, oder ob er dies nicht tut, oder ob er eine Seite nennt, die er überhaupt nicht anzeigt und vielleicht sogar noch nie angezeigt hat, bleibt absolut ihm überlassen.

Ich sehe oft in meinen logs, dass irgendwelche Seiten mit einmaligem betreten meiner Seiten auch gleichzeitig bei mir einen Post absetzen

Tun sie nicht. Clients tun das. Und sie lügen dabei.

Cheatah

[Sven Rautenberg]

Moin!

Und zu diesen noch einmal: Der Request hat *nichts* mit fremden Seiten zu tun! Er ist absolut unabhängig davon, egal ob die fremde Seite ein Formular mit einer Referenz zu Deinem Server aufweist oder nicht. Ob der Client Dir mitteilt, dass er gerade eine solche Seite darstellt, oder ob er dies nicht tut, oder ob er eine Seite nennt, die er überhaupt nicht anzeigt und vielleicht sogar noch nie angezeigt hat, bleibt absolut ihm überlassen.

Man stelle sich folgendes Real-Welt-Beispiel vor:

Malcolms Server hält irgendwo einen großen Papierstapel mit Blankoformularen vor. Jedermann kann sich dort ein oder mehrere Exemplare vom Stapel nehmen. Und genauso kann jemand auch einfach einen den ganzen Stapel mitnehmen, um ihn irgendwo anders zu platzieren - egal, der Server sorgt automatisch für Nachschub.

Außerdem gibts die Formularempfangsstelle. Das ist der Briefkasten, in den ausgefüllte Formulare eingeworfen werden. Dummerweise: Der Stapel mit den Blankoformularen ist vom Briefkasten aus nicht zu sehen. Man kann nicht kontrollieren, ob derjenige, der gerade ein Formular einwirft (= einen POST-Request macht) vorher brav ein Formular vom eigenen Stapel geholt hat, oder ob derjenige das Formular woanders her hat.

Außer natürlich, man baut die Formularausgabestelle aus und setzt jemanden dort hin, der jedem Formular eine Seriennummer gibt, eine Liste von ausgegebenen Seriennummern führt, und bei zurückkommenden Formularen prüft, ob deren Seriennummer stimmt.

- Sven Rautenberg

[Malcolm Beck´s]

hi,

Außer natürlich, man baut die Formularausgabestelle aus und setzt jemanden dort hin, der jedem Formular eine Seriennummer gibt, eine Liste von ausgegebenen Seriennummern führt, und bei zurückkommenden Formularen prüft, ob deren Seriennummer stimmt.

Danke erstmal für das Verständliche Beispiel, jetzt habe ich es verstanden.

Also müsste ich im Prinzip einfach nur ein hidden-Feld in mein Formular einbauen, in dem ich ein „Passwort“ festlege, den niemand kennt (so lange er nicht ins Backend kommt); solange niemand Einblick ins Backend hat, kann er diese Daten auch nicht wissen.

mfg

[Sven Rautenberg]

Moin!

»» Außer natürlich, man baut die Formularausgabestelle aus und setzt jemanden dort hin, der jedem Formular eine Seriennummer gibt, eine Liste von ausgegebenen Seriennummern führt, und bei zurückkommenden Formularen prüft, ob deren Seriennummer stimmt.

Danke erstmal für das Verständliche Beispiel, jetzt habe ich es verstanden.

Also müsste ich im Prinzip einfach nur ein hidden-Feld in mein Formular einbauen, in dem ich ein „Passwort“ festlege, den niemand kennt (so lange er nicht ins Backend kommt); solange niemand Einblick ins Backend hat, kann er diese Daten auch nicht wissen.

Das Passwort kennt er ja jeder - denn es steht im Hidden-Feld. Und das ist öffentlich, auch wenn es im Browser erstmal nicht dargestellt wird - es ist ja im Quelltext.

- Sven Rautenberg

[Malcolm Beck´s]

hi,

Das Passwort kennt er ja jeder - denn es steht im Hidden-Feld. Und das ist öffentlich, auch wenn es im Browser erstmal nicht dargestellt wird - es ist ja im Quelltext.

Das Formular selbst ist im Admin-Bereich, also nur für Authorisierte User (mich); auf der Öffentlich zugänglichen index.php prüfe ich lediglich, ob es einen Post zum Cache-löschen gab.

mfg

[EKKi]

Mahlzeit Malcolm Beck´s,

Also müsste ich im Prinzip einfach nur ein hidden-Feld in mein Formular einbauen, in dem ich ein „Passwort“ festlege, den niemand kennt

Du solltest dort kein allgemeines "Passwort" angeben, sondern eher eine Art "Coupon", der nicht erratbar (Stichwort MD5) und nur einmalig gültig ist. Dafür sollte auf dem Server gespeichert werden, an wen (d.h. welchen Benutzer oder welchen Session-Cookie) welcher "Coupon" ausgegeben wurde. Wenn dann der richtige Benutzer (bzw. Browser mittels Session-Cookie) einen Request mit einem passenden, noch nicht benutzten "Coupon" absetzt, wird es verarbeitet und der "Coupon" "entwertet". Wenn jemand ohne oder mit ungültigem bzw. entwerteten "Coupon" kommt, passiert nichts oder es kommt ein entsprechender Hinweis.

(so lange er nicht ins Backend kommt); solange niemand Einblick ins Backend hat, kann er diese Daten auch nicht wissen.

"Security by obscurity" funktioniert nie.

MfG,
EKKi

[Malcolm Beck´s]

hi EKKi,

Du solltest dort kein allgemeines "Passwort" angeben, sondern eher eine Art "Coupon", der nicht erratbar (Stichwort MD5) und nur einmalig gültig ist. Dafür sollte auf dem Server gespeichert werden, an wen (d.h. welchen Benutzer oder welchen Session-Cookie) welcher "Coupon" ausgegeben wurde. Wenn dann der richtige Benutzer (bzw. Browser mittels Session-Cookie) einen Request mit einem passenden, noch nicht benutzten "Coupon" absetzt, wird es verarbeitet und der "Coupon" "entwertet". Wenn jemand ohne oder mit ungültigem bzw. entwerteten "Coupon" kommt, passiert nichts oder es kommt ein entsprechender Hinweis.

Das klingt nach einer interessanten Übung, werde mich mal dran versuchen.

mfg

[EKKi]

Mahlzeit Malcolm Beck´s,

Gibt es denn Generell keine Server-Einstellung, die dieses verhalten unterbindet?

Nein.

Das wirkt auf mich wie eine Fehlfunktion,

Nein.

wenn Fremde Server auf meinem einen POST-Request absetzen können und dieser auch noch bearbeitet wird.

Du hast die Funktionsweise von HTTP anscheinend noch nicht ganz verstanden. Den POST-Request setzt der Client ab. Er richtet diesen Request im Regelfall an den Server, der im "http://de.selfhtml.org/html/formulare/definieren.htm#bereich@title=action"-Attribut des jeweiligen Formulars genannt ist - und dabei spielt es absolut keine Rolle, ob er das HTML-Dokument, in dem sich das Formular befindet, von ebendiesem Server, von einem anderen oder vielleicht lokal auf der Platte gespeichert hat.

Das ist weder eine Fehlfunktion, noch eine Sicherheitslücke, sondern absolut so gewollt.

Es ist und bleibt das Problem desjenigen, der eine Ressource, die POST-Requests verarbeitet, anbietet, diese Ressource so abzusichern, dass sie nur sinnhafte Requests verarbeitet und im Rahmen dieser Verarbeitung ggf. überprüft, ob der Requests überhaupt fachlich zulässig ist.

MfG,
EKKi

[Cheatah]

Hi,

kleine Ergänzung und Wiederholung, weil es offenbar immer noch Zweifel gibt:

Du hast die Funktionsweise von HTTP anscheinend noch nicht ganz verstanden. Den POST-Request setzt der Client ab. Er richtet diesen Request im Regelfall an den Server, der im "http://de.selfhtml.org/html/formulare/definieren.htm#bereich@title=action"-Attribut des jeweiligen Formulars genannt ist - und dabei spielt es absolut keine Rolle, ob er das HTML-Dokument, in dem sich das Formular befindet, von ebendiesem Server, von einem anderen oder vielleicht lokal auf der Platte gespeichert hat.

... oder es gar keines gibt. HTTP ist nicht von einem HTML-Dokument abhängig - es kennt kein "von".

Das ist weder eine Fehlfunktion, noch eine Sicherheitslücke, sondern absolut so gewollt.

Jupp.

Cheatah

[ChrisB]

Hi,

Gibt es denn Generell keine Server-Einstellung, die dieses verhalten unterbindet? Das wirkt auf mich wie eine Fehlfunktion, wenn Fremde Server auf meinem einen POST-Request absetzen können und dieser auch noch bearbeitet wird.

Dass diese Server in dem Falle Clients "sind", also bezogen auf eine HTTP-Kommunikation die Rolle des Clients uebernehmen, wurde dir ja bereits gesagt.

Wenn so etwas jetzt eine "Fehlfunktion" waere - dann koenntest du gar nicht hier im Forum schreiben. Denn dabei sendet dein Browser, ein Client, der dem Server, auf dem das Forum laeuft, mindestens ebenso "fremd" ist, wie dir der anfragende Client in deinem Szenario, einen POST-Request an eben diesen Server, auf dem das Forum laeuft.
Waere reichlich bloed, wenn der jetzt sagen wuerde, "wer bist du denn, dich kenn' ich nicht, von dir lass' ich mich doch nicht bePOSTen ..."

MfG ChrisB

[Auge]

Hallo

Du möchtest einen Login oder eine Authentifizierung einrichten.

Bei einer Authentifizierung per .htaccess kann Malcolm nicht nur auf den (unsicheren) Referrer, sondern auch, was meiner Meinung nach sicherer ist, auf den authentifizierten Benutzer bzw. auf dessen Anmeldenamen prüfen. Damit schlösse er auch die Benutzung durch andere authentifizierte Benutzer aus, wenn ihnen diese Funktion nicht zur Verfügung stehen soll. Ginge auch per Login, ich würde mich da aber eher auf den Server verlassen.

Tschö, Auge

[Malcolm Beck´s]

hi,

Bei einer Authentifizierung per .htaccess kann Malcolm nicht nur auf den (unsicheren) Referrer, sondern auch, was meiner Meinung nach sicherer ist, auf den authentifizierten Benutzer bzw. auf dessen Anmeldenamen prüfen. Damit schlösse er auch die Benutzung durch andere authentifizierte Benutzer aus, wenn ihnen diese Funktion nicht zur Verfügung stehen soll. Ginge auch per Login, ich würde mich da aber eher auf den Server verlassen.

Nochmal mein Beispiel:

Ich habe eine „index.php“, über die die Gesamte Ausgabe der Inhalte erfolgt (ohne Authentifizierung), in dieser steht auch die prüfung drin, um das Cache zu leeren.
Dann habe ich ein Admin-Verzeichnis, dass ich mit .htaccess schütze, in diesem Verzeichnis habe ich mein Formular, dass im action-Attribut auf die index.php zielt, um dass löschen des Caches zu veranlassen.

So sieht es aus:

Admin-Backend steht das Formular:

<form action="/" method="post">  
<input type="submit" name="cachecleaner" value="Cache säubern" />  
</form>

Auf der Regulären „index.php“ prüfe ich dann einfach auf POST:

  if (isset($_POST['cachecleaner']))  
  {  
    if ($_POST['cachecleaner'] == 'Cache säubern')  
    {  
      $smarty->clear_all_cache();  
    }  
  }

Ich werde dass ganze jetzt noch um ein input-hidden erweitern; aber wie könnte ich dass noch mit einer Authentifizierung lösen?

Die Function $smarty->clear_all_cache(); Funktioniert nur, wenn ich sie auf der „index.php“ aufrufe und nicht über das „Admin-Backend“ (ansonsten hätte ich dieses Problem nicht).

mfg

[Auge]

Hallo

Admin-Backend steht das Formular:

<form action="/" method="post">

<input type="submit" name="cachecleaner" value="Cache säubern" />
</form>

  

> Ich werde dass ganze jetzt noch um ein input-hidden erweitern; aber wie könnte ich dass noch mit einer Authentifizierung lösen?  
  
Wenn du dich gegenüber dem Webserver per .htaccess authentifizierst, wird der Benutzername bei jedem Seitenzugriff an den Server übermittelt, solange der Browser nicht geschlossen wird. So weit, so klar. Aus dem Array $\_SERVER ist der Benutzername auslesbar. Es gibt zwei Möglichkeiten, wie der Schlüssel heißt, das kommt, wenn ich nicht irre, darauf an, ob PHP als Modul oder CGI läuft. Schau einfach in die Ausgabe von phpinfo(), die innerhalb deines Admin-Backends aufgerufen wird.  
  
Danach sollte dein Cachelöscher etwa so aufgerufen werden:  
  
~~~php
if (isset($_POST['cachecleaner'])  
   and $_POST['cachecleaner']=='Cache säubern'  
   and !empty($_SERVER['AUTH_USER'])  
   and $_SERVER['AUTH_USER']=='Malcolms_Benutzername'  
   // 'AUTH_USER' ist eine der Möglichkeiten, wie der Schlüssel heißen kann)  
   {  
   $smarty->clear_all_cache();  
   }

Die Voraussetzung wäre allerdings, dass dieser Aufruf innerhalb des Admin-Backends aufgerufen wird.

Die Function $smarty->clear_all_cache(); Funktioniert nur, wenn ich sie auf der „index.php“ aufrufe und nicht über das „Admin-Backend“ (ansonsten hätte ich dieses Problem nicht).

Blöde Frage: Warum geht das nur so?

Tschö, Auge

[Malcolm Beck´s]

hi,

Wenn du dich gegenüber dem Webserver per .htaccess authentifizierst, wird der Benutzername bei jedem Seitenzugriff an den Server übermittelt, solange der Browser nicht geschlossen wird. So weit, so klar. Aus dem Array $_SERVER ist der Benutzername auslesbar. Es gibt zwei Möglichkeiten, wie der Schlüssel heißt, das kommt, wenn ich nicht irre, darauf an, ob PHP als Modul oder CGI läuft. Schau einfach in die Ausgabe von phpinfo(), die innerhalb deines Admin-Backends aufgerufen wird.

Die Konfiguration vom Admin-Backend ist die gleiche wie das Frontend, http://dj-tut.de/info.php -- User: „demo“ Pass: „demo“

Woran erkenne, wie PHP bei mir installiert ist? Ist es die „Server API“? Dann ist es Online „CGI“, Lokal steht dort „Apache 2.0 Handler“.

Die Voraussetzung wäre allerdings, dass dieser Aufruf innerhalb des Admin-Backends aufgerufen wird.

Danke für das Beispiel, aber wie gesagt, wenn ich es vom Admin-Backend aufrufe, bringt dass ja nichts.

» Die Function $smarty->clear_all_cache(); Funktioniert nur, wenn ich sie auf der „index.php“ aufrufe und nicht über das „Admin-Backend“ (ansonsten hätte ich dieses Problem nicht).

Blöde Frage: Warum geht das nur so?

Ich weiss es nicht, vielleicht hat hier jemand Erfahrung mit Smarty und weiss, wie man es noch lösen kann.
Ich habe schon probiert, dass Löschen aus dem Admin-Backend aufzurufen, nur passiert dann nichts.

Ich werde jetzt mal eine andere Möglichkeit versuchen und hier posten.

mfg

[Auge]

Hallo

»» Wenn du dich gegenüber dem Webserver per .htaccess authentifizierst, wird der Benutzername bei jedem Seitenzugriff an den Server übermittelt, solange der Browser nicht geschlossen wird. So weit, so klar. Aus dem Array $_SERVER ist der Benutzername auslesbar. Es gibt zwei Möglichkeiten, wie der Schlüssel heißt, das kommt, wenn ich nicht irre, darauf an, ob PHP als Modul oder CGI läuft. Schau einfach in die Ausgabe von phpinfo(), die innerhalb deines Admin-Backends aufgerufen wird.

Die Konfiguration vom Admin-Backend ist die gleiche wie das Frontend, http://dj-tut.de/info.php -- User: „demo“ Pass: „demo“

Die Seite mit "demo" zu durchsuchen lässt mich $_SERVER["REMOTE_USER"] mit eben diesem Wert finden.

Woran erkenne, wie PHP bei mir installiert ist? Ist es die „Server API“? Dann ist es Online „CGI“, Lokal steht dort „Apache 2.0 Handler“.

Da steht auch, gleich in der dritten Zeile der ersten Tabelle: "Server API: CGI". Das sollte Hinweis genug sein.

Und nun solltest du den Zugang bzw. die info.php flugs löschen, da dort noch einiges mehr über das System zu lesen ist.

»» » Die Function $smarty->clear_all_cache(); Funktioniert nur, wenn ich sie auf der „index.php“ aufrufe und nicht über das „Admin-Backend“ (ansonsten hätte ich dieses Problem nicht).
»»
»» Blöde Frage: Warum geht das nur so?

Ich weiss es nicht, vielleicht hat hier jemand Erfahrung mit Smarty und weiss, wie man es noch lösen kann.

Tut mir leid, da kann ich nicht weiterhelfen.

Tschö, Auge

[Malcolm Beck´s]

hi,

» Die Konfiguration vom Admin-Backend ist die gleiche wie das Frontend, http://dj-tut.de/info.php -- User: „demo“ Pass: „demo“

Die Seite mit "demo" zu durchsuchen lässt mich $_SERVER["REMOTE_USER"] mit eben diesem Wert finden.

Woran kann ich das erkennen bzw. woran erkennst du dass?

» Woran erkenne, wie PHP bei mir installiert ist? Ist es die „Server API“? Dann ist es Online „CGI“, Lokal steht dort „Apache 2.0 Handler“.
Da steht auch, gleich in der dritten Zeile der ersten Tabelle: "Server API: CGI". Das sollte Hinweis genug sein.

Also CGI, Danke.

Und nun solltest du den Zugang bzw. die info.php flugs löschen, da dort noch einiges mehr über das System zu lesen ist.

Ich würde gerne das Risiko eingehen, gehackt zu werden. Mich würde schon interessieren, wo ich lücken im System habe.
Aber du hast wohl recht, werde es gleich entfernen.

mfg

[Auge]

Hallo

»» » Die Konfiguration vom Admin-Backend ist die gleiche wie das Frontend, http://dj-tut.de/info.php -- User: „demo“ Pass: „demo“
»»
»» Die Seite mit "demo" zu durchsuchen lässt mich $_SERVER["REMOTE_USER"] mit eben diesem Wert finden.

Woran kann ich das erkennen bzw. woran erkennst du dass?

Eine Seite mit phpinfo() ist nicht nur zum aufrufen da, sondern auch zum durchlesen von oben *bis unten*. Im unteren Bereich sind die PHP zur Verfügung stehenden Environment-Werte und darunter die PHP-eigenen Entsprechungen (in $_SERVER und $_ENV) zu finden. Dabei in deinem Fall auch $_SERVER['REMOTE_USER'] = 'demo'. Wie gesagt, eine Suche mit 'demo' führt genau dort hin.

»» Und nun solltest du den Zugang bzw. die info.php flugs löschen, da dort noch einiges mehr über das System zu lesen ist.

Ich würde gerne das Risiko eingehen, gehackt zu werden. Mich würde schon interessieren, wo ich lücken im System habe.

Auf einem Produktivsystem? Mächtig leichtsinnig.

Tschö, Auge

[Malcolm Beck´s]

hi,

Eine Seite mit phpinfo() ist nicht nur zum aufrufen da, sondern auch zum durchlesen von oben *bis unten*. Im unteren Bereich sind die PHP zur Verfügung stehenden Environment-Werte und darunter die PHP-eigenen Entsprechungen (in $_SERVER und $_ENV) zu finden. Dabei in deinem Fall auch $_SERVER['REMOTE_USER'] = 'demo'. Wie gesagt, eine Suche mit 'demo' führt genau dort hin.

Danke für den Hinweis, ich hatte nach dem falschen Begriff gesucht, nämlich $_SERVER['REMOTE_USER'], jetzt habe ich es gefunden.
Die PHP-Info lesen ist ja eine Sache für sich, da stehen viele dinge drin, von denen ich nicht den blassesten Schimmer hab.

» Ich würde gerne das Risiko eingehen, gehackt zu werden. Mich würde schon interessieren, wo ich lücken im System habe.

Auf einem Produktivsystem? Mächtig leichtsinnig.

„So“ Produktiv ist der Server nun auch wieder nicht ;)
Das Projekt ist für mich eher eine Spielwiese zum Programmieren lernen, von daher würde das schon passen.

So weit (User: „demo“ Pass: „demo“) bin ich schon, jetzt geht es langsam ins Detail.

mfg

[Auge]

Hallo

Danke für den Hinweis, ich hatte nach dem falschen Begriff gesucht, nämlich $_SERVER['REMOTE_USER'], jetzt habe ich es gefunden.

Jaja, die Sache mit dem richtigen Suchbegriff. :-)

Die PHP-Info lesen ist ja eine Sache für sich, da stehen viele dinge drin, von denen ich nicht den blassesten Schimmer hab.

Vieles davon wird man nie brauchen, das mag aber von Projekt zu Projekt jeweils anderes sein. Wichtig sind die oberen Blöcke mit den php.ini-Einstellungen und die Umgebungsvariablen und ihre PHP-Entsprechungen. Dazu halt noch die Informationen zu der einen oder anderen Erweiterung.

So weit (User: „demo“ Pass: „demo“) bin ich schon, jetzt geht es langsam ins Detail.

Na denn los. Wenn das nicht nur für dich allein sein sollte, du weißt ja, wie es funktioniert, würde ich in der Navigation noch die Hauptmenüpunkte beim Hovern optisch verändern. Dann sieht man bei Verwendung einer Maus auch, wo man mit dem Cursor zu bleiben hat, um die Untermenüs offen zu halten.

Tschö, Auge

[Malcolm Beck´s]

hi,

» Danke für den Hinweis, ich hatte nach dem falschen Begriff gesucht, nämlich $_SERVER['REMOTE_USER'], jetzt habe ich es gefunden.
Jaja, die Sache mit dem richtigen Suchbegriff. :-)

Hat ihre Tücken ;)

Wichtig sind die oberen Blöcke mit den php.ini-Einstellungen und die Umgebungsvariablen und ihre PHP-Entsprechungen. Dazu halt noch die Informationen zu der einen oder anderen Erweiterung.

Die verstehe ich zu grossen teilen bzw. pfusche auch an der einen oder anderen Einstellung da gerne mit (dank dedlfix), nur der Grossteil wird wohl ein Rätsel bleiben.

Na denn los. Wenn das nicht nur für dich allein sein sollte, du weißt ja, wie es funktioniert, würde ich in der Navigation noch die Hauptmenüpunkte beim Hovern optisch verändern. Dann sieht man bei Verwendung einer Maus auch, wo man mit dem Cursor zu bleiben hat, um die Untermenüs offen zu halten.

Danke für den Tipp. http://dj-tut.de/z_test/selfhtml/ul
Und das war Überraschend leicht umgesetzt und vor allem ohne Javascript (nur im FF getestet, befürchte aber dass schlimmste). Und ja, dieses CMS ist erstmal nur für mich bestimmt, und höchst wahrscheinlich wird dieser Status auch auf ewig beibehalten ;)

mfg

[Malcolm Beck´s]

hi,

für das Cache-löschen Problem habe ich jetzt eine ganz einfache lösung gefunden;

Ich habe ins „Root-Verzeichnis“ eine Ressource Namens „clear_cache.php“ angelegt bzw. es liegt unter den Configs und über mod_rewrite wird es umgeschrieben.
Diese Datei wird mittels htaccess geschützt, dass heisst, wenn ich mich erstmal im Admin-Backend eingeloggt habe, ist dieser Login auch auf dem Root-verzeichnis Gültig und somit eine löschung des Caches für mich möglich, wenn ein nicht Authorisierter User versucht, dass Cache zu löschen, wird er nach einem Passwort gefragt, siehe http://dj-tut.de/test.

Im einzelnen sieht das so aus:

.htacces im Root (auf das Wesentliche gekürzt):

AuthUserFile /***/***/.htpasswd  
AuthName "Admin"  
AuthType Basic  
order deny,allow  
<Files ~ "info.php|clear_cache.php">  
        require valid-user  
</Files>

Das Admin-Backend wird komplett geschützt:

AuthUserFile /***/***/.htpasswd  
AuthName "Admin"  
AuthType Basic  
require user Admin  

Somit brauche ich auch garnicht erst mit PHP herumwerkeln. Zumindest dies bezüglich nicht.

Danke allen für die Hilfe.

mfg