Ankündigung

Einklappen
Keine Ankündigung bisher.

Config Dateien schützen

Einklappen

Neue Werbung 2019

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • Config Dateien schützen

    Hallo Zusammen,

    für meine Anwnedung wurde eine Subdomain angelegt. Im Root der Domain sind alle Dateien auch die config.php. Sie beinhaltet Informationen um eine Verbindung zu einem REST-Server aufzubauen. Sie enthält die base_URL, Username und Passwort für den REST-Server. Das Passwort habe ich mittels password_hash verschlüsselt. Wie kann ich sicherstellen das die config.php nur von meiner Anwendung gelesen werden kann? Wenn jemand die config.php öffnet, kann er mit den Angaben den REST-Server ansprechen. Das Passwort ist zwar verschlüsselt aber der REST-Server würde das verschlüsselte Passwort akzeptieren.

    Bei einigen Webseiten ist mir eine bestimmte Struktur aufgefallen:
    /database
    /config
    /js
    /media
    /vendor
    /dublic/index.html

    Die index.html und weitere Dateien waren in /dublic abgelegt. Alle andere Dateien eine Ebene höher.
    Ich habe das ausprobiert, also meine SubDomain zeigt nicht auf die Root sondern auf /dublic. Leider konnte meine Anwendung dann nicht auf die ../config/config.php zugreifen.

    Hat mir jemand bitte einen Hinweis wie ich bestimmte Dateien wie die config.php schützen kann?




  • #2
    üblicherweise heißt dieser Ordner "public", weil er den öffentlich erreichbaren Teil der Anwendung darstellt.

    Leider konnte meine Anwendung dann nicht auf die ../config/config.php zugreifen.
    Den Teil solltest du ausführen, du kannst Dateien außerhalb des document roots genauso wie jede andere mit include oder require einbinden.

    Anbei noch: Der Ordner "js" (javascript) außerhalb des document root ergibt nur dann Sinn, wenn du die enthaltenen Dateien in einer einzelnen Datei zusammenbindest und diese dann im öffentlichen Teil der Anwendung aufbewahrst.

    Kommentar


    • #3
      Hallo und danke für die Infos.

      dublic ist natürlich ein Tippfehler, public war gemeint. Wenn ich dich richtig verstanden habe, alles was nicht besonders geschützt werden soll, darf ab /public angelegt werden. Dokumente die geschützt werden sollen wie in dem Beispiel /database, /config, /vendor sind außerhalb von /public. Wie müssen bitte die Zugriffsrechte gesetzt sein für /public und für die Verzeichnisse darüber damit nur die Anwendung darauf zugreifen kann? Mit Anwendung meine ich einfach mein Projekt und dessen .php, .html, .js und weiterer Dateien die zum Projekt gehören.

      Ich frage mich gerade, wenn die config.php über include ../config/config.php erreichbar ist, ist sie dann auch wirklich nicht von "außen" erreichbar? Oder hat das was mit den Zugriffsrechten auf Systemebenen die man entsprechend setzen muss zu tun? Sorry, ich frage weil ich es einfach nicht besser weis. Wie man Projekt-Strukturen anlegt und wie sie geschützt werden steht sicherlich irgendwo. Nach was müsste ich bitte suchen?

      Kommentar


      • #4
        Wenn ich dich richtig verstanden habe, alles was nicht besonders geschützt werden soll, darf ab /public angelegt werden. Dokumente die geschützt werden sollen wie in dem Beispiel /database, /config, /vendor sind außerhalb von /public.
        Das stimmt so nicht ganz, geht aber in die richtige Richtung. Man verfolgt den Ansatz "im document root ist nur das, was dort zwingend sein muss", der Rest ist außerhalb. Aber insbesonder Konfigurationsdateien die z.B. Datenbankzugangsdaten oder ähnliches enthalten sollten außerhalb des document root aufbewahrt werden. Ein einfacher Grund, alles innerhalb des document roots kann per url angesprochen werden. Bei einer Verknüpfung ungünstiger Umstände kann es sonst dazu kommen, dass dein Webserver die Dateien mal "roh" als Text ausliefert.

        Was genau öffentlich sein muss hängt stark von deiner Anwendung ab. Wenn du eine Routing Komponente verwendest reicht eine einzelne index.php Datei als Einstiegspunkt in die Anwendung. Von dort werden dann die anderen Komponenten geladen.
        Ausnahme davon sind die css und js Dateien. Diese möchtest du auch ausliefern können und die Einbindung findet nicht serverseitig sondern erst beim Client statt. Wenn die Teile nicht öffentlich sind können sie nicht vom Client geladen werden.

        Ich frage mich gerade, wenn die config.php über include ../config/config.php erreichbar ist, ist sie dann auch wirklich nicht von "außen" erreichbar?
        Was meinst du damit? Php läuft am Server ab. Wenn die Antwort zum Client geschickt wird ist Php komplett fertig. Wenn du nicht gerade eval() verwendest hat der Client keine Möglichkeit deinen Php-Code zu beeinflussen.

        Du musst keine speziellen Systemrechte setzen, der Nutzer unter dem Php läuft muss Zugriff auf die Ordner haben die du benutzen möchtest, dafür musst du in der Regel nichts spezielles einstellen.

        Kommentar


        • #5
          Die gute Nachricht zuerst: Es hat funktioniert, zumindest in der Entwicklungsumgebung!


          Von "außen" erreichbar meinte ich ob jeder über seinen Browser wenn er den Pfad kennt die config.php irgend wie erreichen kann.

          So sieht meine aktuelle Struktur aus.
          2018-05-24_100528.png

          Der Ordner vendor beinhaltet auch css Elemente für bootstrap. Somit verschiebe ich auch den Ordner in public, sowie .js und .media in public.

          So sieht jetzt meine neue Struktur aus:
          2018-05-24_102844.png


          Ich habe ein paar Links anpassen müssen. Es scheint alles zu funktionieren.
          Nur PHPStorm meldet dass der GuzzleHTTP Namespace nicht gefunden wurde. Aber es funktioniert dennoch, zumindest in meiner Entwicklungsumgebung! Online habe ich es noch nicht gestellt.

          2018-05-24_103448.png



          Muss ich jetzt die subdomain umstellen so dass sie auf /public zeigt?
          Bisher hatte ich folgende URL: http://MeineDomain.de/newsletterAktivieren.html?email@AndereDomain.de
          Ohne die subdomain zu veränder würde ja jetzt die URL so aussehen: http://MeineDomain.de/public/newsletterAktivieren.html?email@AndereDomain.de


          Reicht es einfach den Pfad der subdomain auf /public zeigen zu lasen ohne die Zugriffrechte zu verändern?

          Kommentar


          • #6
            Das mit GuzzleHttp hat sich erledigt. War noch eine Einstellung in PHPStorm notwendig.

            Ich habe es mittlerweile Online gestellt und das Root Directory der subdomain auf /public ändern lassen. Das funktioniert leider nicht. In der URL ist zwar /public weg und die newsletterAktivieren.html wird gefunden, doch beim senden des Formulars sende ich es an ../newsletter.php welches jetzt nicht mehr erreichbar ist.
            HTML-Code:
            <form class="needs-validation" novalidate id="newsletterForm" action="../newsletter.php" method="post">
            Hast du eine Idee?

            Kommentar


            • #7
              Zitat von R1100 Beitrag anzeigen
              ../newsletter.php welches jetzt nicht mehr erreichbar ist. Hast du eine Idee?
              Legt die newsletter.php halt dahin wo diese erreichbar ist…

              Kommentar


              • #8
                Von "außen" erreichbar meinte ich ob jeder über seinen Browser wenn er den Pfad kennt die config.php irgend wie erreichen kann.
                Nein, das geht nicht.

                Hast du eine Idee?
                Hier möchtest du offensichtlich das genaue Gegenteil. Du verweist von "außen" auf die newsletter.php, also muss diese auch öffentlich verfügbar sein.

                Kommentar


                • #9
                  Die newsletter.php könnte ohne Probleme in public verschieben. Die config.php jedoch möchte ich schon geschützt haben.Ich dachte es macht kein Unterschied ob nur die config.php oder auch weitere files ausserhalb von public sind.

                  Die newsletter.php ist nun in /public. Um aus public eine Datei einzubinden die oberhalb liegt, verwende ich
                  HTML-Code:
                  include '../APIClient.php';
                  Ich habe auch gelesen dass besser sei
                  HTML-Code:
                  include __DIR__ . '../APIClient.php';
                  zu verwenden. Oder gibt es eine andere Methode auf Files die ausserhalb von public sind zuzugreifen?

                  Ich bin auf das ganze gekommen durch diesen Beitrag unter Punkt 7. https://php.earth/docs/security/configuration

                  Oder habe ich alles komplett missverstanden?

                  Kommentar


                  • #10
                    Dir ist offensichlich nicht klar das ein Zugriff über http oder ssl(https) etwas anderes ist als der Zugriff über das Dateisystem der Maschine.

                    Apache und andere Webserver nutzen für jeden vhost ein virtuelles Dateisystem, das es nur ermöglicht auf einen genau spezifizierten Ausschnitt im echten Dateisystem zuzugreifen. Das DOCUMENT_ROOT
                    stellt dabei das Verzeichnis dar das in der URL dem Pfad / entspricht (z.B.: https://example.com/) weiter kannst Du nicht aus der Verzeichnisstruktur rausgehen wenn Du über den Webserver kommst.

                    Mit https://example.com/../geheime-datei kommst Du nicht tiefer. DOCUMENT_ROOT ist die Grenze.

                    Für den Code in PHP-Scripten gilt diese Einschränkung natürlich nicht. Diese arbeiten auf den echten Dateisystem.
                    PHP-Manual ¡ mysql_* ist veraltet ¡ Debugging: Finde DEINE Fehler selbst ¡ Passwort-Hashing ¡ Prepared Statements

                    Kommentar


                    • #11
                      Zitat von R1100 Beitrag anzeigen
                      Ich habe auch gelesen dass besser sei
                      HTML-Code:
                      include __DIR__ . '../APIClient.php';
                      zu verwenden. Oder gibt es eine andere Methode auf Files die ausserhalb von public sind zuzugreifen?
                      Lies die auch mal den Artikel includes niemals ohne DIR durch, damit es klarer wird, was den Unterschied ausmacht.

                      Kommentar


                      • #12
                        Zitat von R1100 Beitrag anzeigen
                        Ich habe auch gelesen dass besser sei
                        HTML-Code:
                        include __DIR__ . '../APIClient.php';
                        zu verwenden.
                        Wenn Du es ausprobiert hättest wüstest Du das das so nicht funktioniert. Da fhlt noch der Verzeichnistrenner am Anfang der Zeichenkette

                        PHP-Manual ¡ mysql_* ist veraltet ¡ Debugging: Finde DEINE Fehler selbst ¡ Passwort-Hashing ¡ Prepared Statements

                        Kommentar


                        • #13
                          Schönes Bild oben R1100 , der autoloader und vendor gehören auch nicht ins public. Möglicherweise lösst das Deine Probleme.

                          Kommentar

                          Lädt...
                          X