jeannie61: phpinfo() verbergen

Guten Abend, hat eine Idee wie man die PHPinfo verbergen kann? Vielen Dank Jeannie

  1. Servus!

    Guten Abend, hat eine Idee wie man die PHPinfo verbergen kann?

    in der .htaccess:

    # protect phpinfo
    <Files php-info.php>
    	Order Deny,Allow
    	Deny from all
    	Allow from 123.456.789
    </Files>
    

    Siehe: Secure your phpinfo.php files with .htaccess Perishable Press

    Herzliche Grüße

    Matthias Scharwies

    --
    "I don’t make typos. I make new words."
    1. Recht vielen Dank Matthias 😀

  2. Tach!

    hat eine Idee wie man die PHPinfo verbergen kann?

    Löschen, wenn der Bedarf befriedigt wurde, sich die Daten anzuzeigen.

    dedlfix.

    1. Mahlzeit,

      Löschen, wenn der Bedarf befriedigt wurde, sich die Daten anzuzeigen.

      Nur mal aus Interesse: Wie löscht man ne Funktion aus PHP? Quelltext patchen und neu Kompilieren? Was hätte das für einen Sinn wenn die Funktion phpinfo() nicht mehr existieren würde?

      --
      42
      1. Mahlzeit,

        Löschen, wenn der Bedarf befriedigt wurde, sich die Daten anzuzeigen.

        Nur mal aus Interesse: Wie löscht man ne Funktion aus PHP?

        die Frage war ja nicht Löschen sonderen Verbergen. Aber um ehrlich zu sein, da bin ich auch ziemlich ratlos. Solch eine Frage ist mir bzw. meinen Kollegen in 20 Jahren Entwicklung nie gestellt worden.

        MfG

        1. Hier gehts mehr darum, ein PHP-Script mit <?php phpinfo(); ?> zu löschen. Nicht die Funktion aus PHP selbst herauszulöschen. Das geht zwar auch, aber man muss PHP danach halt neu kompilieren...

          Die Benutzung der Funktion kann ggf. in der php.ini verboten werden:

          disable_functions = phpinfo,andere,noch_eine
          
          1. security by obscurity

            und was machste wenn sich ein Angreifer seine ganz spezielle phpinfo() selber schreibt? Was sowieso besser wäre wegen der Lesbarkeit.

            disable_functions = phpinfo,andere,noch_eine

            rumpelstilz nicht vergessen!

            MfG

            1. security by obscurity

              Der lockere Spruch macht es dennoch nicht notwendig, einem Angreifer Infos zu liefern, mit denen er sehr viel schneller und/oder unter Vermeidung von Honeypots zum Ziel kommt.

              und was machste wenn sich ein Angreifer seine ganz spezielle phpinfo() selber schreibt?

              Hoffen, dass er vorsichtig ist.

              Was sowieso besser wäre wegen der Lesbarkeit.

              Und man kann die Informationen einschränken. Versionen und Module muss man ja nicht mit raushängen.

          2. Mahlzeit,

            Hier gehts mehr darum, ein PHP-Script mit <?php phpinfo(); ?> zu löschen.

            Na wer hier fragen muss, wie man eine Datei löscht, sollte IMHO nicht ohne Aufsicht eine Webseite verwalten.

            Die Benutzung der Funktion kann ggf. in der php.ini verboten werden:

            disable_functions = phpinfo,andere,noch_eine
            

            Ja, das geht, aber welchen Nutzen sollte das haben?

            --
            42
            1. Mahlzeit,

              Hier gehts mehr darum, ein PHP-Script mit <?php phpinfo(); ?> zu löschen.

              Na wer hier fragen muss, wie man eine Datei löscht, sollte IMHO nicht ohne Aufsicht eine Webseite verwalten.

              :-)

              Die Benutzung der Funktion kann ggf. in der php.ini verboten werden:

              disable_functions = phpinfo,andere,noch_eine
              

              Ja, das geht, aber welchen Nutzen sollte das haben?

              Schnoddrige Antwort: Es beruhigt einerseits die Geschäftsleitung und erklärt warum derjenige, der es veranlasst, eine fürchterlich wichtige, unterbezahlte - aber vor allem unverzichtbare Person ist.

              Aber Spaß beiseite: Im Massenhosting hat man halt Kunden, deren Kenntnisstand und Sicherheitsbewusstsein man nicht mal erahnt und auch nicht beeinflussen kann. (Selbst das Fratzenbuch ist aktuell mal wieder in der Zeitung … aber lassen wir das hier.) Also greift man zu sehr weit und großzügig gefassten technischen Maßnahmen um diese Kunden, deren "Mitbewohner" auf den Servern und vor allem sich selbst zwangsweise vor allerhand Unbill zu schützen.

              1. Mahlzeit,

                Aber Spaß beiseite: Im Massenhosting hat man halt Kunden, deren Kenntnisstand und Sicherheitsbewusstsein man nicht mal erahnt und auch nicht beeinflussen kann. (Selbst das Fratzenbuch ist aktuell mal wieder in der Zeitung … aber lassen wir das hier.) Also greift man zu sehr weit und großzügig gefassten technischen Maßnahmen um diese Kunden, deren "Mitbewohner" auf den Servern und vor allem sich selbst zwangsweise vor allerhand Unbill zu schützen.

                Naja, man kann jede Info, die von phpinfo() ausgegeben wird, auch auf anderen Weg auslesen, sollte man ein PHP-Script einschleusen können. Da erzeugt das deaktivieren von phpinfo() IMHO ein absolut falsches Gefühl von Sicherheit.

                --
                42
        2. Mahlzeit,

          die Frage war ja nicht Löschen sonderen Verbergen.

          naja, dafür reicht ja, dass man nirgends ein phpinfo() in seinem Code hat. Schon ist es verborgen.

          Aber um ehrlich zu sein, da bin ich auch ziemlich ratlos. Solch eine Frage ist mir bzw. meinen Kollegen in 20 Jahren Entwicklung nie gestellt worden.

          Mir auch nicht. Liegt vermutlich daran, dass es keinen Sinn macht, etwas verbergen zu wollen, was eh nur erscheint, wenn man es bewusst anzeigen lässt.

          --
          42
      2. Hallo,

        Nur mal aus Interesse: Wie löscht man ne Funktion aus PHP?

        Was man auf jeden Fall machen könnte, wäre über disable_functions in der php.ini die Funktion abzuschalten.

        Gruß
        Patrick

        1. Mahlzeit,

          Was man auf jeden Fall machen könnte, wäre über disable_functions in der php.ini die Funktion abzuschalten.

          Könnte man, aber was genau sollte das bringen? Ob sich das auf die Laufzeit auswirkt, weiss ich nicht, kann mir aber vorstellen, dass die Prüfung ob eine Funktion erlaubt ist, Zeit frisst. Selbst bei Millisekunden kann das bei grossen Projekten oder grossen Zugriffszahlen durchaus relevant sein.

          --
          42
      3. Tach!

        Löschen, wenn der Bedarf befriedigt wurde, sich die Daten anzuzeigen.

        Nur mal aus Interesse: Wie löscht man ne Funktion aus PHP?

        Abgesehen vom bereits erwähnten disable_functions, was natürlich nicht besonders sinnvoll ist, solange man die Hoheit über seinen eigenen Code hat, ging ich davon aus, dass es sich um eine Datei mit phpinfo()-Aufruf darin handelte.

        dedlfix.

        1. Mahlzeit,

          Nur mal aus Interesse: Wie löscht man ne Funktion aus PHP?

          Abgesehen vom bereits erwähnten [disable_functions]

          Naja, deaktivieren ist nicht löschen. Deshalb frag ich ja, könnte ja sein, dass es in dem Bereich was gibt, was ich noch nicht kenne 😉

          was natürlich nicht besonders sinnvoll ist, solange man die Hoheit über seinen eigenen Code hat,

          Ja, so kann man es ausdrücken, wenn man höflich sein will 😂 Wenn man nicht die Hohheit über seinen Code hat, hat man idR auch nicht die Möglichkeit, die php.ini zu ändern.

          ging ich davon aus, dass es sich um eine Datei mit phpinfo()-Aufruf darin handelte.

          Ich auch, deshalb hat mich gewundert, dass noch keiner belehrend eingegriffen hat, weil die Fragestellung dann falsch ist. Ist doch in diesem Forum sonst auch üblich.

          --
          42
    2. Tach!

      hat eine Idee wie man die PHPinfo verbergen kann?

      Löschen, wenn der Bedarf befriedigt wurde, sich die Daten anzuzeigen.

      Klingt überzeugend!

      .

    3. @@dedlfix

      hat eine Idee wie man die PHPinfo verbergen kann?

      Löschen, wenn der Bedarf befriedigt wurde, sich die Daten anzuzeigen.

      Und was ist vorher? Da ist die phpinfo für jeden sichtbar, der gerade in dem Moment vorbeischaut?

      Für mich stellt sich das so dar: Entweder die phpinfo ist unbedenklich; dann braucht sie keinen Schutz. Oder die phpinfo sollte niemals für Unbefugte sichtbar sein; dann braucht sich auch in dem Moment einen Schutz (zumindest Basic Authentication). Wenn sie geschützt ist, muss sie auch nicht gelöscht werden, wenn der Bedarf befriedigt wurde.

      LLAP 🖖

      --
      „Wer durch Wissen und Erfahrung der Klügere ist, der sollte nicht nachgeben. Und nicht aufgeben.“ —Kurt Weidemann
      1. Mahlzeit,

        Für mich stellt sich das so dar: Entweder die phpinfo ist unbedenklich; dann braucht sie keinen Schutz. Oder die phpinfo sollte niemals für Unbefugte sichtbar sein; dann braucht sich auch in dem Moment einen Schutz (zumindest Basic Authentication). Wenn sie geschützt ist, muss sie auch nicht gelöscht werden, wenn der Bedarf befriedigt wurde.

        Ich sehe das so: Wenn phpinfo() Auskunft über Pakete gibt, die evtl. veraltet/fehlerbehaftet sind, hat der Serveradmin ganz andere Probleme als eine Datei, die die phpinfo() ausgibt 😉

        --
        42
        1. Mahlzeit,

          Ich sehe das so: Wenn phpinfo() Auskunft über Pakete gibt, die evtl. veraltet/fehlerbehaftet sind, hat der Serveradmin ganz andere Probleme als eine Datei, die die phpinfo() ausgibt 😉

          Man kann das auch so formulieren: Wenn phpinfo() über verfügbare Sicherheitslücken informiert ist das doch ein nettes Feature.

          MfG

          1. Mahlzeit,

            Man kann das auch so formulieren: Wenn phpinfo() über verfügbare Sicherheitslücken informiert ist das doch ein nettes Feature.

            Aus Sicht eines Hackers ist es das bestimmt :D

            --
            42
      2. Tach!

        Löschen, wenn der Bedarf befriedigt wurde, sich die Daten anzuzeigen.

        Und was ist vorher? Da ist die phpinfo für jeden sichtbar, der gerade in dem Moment vorbeischaut?

        Vorher ist sie gar nicht da, solange niemand eine entsprechende Datei anlegt.

        Ich vermute, es ist hier so, dass der Dienstleister von jeannie61 eine solche Datei angelegt hat und sie sie nun entdeckt hat.

        Für mich stellt sich das so dar: Entweder die phpinfo ist unbedenklich; dann braucht sie keinen Schutz. Oder die phpinfo sollte niemals für Unbefugte sichtbar sein; dann braucht sich auch in dem Moment einen Schutz (zumindest Basic Authentication).

        Die Ausgabe der Funktion selbst ist sicherlich ungefährlich, aber sie offenbart eine Menge Informationen, die man ja nicht unbedingt auf dem Präsentierteller anbieten muss, beispielsweise Pfadangaben und welche Extensions in welchen Versionen vorhanden sind. Daraus lassen sich durchaus mögliche Angriffe leichter planen.

        Ist die Datei nicht vorhanden, schließt das keine Lücken, aber man hat es nun schwerer, diese zu finden, und fällt damit vielleicht eher auf, wenn man alles durchprobieren muss.

        Wenn sie geschützt ist, muss sie auch nicht gelöscht werden, wenn der Bedarf befriedigt wurde.

        Man braucht sie üblicherweise nicht ständig, und eine Datei mit dem Funktionsaufruf drin ist bei Bedarf sehr schnell angelegt. Deswegen kann sie ganz weg, und man muss nicht noch extra dafür sorgen, einen funktionierenden Schutz davorzubauen.

        dedlfix.

        1. @@dedlfix

          Löschen, wenn der Bedarf befriedigt wurde, sich die Daten anzuzeigen.

          Und was ist vorher? Da ist die phpinfo für jeden sichtbar, der gerade in dem Moment vorbeischaut?

          Vorher ist sie gar nicht da, solange niemand eine entsprechende Datei anlegt.

          Mit „vorher“ meinte ich „bevor der Bedarf befriedigt wurde“, also die Zeit zwischen Anlegen der Datei und Löschen derselben. In dieser (kurzen) Zeitspanne dann security by obscurity?

          Man braucht sie üblicherweise nicht ständig, und eine Datei mit dem Funktionsaufruf drin ist bei Bedarf sehr schnell angelegt. Deswegen kann sie ganz weg, und man muss nicht noch extra dafür sorgen, einen funktionierenden Schutz davorzubauen.

          Wenn man einen funktionierenden Schutz davorgebaut hat, muss man nicht den Aufwand betreiben, die Datei bei erneutem Bedarf wieder neu zu erstellen.

          LLAP 🖖

          --
          „Wer durch Wissen und Erfahrung der Klügere ist, der sollte nicht nachgeben. Und nicht aufgeben.“ —Kurt Weidemann
          1. Tach!

            Mit „vorher“ meinte ich „bevor der Bedarf befriedigt wurde“, also die Zeit zwischen Anlegen der Datei und Löschen derselben. In dieser (kurzen) Zeitspanne dann security by obscurity?

            Ja, kann man machen. Das Risiko verringert sich, wenn men einen unüblichen Dateinamen nimmt. Ob phpinfo.php existiert, wird beispielswiese recht häufig probiert.

            Man braucht sie üblicherweise nicht ständig, und eine Datei mit dem Funktionsaufruf drin ist bei Bedarf sehr schnell angelegt. Deswegen kann sie ganz weg, und man muss nicht noch extra dafür sorgen, einen funktionierenden Schutz davorzubauen.

            Wenn man einen funktionierenden Schutz davorgebaut hat, muss man nicht den Aufwand betreiben, die Datei bei erneutem Bedarf wieder neu zu erstellen.

            Durchaus. Kommt darauf an, was man selbst für Aufwand inverstieren möchte. Ein dauerhafter Schutz bedeutet ja auch, dass man eine Zugangskennung mehr verwalten muss.

            dedlfix.

        2. Tach!

          Ich vermute, es ist hier so, dass der Dienstleister von jeannie61 eine solche Datei angelegt hat und sie sie nun entdeckt hat.

          Das wäre die einzig mögliche, logische und sinnvolle Erklärung.

          MfG

  3. @@jeannie61

    An der Stelle mal ganz dumm nachgefragt: Was kann so alles passieren, wenn man phpinfo für alle sichtbar macht?

    Antworten ausnahmsweise hier gern auf Englisch. Ich würde das aus aktuellem Anlass gleich mal weiterleiten.

    LLAP 🖖

    --
    „Wer durch Wissen und Erfahrung der Klügere ist, der sollte nicht nachgeben. Und nicht aufgeben.“ —Kurt Weidemann
    1. Tach!

      An der Stelle mal ganz dumm nachgefragt: Was kann so alles passieren, wenn man phpinfo für alle sichtbar macht?

      Auf direktem Wege kann nicht viel passieren, wenn nicht gerade PHP oder eine der Extensions eine Lücke eingebaut haben. Es ist aber auf alle Fälle ein Information Disclosure, das es Angreifern einfacher macht, die passenden Exploits zu finden. Betonung liegt auf "einfacher", denn man kann die Exploits auch einfach so durchprobieren. Abgesehen davon gibt es auch noch andere Details, anhand derer man das System erkennen kann, beispielsweise das Antwortverhalten auf bestimmte Netzwerkrequests.

      dedlfix.

      1. Alles richtig. Einfach löschen und bei Bedarf neu erstellen.

    2. @LLAP

      My webchecker at 1 und 1 shows me a warning because of it and tells me I have to rectify it 😉, so I would like to know if it is really all that important.

      1. Tach!

        My webchecker at 1 und 1 shows me a warning because of it and tells me I have to rectify it 😉, so I would like to know if it is really all that important.

        Die ist überhaupt nicht wichtig oder notwendig. Sie dient nur zum Informieren des Administrators und kann problemlos gelöscht werden, wenn du fertig bist mit Nachschauen. Ebenso einfach kann sie wieder erstellt werden, wenn ein weiteres Informationsbedürfnis auftaucht.

        dedlfix.

        1. Ah Okay, vielen lieben Dank dafür 😀