Su Ling: Wie inc.Datein schützen?

Ich möcte verhindern, dass meine inc-Dateien separat aufgerufen/ausgeführt werden könnnen. Da eine der inc-Datein ein Formular enthält, das mittels POST Daten an eine eine weitere inc-Datei übergeben soll, fällt ein Speicherplatz außerhalb Root wohl aus(?) und (soweit mir bekannt), kann ich mit Post auch keine action in einem gesperrten Ornder aufrufen, oder? Vielleicht (vermutlich) bin ich aber auch gänzlich auf dem falschen Weg ... daher: Wie kann ich inc-Dateien so schützen, dass sie nur included angesprochen ausgeführt werden (können)?

  1. Leg sie im Verzeichnissystem da hin, wo der Browser nicht drauf kommt.

    1. Leg sie im Verzeichnissystem da hin, wo der Browser nicht drauf kommt.

      Und wenn das nicht geht bei Deinem Hoster (davon gibt es leider viele), ist die .htaccess-Datei Dein Freund. Damit kannst Du allerhand machen, die wirklich einfachste Lösung wäre hierbei ein einfacher Verzeichnisschutz.

    2. Leg sie im Verzeichnissystem da hin, wo der Browser nicht drauf kommt.

      Wenn ich das mache, dann komme ich zwar mit php noch an die seiten dran (include funktioniert), aber ich kann mittels formular bzw. post dorthin keine action ausführen :-( ...

      1. Mahlzeit Su Ling,

        Wenn ich das mache, dann komme ich zwar mit php noch an die seiten dran (include funktioniert), aber ich kann mittels formular bzw. post dorthin keine action ausführen :-( ...

        Wenn es sich um Dateien handelt, die Du lediglich in anderen einbinden willst, wäre das auch ziemlich widersinnig ... findest Du nicht?

        MfG,
        EKKi

        --
        sh:( fo:| ch:? rl:( br:> n4:~ ie:% mo:} va:) de:] zu:) fl:{ ss:) ls:& js:|
        1. Wenn es sich um Dateien handelt, die Du lediglich in anderen einbinden willst, wäre das auch ziemlich widersinnig ... findest Du nicht?

          Zugegeben, ja! ;-)

          *Ich hatte gehofft, die zum Formular gehörige Verarbeitungs-php ebenso in dem Ordner abzulegen, so dass die zusammengehörige Dateien in einem Ordner bleiben - aber das ist wohl so nicht möglich :-(

          Danke für Deine Antwort/en!

          1. *Ich hatte gehofft, die zum Formular gehörige Verarbeitungs-php ebenso in dem Ordner abzulegen, so dass die zusammengehörige Dateien in einem Ordner bleiben - aber das ist wohl so nicht möglich :-(

            Doch, indem Du die Verarbeitungs-php im gegebenen Fall ebenfalls includierst.

            if (es gibt was zu verarbeiten) {
              include Verarbeitungs-php
            } else {
              include Formular-php
            }

          2. Mahlzeit Su Ling,

            *Ich hatte gehofft, die zum Formular gehörige Verarbeitungs-php ebenso in dem Ordner abzulegen, so dass die zusammengehörige Dateien in einem Ordner bleiben - aber das ist wohl so nicht möglich :-(

            Doch ... :-)

            Wie sinnvoll das ist, sei dahingestellt. Was spricht gegen eine Verzeichnisstruktur wie z.B.:

            /var/www/htdocs                          - DOCUMENT_ROOT
            /var/www/htdocs/foo/bar/blubb.php        - irgendeine durch HTTP erreichbare Datei

            /var/www/include                         - Verzeichnis für Includes, *nicht* durch HTTP erreichbar
            /var/www/include/foo/bar/blubb_bla.php   \ Zwei Include-Dateien, die innerhalb der durch
            /var/www/include/foo/bar/blubb_fasel.php / HTTP erreichbaren Datei benötigt werden

            Ich persönlich halte es für sinnvoller und sicherer, Dateien, die definitiv niemals direkt per HTTP abrufbar sein sollen, auch niemals innerhalb bzw. unterhalb des DOCUMENT_ROOT abzulegen (und nachträglich die Türen zu verrammeln), sondern parallel dazu. Wenn man Pech hat, reicht sonst nämlich eine kleine Verkonfigurierung des Webservers und schon ist alles erreichbar, was nie erreichbar sein sollte ...

            MfG,
            EKKi

            --
            sh:( fo:| ch:? rl:( br:> n4:~ ie:% mo:} va:) de:] zu:) fl:{ ss:) ls:& js:|
  2. Hallo,

    .ht_meine.inc.datei.php

    Gruß

    jobo

    1. .ht_meine.inc.datei.php

      Das macht die Datei/en unsichbar, schützt aber nicht davor, dass sie jemand aufrufen/ansprechen kann :-( ...

      1. Mahlzeit Su Ling,

        .ht_meine.inc.datei.php

        Das macht die Datei/en unsichbar, schützt aber nicht davor, dass sie jemand aufrufen/ansprechen kann :-( ...

        Falsch. Normalerweise (natürlich ist das auch änderbar) werden Dateien, deren Namen mit ".ht" beginnt, vom Apache *nicht* ausgeliefert.

        MfG,
        EKKi

        --
        sh:( fo:| ch:? rl:( br:> n4:~ ie:% mo:} va:) de:] zu:) fl:{ ss:) ls:& js:|
        1. Hallo,

          Falsch. Normalerweise (natürlich ist das auch änderbar) werden Dateien, deren Namen mit ".ht" beginnt, vom Apache *nicht* ausgeliefert.

          (;-). Genau, der Trick ist mir erst vor kurzem aufgefallen. Vielleicht nicht ganz so hübsch, aber erstmal effektiv.

          Gruß

          jobo

    2. Tach,

      .ht_meine.inc.datei.php

      das ist eine schlechte Lösung, da sie sich darauf verläßt, dass ein Apache in der gegenwärtigen Standardkonfiguration verwendet wird. Ein eventuell sicherheitsrelevantes (z.B. wegen Paßwörtern im Include) Feature, sollte sich nicht auf solche Annahmen stützen.

      mfg
      Woodfighter

      1. Hallo,

        .ht_meine.inc.datei.php

        das ist eine schlechte Lösung, da sie sich darauf verläßt, dass ein Apache in der gegenwärtigen Standardkonfiguration verwendet wird. Ein eventuell sicherheitsrelevantes (z.B. wegen Paßwörtern im Include) Feature, sollte sich nicht auf solche Annahmen stützen.

        Da hast du wohl recht. Aber wenn die Beschränkung für .ht* aufgehoben wird, würden ggf. auch .htaccess und .htpasswd angezeigt. Es hängt ja auch am Provider bzw. daran, wie sehr man selbst Zugriff auf die Konfiguration hat. Nicht zu vergessen, dass .htasdfasdfasdfasdfasdfasdfasdf.php auch nicht so leicht zu finden ist, wenn ich das nicht mal als Link irgendwo via google.mail schicke oder in einem browser mit google-toolbar eingebe.

        Gruß

        jobo

        1. Mahlzeit jobo,

          Nicht zu vergessen, dass .htasdfasdfasdfasdfasdfasdfasdf.php auch nicht so leicht zu finden ist, wenn ich das nicht mal als Link irgendwo via google.mail schicke oder in einem browser mit google-toolbar eingebe.

          "Security by obscurity" ist *NIEMALS* eine sinnvolle Lösung!

          MfG,
          EKKi

          --
          sh:( fo:| ch:? rl:( br:> n4:~ ie:% mo:} va:) de:] zu:) fl:{ ss:) ls:& js:|
          1. Hallo,

            Nicht zu vergessen, dass .htasdfasdfasdfasdfasdfasdfasdf.php auch nicht so leicht zu finden ist, wenn ich das nicht mal als Link irgendwo via google.mail schicke oder in einem browser mit google-toolbar eingebe.

            "Security by obscurity" ist *NIEMALS* eine sinnvolle Lösung!

            Naja, so obskur ist das ja nicht. Ein login ist ja auch nur eine auseinandergenommene Zeichenkette. D.h. du frägst den Server mit einer möglichst nicht allzuleicht zu erzeugenden Zeichenkette ab. Ich rede jetzt nicht von https.

            Gruß

            jobo

  3. Mahlzeit Su Ling,

    Ich möcte verhindern, dass meine inc-Dateien separat aufgerufen/ausgeführt werden könnnen.

    Definiere "inc-Dateien"! Was verstehst Du darunter? Dateien, die nicht direkt per HTTP abgerufen werden können (sollen)? Also Dateien, die in Skript-Dateien, die direkt per HTTP abgerufen werden, eingebunden werden?

    Da eine der inc-Datein ein Formular enthält, das mittels POST Daten an eine eine weitere inc-Datei übergeben soll,

    Gesetzt den Fall, dass meine o.g. Annahme richtig ist, kann dieser Fall *niemals* vorkommen.

    (soweit mir bekannt), kann ich mit Post auch keine action in einem gesperrten Ornder aufrufen, oder?

    Was verstehst Du unter einem "gesperrten Ordner"? Wenn Du damit meinst, dass HTTP-Zugriffe (von außerhalb) auf diesen Ordner vom Webserver unterbunden werden, dann liegst Du richtig: dann kannst Du natürlich nicht mittels POST etwas an ein darin liegendes Skript schicken.

    Vielleicht (vermutlich) bin ich aber auch gänzlich auf dem falschen Weg ...

    Vielleicht. Das ist aber schwer zu sagen, da Du einfach viel zu viele Fragen offen lässt. Fangen wir doch einfach mal damit an, dass Du uns verraten könntest, welchen Webserver und welche serverseitige Skriptsprache Du benutzt. Dann könntest Du beschreiben, was für Dich eine "inc-Datei" ist und - falls ich richtig geraten habe - wie diese eingebunden werden.

    daher: Wie kann ich inc-Dateien so schützen, dass sie nur included angesprochen ausgeführt werden (können)?

    Indem Du sie außerhalb des DOCUMENT_ROOT aufbewahrst. Sofern der Webserver Leserechte in diesem Verzeichnis hat, können sie ohne Probleme von dort in Deine eigentlichen Skripte eingebunden werden.

    MfG,
    EKKi

    --
    sh:( fo:| ch:? rl:( br:> n4:~ ie:% mo:} va:) de:] zu:) fl:{ ss:) ls:& js:|
    1. Mahlzeit Su Ling,

      Hi Ekki!

      Definiere "inc-Dateien"! Was verstehst Du darunter?

      Inc-Datein sind (in meinem Fall) php-Dateien und zwar solche, die (und darum geht es) möglichst nicht separat aufgerufen/ausgeführt werden sollen/dürfen, sondern mittel php-include in eine andere php-datei importiert und nur dort ausgeführt werden sollen.

      inc = include-dateien.

      Was verstehst Du unter einem "gesperrten Ordner"?

      An einen mittels .htaccess gesperrten (also nicht öffentlich zugänglichen) Ornder.

      Fangen wir doch einfach mal damit an, dass Du uns verraten könntest, welchen Webserver und welche serverseitige Skriptsprache Du benutzt.

      Apache, PHP ...

      1. Inc-Datein sind (in meinem Fall) php-Dateien und zwar solche, die (und darum geht es) möglichst nicht separat aufgerufen/ausgeführt werden sollen/dürfen, sondern mittel php-include in eine andere php-datei importiert und nur dort ausgeführt werden sollen.

        Dann mach das doch. Das steht zwar im Widerspruch dazu eine Datei doch separat aufrufen zu wollen, wie weiter untem im Therad beschrieben, aber diesen Willen zu opfern wäre das Mittel der Wahl.

        Fangen wir doch einfach mal damit an, dass Du uns verraten könntest, welchen Webserver und welche serverseitige Skriptsprache Du benutzt.

        Ich dachte es soll Dir für deinen Fall geholfen werden?!

        1. Inc-Datein sind (in meinem Fall) php-Dateien und zwar solche, die (und darum geht es) möglichst nicht separat aufgerufen/ausgeführt werden sollen/dürfen, sondern mittel php-include in eine andere php-datei importiert und nur dort ausgeführt werden sollen.

          Dann mach das doch. Das steht zwar im Widerspruch dazu eine Datei doch separat aufrufen zu wollen, wie weiter untem im Therad beschrieben, aber diesen Willen zu opfern wäre das Mittel der Wahl.

          PS.: Dann gibt es aber auch noch die Möglichkeit per .htaccess einzelne Dateien zu sperren.

  4. Hallo,

    Du könntest im einbindenen Skript eine Konstante definieren und in der inc-Datei die Existenz dieser Konstante überprüfen - wenn diese nicht definiert ist, reagiere entsprechend.

    Grüße Basti

    1. Du könntest im einbindenen Skript eine Konstante definieren und in der inc-Datei die Existenz dieser Konstante überprüfen - wenn diese nicht definiert ist, reagiere entsprechend.

      Probiere mal das Vorhandensein der Konstante mit isset() zu prüfen, das  funktioniert zwar nicht*, beschert aber eine ungewöhnliche Fehlermeldung.

      *defined() wäre richtig