Simon P.: Sicherheit von PHP-scripts auf Web-Server

Hallo liebe SELFHTML Gemeinde,

momentan befasse ich mich ein wenig mit der Sicherheit von PHP-Scripten und deren Inhalten. Folgendes Szenario hat mich darauf aufmerksam gemacht:

Ich möchte Daten per PHP-Script und HTML-Formular in meine Datenbank eintragen (nichts sensibles). Da ich das nicht immer erst auf meinem Rechner machen möchte (über XAMPP), dann die SQL Tabelle exportieren und dann auf meinem Web-Server (1und1) hochladen möchte, dachte ich mir, ich könnte das auch mit einem Session-basierten Login machen, wo nur ich auf die Seite mit dem entsprechenden Formular zum eintragen der Daten komme.

Meine Frage:
Wie sicher sind Passwörter in einem PHP-Script, wenn man sie im Klartext dort einschreibt. Zum einem wenn man z.B. einen "Login" für seine MYSQL Datenbank schreibt, zum anderen, für den Sessionbasierten Login, da ja nur ein Benutzername und ein Passwort ausreicht.
Kann man PHP-Scripte auslesen oder geht das garnicht!! außer, wenn man das Passwort des Server knackt?

Ich bedanke mich schon für jede Antwort im voraus!

Weiterhin viel Erfolg euch,
Simon P.

  1. Wie sicher sind Passwörter in einem PHP-Script, wenn man sie im Klartext dort einschreibt.

    Die Skripte sind nur für Nutzer, die auf dem Server angemeldet sind, lesbar, d.h. nicht für Wildfremde über den Webserver.

    Beim Hosting ist es nun allerdings so, dass mehrere Nutzer (Kunden) auf demselben Server eingetragen sind. Abhängig davon, wie der Server konfiguriert ist, kann es möglich sein, dass alle Kunden auf Dateien aller anderen Kunden zugreifen können.

    Ob das nun bei dir möglich ist, musst du selbst herausfinden. Schreibe dir ein Skript, das ausgehend von deinem Basisverzeichnis die nächsthöheren aufführt. Von dort aus kannst du dich zu weiteren Daten durchhangeln - oder auch nicht.
    Du kannst auch versuchen, /etc/passwd auszulesen, dort findest du die Basisverzeichnisse aller eingetragenen Nutzer des Systems.

    Probiere sowohl ein PHP- als auch ein Skript für die Shell aus, beide können getrennte Sicherheitseinstellungen haben.

    1. Liebe Wissende und Unwissende,

      Beim Hosting ist es nun allerdings so, dass mehrere Nutzer (Kunden) auf demselben Server eingetragen sind. Abhängig davon, wie der Server konfiguriert ist, kann es möglich sein, dass alle Kunden auf Dateien aller anderen Kunden zugreifen können.

      Der Simon P. schrieb doch, dass er bei 1&1 hostet. Bei denen sind die Accounts schon seit Jahren gut gegeneinander abgesichert, zumal sie bei den einfachen Hostig-Paketen grundsätzlich CGI bzw. FastCGI benutzten. Da hat jeder PHP-Verwender seine eigenen Prozesse mit eigenem Jail. Da kommt er auch nicht raus.

      Bedenklicher finde ich auch den Übertragungsweg. Wenn man dir Übertragung per HTTP vornimmt, sind die Passworte, Cookies und/oder AuthTokens unterwegs schließlich überall lesbar. Wenn sich da mal ein paar Pakete an einer (illegalen) Abzweigung verirren, kann schon mal alles offen liegen.

      Scripte müssen sicher sein gegen Injektionen und Upload-Lücken. Dann sollte es kein Problem sein.
      Man sollte nur die notwendigen Dateirechte vergeben, auch mal schauen, ob nicht aus Versehen ein X-Hack-Bit gesetzt ist.

      Grüße
      Robert

      1. Bedenklicher finde ich auch den Übertragungsweg. Wenn man dir Übertragung per HTTP vornimmt, sind die Passworte, Cookies und/oder AuthTokens unterwegs schließlich überall lesbar. Wenn sich da mal ein paar Pakete an einer (illegalen) Abzweigung verirren, kann schon mal alles offen liegen.

        Scripte müssen sicher sein gegen Injektionen und Upload-Lücken. Dann sollte es kein Problem sein.
        Man sollte nur die notwendigen Dateirechte vergeben, auch mal schauen, ob nicht aus Versehen ein X-Hack-Bit gesetzt ist.

        Grüße
        Robert

        Danke für deine Antwort. Leider bin ich nicht gerade der Crack in Sachen Server-Technik, aber ich würde mich gerne zu diesem Thema einlesen, falls du Links parat hast. Ansonsten würde ich nur fragen wollen, wie ich z.B. für meinen MySql "Login" meine Passwörter bzw. Einlogdaten in das PHP-Script unterbringen soll. Momentan sind diese nämlich in Klarschrift (sagt man das so?) in dem Script lesbar.

        Was denkt der Simon sich jetzt? (<- zum Verständnis für dich)
        Ich denke nun, wenn ich die Passwörter verschlüsselt in das Script eingebe z.B. per md5, dann muss ich diese ja auch vor dem Versenden an den Server ja wieder entschlüsseln, also gelangen die Daten wieder unverschlüsselt ins Netz.
        Hab ich da einen Denkfehler?
        Vielleicht für mich zum Verständnis nocheinmal:: Die Scripte liegen ja auf dem Server. Sende ich nun eine Anfrage über meinen Browser auf dieses Script gelangt dann eigentlich überhaupt was von dem Script nach außen ins Netz oder nur das was das Script zurück an den Browser sendet.
        In diesem Fall... :: ...Gibt es kein Problem für den MySql "Login". Sondern nur für Daten die per HTML-Formular an ein PHP-Script gesendet werden. Wie kann ich dann aber "in HTML" verschlüsseln, damit 0 Daten unverschlüsselt ins Netz gelangen?

        Puh, ich hoffe ich mach nicht zu viele Umstände, aber wäre echt toll. Im Prinzip möchte ich nur eine Möglichkeit haben, dass nur ich auf eine bestimmte Seite meiner Website gelange, damit nur ich von dort aus Eintragungen in meine Datenbank vornehmen kann.

        Vielleicht ja jemand eine Idee,

        Liebe Grüße,
        Simon P.

        PS: Meine Seite ist mit einem Template-System aufgebaut.

        1. Tach!

          Danke für deine Antwort. Leider bin ich nicht gerade der Crack in Sachen Server-Technik, aber ich würde mich gerne zu diesem Thema einlesen, falls du Links parat hast.

          Datei-Berechtigungssystem unter Unix-Systemen wäre die Anlaufstelle.

          Ansonsten würde ich nur fragen wollen, wie ich z.B. für meinen MySql "Login" meine Passwörter bzw. Einlogdaten in das PHP-Script unterbringen soll. Momentan sind diese nämlich in Klarschrift (sagt man das so?) in dem Script lesbar.

          Anders gehts auch nicht. Du brauchst die Passwörter im Klartext. Sie verschlüsselt abzulegen bedeutet, dass das Script an den Schlüssel herankommen muss, und das kann dann auch jeder andere, der bei dir Dateien lesen kann. Die einzige Möglichkeit ist, die Rechte so restriktiv wie möglich zu vergeben. Der Account, unter dem deine Scripts ausgeführt werden, muss die Dateien lesen können, alle anderen nicht.

          Ich denke nun, wenn ich die Passwörter verschlüsselt in das Script eingebe z.B. per md5, dann muss ich diese ja auch vor dem Versenden an den Server ja wieder entschlüsseln, also gelangen die Daten wieder unverschlüsselt ins Netz.

          MD5 ist keine Verschlüsslung sondern ein Hash-Verfahren. Diese sind nicht umkehrbar (aber mit Brute-Force und Rainbow-Tabellen angreifbar).

          Vielleicht für mich zum Verständnis nocheinmal:: Die Scripte liegen ja auf dem Server. Sende ich nun eine Anfrage über meinen Browser auf dieses Script gelangt dann eigentlich überhaupt was von dem Script nach außen ins Netz oder nur das was das Script zurück an den Browser sendet.

          Nur die Antwort. Oder der Inhalt des Scripts bei einer Fehlkonfiguration des Servers. Etwas mehr Sicherheit ist gegeben, wenn du das Script außerhalb des DocumentRoot ablegst. Üblicherwiese bekommst du bei 1&1 eine Inklusiv-Domain s-und-ziffernfolge.irgendwas und deine Domains. Alle zeigen erst einmal in die Wurzel deines Kundenverzeichnisses, womit dann alles im Web erreichbar ist. Lediglich Zugriffsverbote in .htaccess-Dateien sind vorhanden, so man sie nicht löscht. Wenn du für all diese (inklusive der s-domain) ein Unterverzeichnis erstellst, ist nun deine Kundenverzeichniswurzel nicht mehr übers Web erreichbar. Damit hast du nun einen Platz, der auch ohne .htaccess-Verbot nicht übers Web abfragbar ist. Scripts können weiterhin darauf zugreifen, die hangeln sich übers Dateisystem mit .. dorthin.

          In diesem Fall... :: ...Gibt es kein Problem für den MySql "Login". Sondern nur für Daten die per HTML-Formular an ein PHP-Script gesendet werden. Wie kann ich dann aber "in HTML" verschlüsseln, damit 0 Daten unverschlüsselt ins Netz gelangen?

          Mit HTTPS. Das braucht ein von einem der vielen Zertifikatshändler ausgestelltes Zertifikat, damit die Browser nicht jammern. Das ist üblicherweise zusätzlich zu erwerben. Vielleicht ist auch ein in deinem Paket inklusive.

          Puh, ich hoffe ich mach nicht zu viele Umstände, aber wäre echt toll. Im Prinzip möchte ich nur eine Möglichkeit haben, dass nur ich auf eine bestimmte Seite meiner Website gelange, damit nur ich von dort aus Eintragungen in meine Datenbank vornehmen kann.

          Dafür reicht eigentlich auch schon HTTPS mit einem selbstsignierten Zertifikat, das du deinem Browser als vertrauenswürdig bekanntgibst. Ob du ein solches bei 1&1 installieren kannst, weiß ich aber nicht.

          dedlfix.

          1. Nur die Antwort. Oder der Inhalt des Scripts bei einer Fehlkonfiguration des Servers. Etwas mehr Sicherheit ist gegeben, wenn du das Script außerhalb des DocumentRoot ablegst. Üblicherwiese bekommst du bei 1&1 eine Inklusiv-Domain s-und-ziffernfolge.irgendwas und deine Domains. Alle zeigen erst einmal in die Wurzel deines Kundenverzeichnisses, womit dann alles im Web erreichbar ist. Lediglich Zugriffsverbote in .htaccess-Dateien sind vorhanden, so man sie nicht löscht. Wenn du für all diese (inklusive der s-domain) ein Unterverzeichnis erstellst, ist nun deine Kundenverzeichniswurzel nicht mehr übers Web erreichbar. Damit hast du nun einen Platz, der auch ohne .htaccess-Verbot nicht übers Web abfragbar ist. Scripts können weiterhin darauf zugreifen, die hangeln sich übers Dateisystem mit .. dorthin.

            dedlfix.

            Vielen Dank für die ausführliche Antwort.
            Leider konnte ich diesen Inhalt nicht wirklich auf mein Problem übertragen.

            Anders gesagt->
            Ich möchte ja nur auf eine einzige HTML Seite zugreifen.
            Könnte ich nicht einfach, eine HTML Seite (Login.html z.B.) erstellen, wo ich Passwort und Name eintrage. Diese Daten werden dann an mein PHP Script weitergeleitet. Sollten die Daten stimmen, spuckt mein Script die HTML-Seite, mit der ich meine Daten in meine Datenbank eintragen kann, aus. Sollten die Daten nicht stimmen, wird man halt mit einer Benachrichtigung o.ä. konfrontiert.
            Ist so eine Vorgehensweise sicher?
            Dadurch, dass man ja das Passwort und den Namen im PHP Script gespeichert hat, kann man ja nur mit der "ausprobier-Methode" das Passwort und den Namen knacken oder nicht? Wenn man es schwieriger machen möchte, könnte man noch andere Variablen hinzufügen.
            Oder hab ich da einen Denkfehler?

            Liebe Grüße,
            Simon P.

            1. Tach!

              Ich möchte ja nur auf eine einzige HTML Seite zugreifen.
              Könnte ich nicht einfach, eine HTML Seite (Login.html z.B.) erstellen, wo ich Passwort und Name eintrage.

              Dann kannst du auch HTTP Authentication verwenden. In desem Fall und beim Formular gehen die Zugangsdaten im Klartext über die Leitung. Das mag man verschmerzen können. Um Leitunghorchen zu können, muss man einer von den "Guten" sein. Den "Bösen" ist das zu aufwendig, die hacken lieber Server.

              Diese Daten werden dann an mein PHP Script weitergeleitet. Sollten die Daten stimmen, spuckt mein Script die HTML-Seite, mit der ich meine Daten in meine Datenbank eintragen kann, aus.
              Ist so eine Vorgehensweise sicher?

              Wogegen? Sicherheit ist kein Absolutwert. Man muss diese gegenüber bestimmten Szenarien betrachten. Wenn du die Tür ins Schloss fallen lässt, ist dein Zimmer sicher - gegenüber hereinfliegenden Vögeln, aber nicht gegenüber Wesen, die die Klinke herunterzudrücken vermögen.

              Das Script mit einer Passwortabfrage zu versehen ist ein Schutz gegen Zugriffe auf den restlichen Code. PHP-Code wird üblicherweise vom Webserver ausgeführt und nur die Ausgaben gelangen an die Clients. Passwörter im Code bleiben normalerweise verborgen - solange das PHP ausgeführt wird, statt dass es der Webserver als Plaintext ausliefert.

              Dadurch, dass man ja das Passwort und den Namen im PHP Script gespeichert hat, kann man ja nur mit der "ausprobier-Methode" das Passwort und den Namen knacken oder nicht?

              Na, wenn dir das so reicht? Im Prinzip funktionieren aber alle zugangsgeschützten Bereiche auf diese Art und Weise.

              dedlfix.

              1. Hallo!

                Vielen Dank für deine Antwort!

                Na, wenn dir das so reicht? Im Prinzip funktionieren aber alle zugangsgeschützten Bereiche auf diese Art und Weise.

                dedlfix.

                Genau das ist was ich im prinzip frage. Kann ein idiot, der nur Unfug treiben möchte sowas relativ simpel knacken oder muss man dazu schon auf den Server zugreifen können? Denn Jemand der Böses treiben möchte, treibt böses. Es sind keine sensiblen Daten, die Frage ist nur, ob der Otto-normal / idiot-Verbraucher sowas simpel knacken kann, ohne zugriff auf den Server. Ob es da eine Quelltext-seitige Lücke gibt o.ä.. Aber das hast du ja schon beantwortet, also kann ich die Methode mit PHP getrost so machen.
                Natürlich habe ich schon selber viele solcher Seiten gesehen, die so vorgehen, nur ich wusste nicht, ob das einfach nur mist ist oder nur nicht so sicher wie andere Methoden.

                Vielen Dank dir!

                Liebe Grüße,
                Simon P.

                1. Tach!

                  Kann ein idiot, der nur Unfug treiben möchte sowas relativ simpel knacken oder muss man dazu schon auf den Server zugreifen können?

                  Ob HTTP Authentication oder Passwrt-Formular, das nimmt sich beides nicht viel. Es kommt auf die Güte deines Passworts an. Wenn du das sicherste Passwort der Welt nimmst, kann du beruhigt schlafen. Oder auch nicht. ;)

                  Wenn jemand bereits auf dem Server ist, kannst du nicht mehr allzuviel dagegen tun. Höchstens die Beechtigungseinschränkungen des Systems schützen da noch. Je nachdem, welchen Account der Angreifer geknackt hat und was er alles damit darf.

                  dedlfix.