Seite 1 von 2 12 Letzte »
Ergebnis 1 bis 20 von 22

[php] Datenbank und Login

  1. #1 Zitieren
    Sergej Petrow
    Gast
    Ich versuche mich gerade an diesem Beispiel hier:

    http://www.php-kurs.info/tutorial-lo...datenbank.html

    Komme aber irgendwie nicht weiter.

    Welche Datei muss ich aufrufen, um das ganze zu starten? Doch sicher die html-Datei?

    Ich bin soweit, dass ich den Kontakt zur Datenbank bekomme, wenn ich die php-Datei starte.

    Was aber nicht klappt, ist, wenn ich die html-Datei starte und Name und Passwort eingabe. Es passiert gar nichts weiter. Es scheint, als ob die php-Datei gar nicht aufgerufen wird.

    Hier mein Code:

    Einmal die html-Datei:

    HTML-Code:
    <!DOCTYPE html>
    <html>
    <head>
    <meta charset="ISO-8859-1">
    
    </head>
    <body>
    
    <form action="LogIn.php" method="post"> 
    
    Username:<br>
    <input type="text" size="24" maxlength="50"
    name="username"><br><br>
    
    Ihr Passwort:<br>
    <input type="password" size="24" maxlength="50"
    name="passwort"><br>
    
    <input type=submit name=submit value="Einloggen"> //das verstehe ich überhaupt nicht
    </form>
    </body>
    </html>
    Einmal die php-Datei
    PHP-Code:
    <?php
    SESSION_START
    ();
    ?>

    <?php 
        $_db_host 
    "xxxxxxx";            # kd
        
    $_db_datenbank "xxxxxxxx";
        
    $_db_username "xxxxxxxx";
        
    $_db_passwort "xxxxxxxx";

        
    # Datenbankverbindung herstellen
        
    $link mysql_connect($_db_host$_db_username$_db_passwort);

        
    # Hat die Verbindung geklappt ?
        
    if (!$link)
            {
            die(
    "Keine Datenbankverbindung möglich: " mysql_error());
            }
            
        
    # Verbindung zur richtigen Datenbank herstellen
        
    $datenbank mysql_select_db($_db_datenbank$link);

        if (!
    $datenbank)
            {
            echo 
    "Kann die Datenbank nicht benutzen: " mysql_error();
            
    mysql_close($link);        # Datenbank schliessen
            
    exit;                    # Programm beenden !
            
    }

        echo 
    "bin hier"#erreiche ich nicht, wenn ich die html-seite aufrufe
           # Ist die $_POST Variable submit nicht leer ???
           # dann wurden Logindaten eingegeben, die müssen wir überprüfen !
           
    if (!empty($_POST["submit"]))
               {
            
    # Die Werte die im Loginformular eingegeben wurden "escapen",
            # damit keine Hackangriffe über den Login erfolgen können !
            # Mysql_real... ist auf jedenfall dem Befehle addslashes()
            # vorzuziehen !!! Ohne sind mysql injections möglich !!!!
            
    $_username mysql_real_escape_string($_POST["username"]);
            
    $_passwort mysql_real_escape_string($_POST["passwort"]);
            
            
    # Befehl für die MySQL Datenbank
            # Wichtig ist, die Variablen von $_username und $_passwort
            # zu umklammern. Da wir mit Anführungszeichen den SQL String
            # angeben, nehmen wir dafür die einfachen Anführungszeichen
            # die man neben der Enter Taste auf der # findet !
            
    $_sql "SELECT * FROM login_username WHERE
            username='
    $_username' AND
            passwort='
    $_passwort' AND
            usergeloescht=0
            LIMIT 1"
    ;
            
            
    # Prüfen, ob der User in der Datenbank existiert !
            
    $_res mysql_query($_sql$link);
            
    $_anzahl = @mysql_num_rows($_res);
            
            
    # Die Anzahl der gefundenen Einträge überprüfen. Maximal
            # wird 1 Eintrag rausgefiltert (LIMIT 1). Wenn 0 Einträge
            # gefunden wurden, dann gibt es keinen Usereintrag, der
            # gültig ist. Keinen wo der Username und das Passwort stimmt
            # und user_geloescht auch gleich 0 ist !
            
    if ($_anzahl 0)
                {
                echo 
    "Der Login war erfolgreich.<br>";
            
                
    # In der Session merken, dass der User eingeloggt ist !
                
    $_SESSION["login"] = 1;
            
                
    # Den Eintrag vom User in der Session speichern !
                
    $_SESSION["user"] = mysql_fetch_array($_resMYSQL_ASSOC);
            
                
    # Das Einlogdatum in der Tabelle setzen !
                
    $_sql "UPDATE login_username SET letzterlogin=NOW()
                WHERE id="
    .$_SESSION["user"]["id"];
                
    mysql_query($_sql);
                }
            else
                {
                echo 
    "Die Logindaten sind nicht korrekt.<br>";
                }
            }
            
            
    # Ist der User eingeloggt ???
            
    if ($_SESSION["login"] == 0)
                {
            
    # ist nicht eingeloggt, also Formular anzeigen, die Datenbank
            # schliessen und das Programm beenden
                
    include("loginformular.html");
                
    mysql_close($link);
                echo 
    "<br><br> iss ja blöd<br><br>";
                exit;
                }
            
        
    # Hier wäre der User jetzt gültig angemeldet ! Hier kann
        # Programmcode stehen, den nur eingeloggte User sehen sollen !!
        
        
    echo "<br> <br>Hallo, Sie sind erfolgreich eingeloggt !<br>";
            
             
             
        
    # Datenbank wieder schliessen
        
    mysql_close($link);
    ?>
    Was mache ich falsch?

    Dann das nächste.

    In der php-Datei muss ich ja das Passwort meiner Datenbank eintragen. Das kommt mir reichlich unsicher vor. Geht das irgendwie auch anders. Oder ist es unproblematisch?

  2. #2 Zitieren
    Ehrengarde Avatar von Ewige Finsternis
    Registriert seit
    Sep 2008
    Beiträge
    2.659
    Zitat Zitat von Sergej Petrow Beitrag anzeigen
    Welche Datei muss ich aufrufen, um das ganze zu starten? Doch sicher die html-Datei?
    Wenn deine PHP-Datei die Werte braucht, die du in deiner HTML eingibst wird du nicht anders können als die HTML-Datei als erstes zu starten, ja. Wie heißt deine HTML-Datei? Grundsätzlich sollte man die Startseite index.html/index.php nennen, denn wenn du nur in ein Verzeichnis navigierst ohne eine Datei zu spezifizieren wird nach einer solchen gesucht und diese aufgerufen, falls vorhanden.

    Zitat Zitat von Sergej Petrow Beitrag anzeigen
    <input type=submit name=submit value="Einloggen"> //das verstehe ich überhaupt nicht
    Ein input vom Typ submit erstellt einen Button, in diesem Fall den Button der mit "Einloggen" beschriftet ist. Ein Klick auf diesen Button wiederum schickt dein Formular ab. Allerdings bin ich es gewohnt das man nicht

    type=submit name=submit

    sondern

    type="submit" name="submit"

    schreibt. Keine Ahnung ob das so richtig funktioniert, aber ich hab noch nie gesehen das es jemand ohne Anführungszeichen geschrieben hat.


    Zitat Zitat von Sergej Petrow Beitrag anzeigen
    Ich bin soweit, dass ich den Kontakt zur Datenbank bekomme, wenn ich die php-Datei starte.

    Was aber nicht klappt, ist, wenn ich die html-Datei starte und Name und Passwort eingabe. Es passiert gar nichts weiter. Es scheint, als ob die php-Datei gar nicht aufgerufen wird.
    Bist du sicher das Name und Pfad stimmen? Bei mir funktioniert deine HTML-Datei einwandfrei. Wenn ich auf den Button klicke werde ich auf die LogIn.php weitergeleitet. Passiert bei dir einfach komplett gar nichts?


    Zitat Zitat von Sergej Petrow Beitrag anzeigen
    In der php-Datei muss ich ja das Passwort meiner Datenbank eintragen. Das kommt mir reichlich unsicher vor. Geht das irgendwie auch anders. Oder ist es unproblematisch?
    Das kommt kommt jetzt wohl drauf an wo du es einsetzen willst. Gegenüber deinen Nutzern ist es glaube ich eher unproblematisch. Der PHP-Code wird ja direkt vom Server geparst, davon bekommt der Nutzer nichts mit. Wenn du jetzt aber deine Dateien in irgendeinem Verzeichnis liegen hast, auf das andere Leute Zugriff haben, können die natürlich die Dateien einsehen und die Passwörter rauslesen. Aber grundsätzlich müssen die Logindaten für die Datenbank ja irgendwo her kommen. D.h. entweder hast du sie irgendwo stehen, oder du gibts sie von Hand über Inputfelder ein, was zwar sicherer aber dafür aufwändiger ist.


    Ewige Finsternis ist offline Geändert von Ewige Finsternis (06.02.2015 um 22:11 Uhr)

  3. #3 Zitieren
    Sergej Petrow
    Gast
    Zitat Zitat von Ewige Finsternis Beitrag anzeigen
    Ein input vom Typ submit erstellt einen Button, in diesem Fall den Button der mit "Einloggen" beschriftet ist. Ein Klick auf diesen Button wiederum schickt dein Formular ab. Allerdings bin ich es gewohnt das man nicht

    type=submit name=submit

    sondern

    type="submit" name="submit"

    schreibt. Keine Ahnung ob das so richtig funktioniert, aber ich hab noch nie gesehen das es jemand ohne Anführungszeichen geschrieben hat.
    Das hab ich aus der Vorlage so entnommen. Aber jetzt weiß ich wenigstens schon mal, dass damit ein Button gezeigt werden soll. Das hilft schon sehr viel weiter und führt mich ...

    Zitat Zitat von Ewige Finsternis Beitrag anzeigen
    Bist du sicher das Name und Pfad stimmen? Bei mir funktioniert deine HTML-Datei einwandfrei. Wenn ich auf den Button klicke werde ich auf die LogIn.php weitergeleitet. Passiert bei dir einfach komplett gar nichts?
    ... zum Problem, dass bei mir die html-Seite kein Button anzeigt. Bei mir wird nur
    Username:
    Feld zum Eintragen

    Passwort:
    Feld zum Eintragen

    angezeigt. Kein Button sichtbar...

    Das erklärt einiges. Ich kann quasi den Startbefehl gar nicht übermitteln. Ist bei dir wirklich ein Button sichtbar?

    Zitat Zitat von Ewige Finsternis Beitrag anzeigen
    Das kommt kommt jetzt wohl drauf an wo du es einsetzen willst. Gegenüber deinen Nutzern ist es glaube ich eher unproblematisch. Der PHP-Code wird ja direkt vom Server geparst, davon bekommt der Nutzer nichts mit. Wenn du jetzt aber deine Dateien in irgendeinem Verzeichnis liegen hast, auf das andere Leute Zugriff haben, können die natürlich die Dateien einsehen und die Passwörter rauslesen. Aber grundsätzlich müssen die Logindaten für die Datenbank ja irgendwo her kommen. D.h. entweder hast du sie irgendwo stehen, oder du gibts sie von Hand über Inputfelder ein, was zwar sicherer aber dafür aufwändiger ist.
    ok, das sollte eigentlich nicht der Fall sein. Wobei:
    Ich hab mir das Powerpaket von Kabeldeutschland geholt. Da ist eine Homepage bei und alles, was dazu gehört. Hierzu hab ich ein Passwort für meinen Webspace bekommen und einen Benutzernamen. Was ich merkwürdig fand. Ich dachte, dass ich das frei wählen könnte und entsprechend auch das Passwort nach meinen Wünschen ändern könnte. Das scheint aber nicht zu gehen. Deshalb weiß ich nicht, ob der Admin im Webspace reinschauen kann. Nicht, dass es derzeit wichtig wäre, weil ich eh gerade nur am rumprobieren bin. Aber ich würde gerne Gewissheit haben, dass da kein anderer reinschauen kann.
    Geändert von Sergej Petrow (06.02.2015 um 22:31 Uhr)

  4. #4 Zitieren
    Ehrengarde Avatar von Ewige Finsternis
    Registriert seit
    Sep 2008
    Beiträge
    2.659
    Zitat Zitat von Sergej Petrow Beitrag anzeigen
    Das erklärt einiges. Ich kann quasi den Startbefehl gar nicht übermitteln. Ist bei dir wirklich ein Button sichtbar?
    Ja.

    [Bild: CzWKn1Ilogin.png]

    Hast du es mal mit <input type="submit" name="submit" value="Einloggen"> versucht? Beziehungsweise was für einen Browser verwendest du? Manche Browser bügeln einige Fehler automatisch aus und sind somit kulanter was den Code angeht, das wäre grade meine Vermutung.


    Zitat Zitat von Sergej Petrow Beitrag anzeigen
    ok, das sollte eigentlich nicht der Fall sein. Wobei:
    Ich hab mir das Powerpaket von Kabeldeutschland geholt. Da ist eine Homepage bei und alles, was dazu gehört. Hierzu hab ich ein Passwort für meinen Webspace bekommen und einen Benutzernamen. Was ich merkwürdig fand. Ich dachte, dass ich das frei wählen könnte und entsprechend auch das Passwort nach meinen Wünschen ändern könnte. Das scheint aber nicht zu gehen. Deshalb weiß ich nicht, ob der Admin im Webspace reinschauen kann. Nicht, dass es derzeit wichtig wäre, weil ich eh gerade nur am rumprobieren bin. Aber ich würde gerne Gewissheit haben, dass da kein anderer reinschauen kann.
    Dazu kann ich nicht wirklich was sagen, aber ich hätte vermutet das die Leute von Kabeldeutschland jederzeit bei dir reinkommen, wenn sie wollen. Ist wie bei Vermietern, die haben in der Regel auch einen Schlüssel für die Wohnung die sie vermieten.


    Ewige Finsternis ist offline

  5. #5 Zitieren
    Sergej Petrow
    Gast
    Zitat Zitat von Ewige Finsternis Beitrag anzeigen
    Ja.

    [Bild: CzWKn1Ilogin.png]

    Hast du es mal mit <input type="submit" name="submit" value="Einloggen"> versucht? Beziehungsweise was für einen Browser verwendest du? Manche Browser bügeln einige Fehler automatisch aus und sind somit kulanter was den Code angeht, das wäre grade meine Vermutung.
    Großartig!!!!

    Hab es mit deiner Zeile versucht. Der Button war sofort da (dann hätte ich es auch gleich verstanden. )
    Auch die Abfrage funzte mit Kontakt zur Datenbank. Vielen dank für die prompte Hilfe

    Zitat Zitat von Ewige Finsternis Beitrag anzeigen
    Dazu kann ich nicht wirklich was sagen, aber ich hätte vermutet das die Leute von Kabeldeutschland jederzeit bei dir reinkommen, wenn sie wollen. Ist wie bei Vermietern, die haben in der Regel auch einen Schlüssel für die Wohnung die sie vermieten.
    Also muss ich damit wohl leben. Ist schon ein bisserl unbefriedigend.
    Geändert von Sergej Petrow (06.02.2015 um 22:56 Uhr)

  6. #6 Zitieren
    Ehrengarde Avatar von Ewige Finsternis
    Registriert seit
    Sep 2008
    Beiträge
    2.659
    Zitat Zitat von Sergej Petrow Beitrag anzeigen
    Großartig!!!!

    Hab es mit deiner Zeile versucht. Der Button war sofort da (dann hätte ich es auch gleich verstanden. )
    Auch die Abfrage funzte mit Kontakt zur Datenbank. Vielen dank für die prompte Hilfe
    [Bild: JgK8zoidberg.png]

    Freut mich das ich dir helfen konnte.
    In dem Fall benutzt du wohl keinen Firefox, der bügelt dir den Fehler automatisch aus.

    Zitat Zitat von Sergej Petrow Beitrag anzeigen
    Also muss ich damit wohl leben. Ist schon ein bisserl unbefriedigend.
    Ja, bombensicher wird es nicht sein. Ich denke der Vergleich zwischen Mietwohnung und Eigenheim ist ganz passend. Wenns dir nicht selbst gehört, dann wirds auch immer jemand anderen geben der einen Schlüssel hat.


    Ewige Finsternis ist offline

  7. #7 Zitieren
    Sergej Petrow
    Gast
    Ich hab den ie 11.

    Es hätte mir eigentlich auffallen müssen. Schreibe die php- und html-Dateien in Eclipse und es gab vorher bei der html-Datei eine Warnung genau in der Zeile. Dummerweise konnte ich mir nicht vorstellen, dass da ein Fehler drin steckt, weil das ja in der Beispielseite, die ich oben angegeben hatte, so gemacht wurde. Man kann sich nicht mal auf Beispiele verlassen.

  8. #8 Zitieren
    Drachentöter Avatar von Vertaler
    Registriert seit
    Sep 2006
    Beiträge
    4.539
    Zitat Zitat von Sergej Petrow Beitrag anzeigen
    Man kann sich nicht mal auf Beispiele verlassen.
    Insbesondere nicht, wenn das ganze schon ein paar Jährchen alt ist. Die mysql_-Funktionen sind seit PHP 5.5 (Mitte 2013) deprecated (veraltet, überholt), man sollte stattdessen lieber auf MySQLi oder PDO zurückgreifen. Zu MySQLi ist es leichter von den alten Funktionen zu migrieren, im Prinzip kann man alle mysql_-Funktionsaufrufe durch mysqli_-Aufrufe ersetzen (das nutzt dann zwar nicht alles, was MySQLi zu bieten hat, aber für den Einstieg reicht es).
    Es entsteht immer wieder Anlass zu vorsichtiger Lebensfreude, wenn man sich vor Augen hält, was es alles nicht gibt und was es daher vielleicht auch niemals geben wird.

    [Bild: rand.php?p=xkcd&n=3] [Bild: rand.php?p=numminen&n=3] [Bild: rand.php?p=co&n=4] [Bild: rand.php?p=snark&n=3] [Bild: rand.php?p=musik&n=5]
    Vertaler ist offline

  9. #9 Zitieren
    Mythos Avatar von Pyrokar
    Registriert seit
    May 2004
    Ort
    ..... hihihähähä hier gibt es Wände und wenn ich dagegen Lauf prall ich ab, wie ein Flummi..... hihihähähääähääääää
    Beiträge
    8.115
    Zitat Zitat von Sergej Petrow Beitrag anzeigen
    In der php-Datei muss ich ja das Passwort meiner Datenbank eintragen. Das kommt mir reichlich unsicher vor. Geht das irgendwie auch anders. Oder ist es unproblematisch?
    Ich weiß nicht ob das bei deinem Webspace geht, aber üblicherweise hinterlegt man Passwörter u.ä. nicht in einem Verzeichnis, das über den Webserver erreichbar ist. In der php-Datei, die Zugang zur Datenbank braucht kann man die Datei, die die Zugangsdaten beinhaltet dann per require einbinden.

    Zitat Zitat von Ewige Finsternis Beitrag anzeigen
    oder du gibts sie von Hand über Inputfelder ein, was zwar sicherer aber dafür aufwändiger ist.
    Das kommt auf das verwendete Übertragungsprotokoll an. HTTP wird im Klartext übertragen. Sicherer wäre das nur mit SSL (lassen wir mal die Möglichkeiten von Geheimdiensten aus). Aber es wäre auch wenig benutzerfreundlich, jedes Mal das Passwort einzugeben und wenn man mal noch andere Benutzer hat nicht mehr möglich wenn nicht alle das DB-Passwort bekommen.

    Zitat Zitat von Sergej Petrow Beitrag anzeigen
    Ich hab mir das Powerpaket von Kabeldeutschland geholt. Da ist eine Homepage bei und alles, was dazu gehört. Hierzu hab ich ein Passwort für meinen Webspace bekommen und einen Benutzernamen. Was ich merkwürdig fand. Ich dachte, dass ich das frei wählen könnte und entsprechend auch das Passwort nach meinen Wünschen ändern könnte. Das scheint aber nicht zu gehen. Deshalb weiß ich nicht, ob der Admin im Webspace reinschauen kann. Nicht, dass es derzeit wichtig wäre, weil ich eh gerade nur am rumprobieren bin. Aber ich würde gerne Gewissheit haben, dass da kein anderer reinschauen kann.
    Sein Passwort nicht ändern zu können ist wirklich merkwürdig, da würde ich mich mal an deren Support wenden, ob das wirklich nicht geht.

    Aber das ändert nichts daran, dass die KD-Admins immer in deinen Webspace reinschauen können, egal ob du dein Passwort ändern kannst oder nicht. Dein Webspace liegt ja auf einem Server (egal ob virtuell oder nicht) und du hast drauf einen Benutzer und ein Verzeichnis. Leute mit Adminrechten können sich auf einer Maschine alle Dateien anschauen und mit dem su-Kommando auch einfach deine Rolle annehmen. Die Frage für dich ist, ob du die Zugangsdaten aus dem Webserver-Verzeichnis raus bekommst oder nicht.
    Die andere Frage ist, ob du KD und deren Admins vertraust. Wenn ja, dann ist alles gut, ansonsten müsstest du dir was anderes suchen. Wenn die Admins vertrauenswürdig sind, dann schauen die nicht in deine Dateien, ohne das es einen Grund dazu gibt (weil du irgendwie Support brauchst, weil die Polizei die Kundendaten von Sergejs Online-Drogenvertrieb haben will, ...). Wenn sie gescheite Arbeitsverträge haben, ist das auch darin geregelt, was sie dürfen und was nicht. Aber Papier ist geduldig - darum geht es in erster Linie um Vertrauen.
    [Bild: gg_schuetzen_ani.gif] | ~ DauJones ~ | ~ Klopfers-Web ~ | ~ German Bash ~ |
    Die meisten und schlimmsten Übel, die der Mensch dem Menschen zugefügt hat, entsprangen dem felsenfesten Glauben an die Richtigkeit falscher Überzeugungen.
    Bertrand Russell
    Religionskriege sind Konflikte zwischen erwachsenen Menschen, bei denen es darum geht, wer den cooleren, imaginaeren Freund hat. anonym
    Pyrokar ist offline

  10. #10 Zitieren
    Sergej Petrow
    Gast
    Zitat Zitat von Pyrokar Beitrag anzeigen
    Ich weiß nicht ob das bei deinem Webspace geht, aber üblicherweise hinterlegt man Passwörter u.ä. nicht in einem Verzeichnis, das über den Webserver erreichbar ist. In der php-Datei, die Zugang zur Datenbank braucht kann man die Datei, die die Zugangsdaten beinhaltet dann per require einbinden.
    Hm, ich glaube nicht, dass das bei dem funktioniert, was ich eigentlich machen will. Hab vor, ein Programm, welches ich für Open Office Calc in Starbasic geschrieben habe, in php umzusetzen. Hier geht es um Anno Online, wo User die Daten online speichern (nämlich in der Datenbank) und damit eine bessere Übersicht über ihre Wirtschaft zu bekommen.
    Die müssen dann ja irgendwie an die php-Datei, die über require verlinkt wird, rankommen, auch wenn ich nicht online bin. Das geht ja nur über den Webspace.

    Zitat Zitat von Pyrokar Beitrag anzeigen
    Sein Passwort nicht ändern zu können ist wirklich merkwürdig, da würde ich mich mal an deren Support wenden, ob das wirklich nicht geht.

    Aber das ändert nichts daran, dass die KD-Admins immer in deinen Webspace reinschauen können, egal ob du dein Passwort ändern kannst oder nicht. Dein Webspace liegt ja auf einem Server (egal ob virtuell oder nicht) und du hast drauf einen Benutzer und ein Verzeichnis. Leute mit Adminrechten können sich auf einer Maschine alle Dateien anschauen und mit dem su-Kommando auch einfach deine Rolle annehmen. Die Frage für dich ist, ob du die Zugangsdaten aus dem Webserver-Verzeichnis raus bekommst oder nicht.
    Die andere Frage ist, ob du KD und deren Admins vertraust. Wenn ja, dann ist alles gut, ansonsten müsstest du dir was anderes suchen. Wenn die Admins vertrauenswürdig sind, dann schauen die nicht in deine Dateien, ohne das es einen Grund dazu gibt (weil du irgendwie Support brauchst, weil die Polizei die Kundendaten von Sergejs Online-Drogenvertrieb haben will, ...). Wenn sie gescheite Arbeitsverträge haben, ist das auch darin geregelt, was sie dürfen und was nicht. Aber Papier ist geduldig - darum geht es in erster Linie um Vertrauen.
    Wenn es bei Kabeldeutschland direkt wäre, hätte ich wohl weniger Probleme mit. Bisher bin ich mit denen sehr zufrieden. Die Homepagespakete haben sie aber an Subunternehmen vergeben. Da ist das ganze schon nicht mehr so einfach, wenn es um mehrere Ecken geht. Hatte mir überlegt, das Passwort der DB zu verschlüsseln. Aber man kann die ja nicht zurückentschlüsseln. Irgendwo in einer php-Datei steht dann doch das Passwort drin. Da beißt wohl die Maus kein Faden ab. Ist also die Frage, wie gut der Webspace gesichert ist.
    Ich werde mal den Support anschreiben. Die können mir ja sicher was zu sagen, wie das mit der Sicherheit läuft.

    Online mache ich das erste mal was, deshalb war das bisher nie ein Thema für mich gewesen. Jetzt sehe ich erstmal, was da für Probleme bezüglich der Sicherheit auftauchen.

  11. #11 Zitieren
    Tieftöner Avatar von Lookbehind
    Registriert seit
    Dec 2007
    Beiträge
    15.176
    Zitat Zitat von Sergej Petrow Beitrag anzeigen
    ...
    Die müssen dann ja irgendwie an die php-Datei, die über require verlinkt wird, rankommen, auch wenn ich nicht online bin. Das geht ja nur über den Webspace.
    Pyro meinte das etwas anders.
    Du erstellst 2 php-Dateien. Eine mit deinen Einstellungen (Passwort für die DB, etc) und eine mit deinem eigentlichen Programm. In letzterer bindest du erstere über ein require ein. Das bedeutet, dass dein Programm ab der Zeile nur weiter macht, wenn es die php-Datei mit dem DB-Login auch lesen und verwenden kann.
    Der Clou ist jetzt, wo du diese beiden Dateien speicherst. Die Programm-Datei muss, um funktionieren zu können, in einem Verzeichnis liegen, das vom Internet aus aufgerufen werden kann. Das muss aber für die Datei mit den Login-Daten für die DB nicht so sein. Diese kann in einem gänzlich anderen Verzeichnis auf dem Server liegen, welches so über den Webserver gar nicht erreichbar ist.
    Der Effekt der dabei entsteht ist folgender:
    Solange alles funktioniert, wie es soll, kannst du die Login-Daten auch direkt in die Programm-Datei mit rein schreiben. Jemand der über das Internet diese Datei aufruft, wird niemals den Inhalt der eigentlichen PHP-Datei zu sehen bekommen, sondern immer nur, was das Programm darin an Output erzeugt. ... Solange alles funktioniert wie es soll. Sollte mal, aus welchem Grund auch immer, der PHP-Parser auf dem Server versagen, und der Webserver bietet den Quellcode deines Programms feil, sieht die Welt plötzlich anders aus. Wenn jetzt die DB-Zugangsdaten in irgendeiner Datei stehen, die vom Web aus erreichbar ist, kann auch jeder diese Zugangsdaten lesen. Ist die Datei aber gar nicht direkt über den Webserver erreichbar, kann man maximal sehen wie dein Programm generell funktioniert, und das es an einer bestimmten Stelle die Passwort-Datei laden will. Aber an die Passwort-Datei kommt man deshalb noch lange nicht ran.
    Was dir hier in die Suppe spucken kann: Manchmal ist der Webspace so konfiguriert, dass du keine Chance hast, Dateien so ab zu legen, dass sie nicht prinzipiell vom Webserver aus erreichbar sind. Dann bleibt dir nur eins: Darauf vertrauen, dass der PHP-Parser nicht versagt.

    Ja, richtig, das bezieht sich alles auf Besucher der Seite und böse Buben die evtl deine Seite Cracken wollen.
    Zitat Zitat von Sergej Petrow Beitrag anzeigen
    Wenn es bei Kabeldeutschland direkt wäre, hätte ich wohl weniger Probleme mit. Bisher bin ich mit denen sehr zufrieden. Die Homepagespakete haben sie aber an Subunternehmen vergeben. Da ist das ganze schon nicht mehr so einfach, wenn es um mehrere Ecken geht.
    Ja, hier einen vertrauenswürdigen und guten Anbieter zu finden ist immer so eine Sache. Allerdings wirst du nur dann darum herum kommen, dem Admin des Servers zu vertrauen, wenn du selbst dieser Admin bist.
    Die Wahrscheinlichkeit, dass der Server-Admin sich für dein DB-Passwort interessiert, halte ich allerdings für ziemlich gering. Grund: Er ist Admin auf dem Server. Er hat root. Und root kann alles, root darf alles, für root gibt es keine Beschränkungen. Der kommt an den Inhalt deiner DB auch ohne dein Passwort ran.
    Zitat Zitat von Sergej Petrow Beitrag anzeigen
    Hatte mir überlegt, das Passwort der DB zu verschlüsseln. Aber man kann die ja nicht zurückentschlüsseln.
    Das bringt mich noch zu einem anderen Punkt. Der betrifft nicht dein Passwort, welches das Programm braucht um an die Datenbank zu kommen. Sondern es geht um die Passwörter der Nutzer, die sich auf deiner Seite anmelden.
    Mal kurz den Code oben überflogen. Es sieht so aus, als würdest du die User-Passwörter im Klartext in der DB ablegen. Das ist ein absolutes NoGo! Du möchtest dich mit Passwort-Hashing und Salting beschäftigen!
    Grund: Sollte einer es doch mal, auf welchem Wege auch immer, schaffen deine Datenbank zu knacken, hat er eine wunderschöne Liste mit Usernamen und den dazugehörigen Passwörtern, und wahrscheinlich auch noch den dazugehörigen E-Mail-Adressen. Viele User benutzen Passwörter mehrfach bei verschiedenen Diensten. Böse Jungs wissen das, und werden sich freuen eine schöne Liste mit Usernamen und Passwörtern gefunden zu haben, die man mal bei Amazon, eBay und Co testen kann.

    Ein Passwort-Hash mit einem anständigen Salt verhindert sowas. Oder macht es zumindest so aufwändig, dass sich die Sache nicht mehr lohnt.
    Zitat Zitat von Sergej Petrow Beitrag anzeigen
    Irgendwo in einer php-Datei steht dann doch das Passwort drin. Da beißt wohl die Maus kein Faden ab.
    Das hast du richtig erkannt
    Zitat Zitat von Sergej Petrow Beitrag anzeigen
    Ist also die Frage, wie gut der Webspace gesichert ist.
    Ich werde mal den Support anschreiben. Die können mir ja sicher was zu sagen, wie das mit der Sicherheit läuft.
    "Ja, wissen sie, mit der Sicherheit ist es bei uns nicht so richtig weit her. Wir haben halt auf allen Kisten das gleiche root-Passwort, das aus 5 Ziffern besteht. Sagen darf ich ihnen das natürlich nicht. ..."

    Leider erfährt man bei solchen Anfragen oft weniger als nichts. Die meisten halten es ja schon für eine Sicherheitslücke den Leuten zu sagen wie sie ihre Systeme absichern. (Security by obscurity)
    Zitat Zitat von Sergej Petrow Beitrag anzeigen
    Online mache ich das erste mal was, deshalb war das bisher nie ein Thema für mich gewesen. Jetzt sehe ich erstmal, was da für Probleme bezüglich der Sicherheit auftauchen.
    Ja, einer der Punkte der mich an Web-Entwicklung immer genervt hat. Man darf nichts und niemandem trauen. Nichtmal seinem eigenen Code.
    Lookbehind ist offline

  12. #12 Zitieren
    Sergej Petrow
    Gast
    Zitat Zitat von Lookbehind Beitrag anzeigen
    Pyro meinte das etwas anders.
    Du erstellst 2 php-Dateien. Eine mit deinen Einstellungen (Passwort für die DB, etc) und eine mit deinem eigentlichen Programm. In letzterer bindest du erstere über ein require ein. Das bedeutet, dass dein Programm ab der Zeile nur weiter macht, wenn es die php-Datei mit dem DB-Login auch lesen und verwenden kann.
    Der Clou ist jetzt, wo du diese beiden Dateien speicherst. Die Programm-Datei muss, um funktionieren zu können, in einem Verzeichnis liegen, das vom Internet aus aufgerufen werden kann. Das muss aber für die Datei mit den Login-Daten für die DB nicht so sein. Diese kann in einem gänzlich anderen Verzeichnis auf dem Server liegen, welches so über den Webserver gar nicht erreichbar ist.
    Mir ist hier noch nicht ganz klar, wie denn eine Verbindung zu jeder Zeit gegeben sein soll, wenn diese Datei nicht über den Webserver erreichbar ist. Von irgendwo muss ja auch diese Datei erreichbar sein.

    Zitat Zitat von Lookbehind Beitrag anzeigen
    Mal kurz den Code oben überflogen. Es sieht so aus, als würdest du die User-Passwörter im Klartext in der DB ablegen. Das ist ein absolutes NoGo! Du möchtest dich mit Passwort-Hashing und Salting beschäftigen!
    Grund: Sollte einer es doch mal, auf welchem Wege auch immer, schaffen deine Datenbank zu knacken, hat er eine wunderschöne Liste mit Usernamen und den dazugehörigen Passwörtern, und wahrscheinlich auch noch den dazugehörigen E-Mail-Adressen. Viele User benutzen Passwörter mehrfach bei verschiedenen Diensten. Böse Jungs wissen das, und werden sich freuen eine schöne Liste mit Usernamen und Passwörtern gefunden zu haben, die man mal bei Amazon, eBay und Co testen kann.

    Ein Passwort-Hash mit einem anständigen Salt verhindert sowas. Oder macht es zumindest so aufwändig, dass sich die Sache nicht mehr lohnt.
    Ja, das ist klar. Das ist hier erst mal nur zu Testzwecken. Hab zwar schon einiges programmiert, aber noch nie was im Onlinebereich.

    Zitat Zitat von Lookbehind Beitrag anzeigen
    Leider erfährt man bei solchen Anfragen oft weniger als nichts. Die meisten halten es ja schon für eine Sicherheitslücke den Leuten zu sagen wie sie ihre Systeme absichern. (Security by obscurity)
    Na, mal sehen, was da kommt. Habe zwei recht einfache Fragen gestellt.

    Zitat Zitat von Lookbehind Beitrag anzeigen
    Ja, einer der Punkte der mich an Web-Entwicklung immer genervt hat. Man darf nichts und niemandem trauen. Nichtmal seinem eigenen Code.
    Das kommt ja noch hinzu. Was nutzt das beste Sicherheitskonzept, wenn der Code Mist ist? Hab die ersten Tage, seit ich den Webspace habe, immer nach dem Testen die php-Datei auf dem Server gelöscht, weil ich Angst hatte, dass da jemand reinschauen könnte.
    Was noch hinzukommt: Ich hasse es, auf dem Rechner Passwörter zu speichern. Jetzt muss ich in Eclipse die php-Datei mit Passwort und Host usw. füttern...
    Bin da eigentlich so ein kleiner Sicherheitsfanatiker. Aber hier hab ich gemerkt, dass man sich sehr schnell komplett verrückt macht und das wohl auch nicht zielführend ist.

  13. #13 Zitieren
    Tieftöner Avatar von Lookbehind
    Registriert seit
    Dec 2007
    Beiträge
    15.176
    Zitat Zitat von Sergej Petrow Beitrag anzeigen
    Mir ist hier noch nicht ganz klar, wie denn eine Verbindung zu jeder Zeit gegeben sein soll, wenn diese Datei nicht über den Webserver erreichbar ist. Von irgendwo muss ja auch diese Datei erreichbar sein.
    Ich glaube du verwechselst hier was. (Zugegeben, man kann halt beides mit dem gleichen Wort betiteln, kann schon mal passieren )
    Was du mit "Webserver" meinst ist die komplette Kiste, die Hardware inklusive Betriebssystem und allem drum und dran.
    Was ich mit "Webserver" meine, ist lediglich das Stück Software, welches Dokumente auf dem Server (komplette Kiste) in einen http-Stream verwandelt und ihn über das Netzwerk weiter gibt. Um es mal beim Namen zu nennen: Apache2, wahlweise auch lighttpd oder einer der vielen anderen Webserver.
    Zitat Zitat von Sergej Petrow Beitrag anzeigen
    Ja, das ist klar. Das ist hier erst mal nur zu Testzwecken. Hab zwar schon einiges programmiert, aber noch nie was im Onlinebereich.
    ...
    Zu Testzwecken ist es manchmal ganz praktisch eine seperate Testumgebung zu haben, die nicht direkt aus dem Internet erreichbar ist. Das entsprechende System braucht in der Regel nicht mal viel Leistung. N kleines Raspberry-Pi als Webserver (komplette Kiste ) reicht oft schon aus. Oder ne Virtuelle Maschine.
    Lookbehind ist offline

  14. #14 Zitieren
    Legende Avatar von jabu
    Registriert seit
    Jul 2011
    Beiträge
    7.383
    Zitat Zitat von Lookbehind Beitrag anzeigen
    Ich glaube du verwechselst hier was. (Zugegeben, man kann halt beides mit dem gleichen Wort betiteln, kann schon mal passieren )
    Was du mit "Webserver" meinst ist die komplette Kiste, die Hardware inklusive Betriebssystem und allem drum und dran.
    Was ich mit "Webserver" meine, ist lediglich das Stück Software, welches Dokumente auf dem Server (komplette Kiste) in einen http-Stream verwandelt und ihn über das Netzwerk weiter gibt. Um es mal beim Namen zu nennen: Apache2, wahlweise auch lighttpd oder einer der vielen anderen Webserver.
    Dann erlaube ich mir eine kurze Zusammenfassung dessen, was ihn mindestens interessieren sollte, bevor er sich an fortgeschrittene Themen, wie z.B. Datenbanken, heranwagt:

    - Common Gateway Interface, kurz CGI (wegen der Basics, obwohl er vllt. ein Sprachmodul verwendet)
    - die Rolle der Standardein- und Ausgabe (stdin, stdout) im Zusammenhang mit CGI
    - Umgebungsvariablen im Kontext eines CGIs
    - GET, POST und den Unterschied bzw. woher die Daten kommen und wie der Server reagiert
    - HTTP und Zustandslosigkeit
    - Session, Session-ID und Cookie


    Um kurz auf seine Frage einzugehen:

    Die PHP-Dateien werden vom Skriptinterpreter verarbeitet, bevor der Webserver dessen Ausgabe bekommt. Daher ist es dem Skriptinterpreter möglich, auf Dateien zuzugreifen, dessen Auslieferung dem Webserver (z.B. ein Apache) nicht gestattet oder verboten wurde. (Selbst wenn der Skriptinterpreter über ein sprachspezifisches Modul (anstelle eines CGIs) in den Webserver eingebunden ist, ändert das nichts an dem grundsätzlichen Ablauf.)

    Es empfiehlt sich, dem Webserver nur die Auslieferung von Inhalten zu gestatten, welche sich unterhalb eines bestimmten Wurzelknotens des Verzeichnisbaumes befinden. Alles, was sich dann oberhalb befindet oder abzweigt, ist nicht zur Auslieferung durch den Webserver bestimmt.
    Einsteigerpakete sind oft sehr restriktiv, was eigene Konfigurationen angeht, weshalb das nicht immer geht. Falls es der Anbieter erlaubt, kann man dennoch für den Webserver eine Konfigurationsdatei im betreffenden Verzeichnis für dieses ablegen, um damit die globalen Einstellungen teilweise zu überschreiben. Beim Apache kann man z.B. folgendermaßen ein Verzeichnis sperren:

    - Verzeichnis anlegen, worin sich die zu schützenden Dateien befinden sollen
    - eine Datei mit folgendem Namen und mit Unix-Zeilenenden anlegen: .htaccess
    - Folgende Zeile einfügen: Deny from all
    - Datei in das zu schützende Verzeichnis hochladen
    - Das mit unkritischen Daten testen
    - trotzdem niemals PWs im Klartext ablegen, sondern salzen und hashen, denn ein Entschlüsseln ist niemals erforderlich!

    Dein Skriptinterpreter hat trotzdem Zugriff, weil ihn die Konfigurationsdatei des Webservers nicht interessiert. Aber bedenke, dass bei erneutem Aufruf eines Skriptes der Benutzer ein anderer sein kann und wird, schon wegen der Zustandslosigkeit von HTTP, s.o. Daher der Hinweis auf Sessions. Aber auch die sind nicht unbedingt sicher, wenn man nicht einiges bedenkt.

    Eine Funktion, welche in ein geschütztes Skript ausgelagert ist, wird nicht durch den Webserver aufgerufen, sondern durch den Interpreter aus dem aufrufenden Skript heraus, weshalb der Webserver keinen Zugriff braucht.
    Bei der hier geforderten Funktion handelt sich um einen Teil der Programmlogik und nicht um eine Benutzerschnittstelle, weshalb darin Interaktionen mit dem Benutzer deplaziert wären. Trotzdem wäre es immer noch keine gute Idee, Benutzerdaten darin abzulegen, sondern über die Funktion nur diejenigen Daten, die man gerade braucht, von einem gut gesicherten Ort abzuholen.
    Eine strikte Trennung zwischen Benutzerschnittstelle, Programmlogik und Daten ist nicht nur sinnvoll, sondern geboten, solange nicht ein verdammt guter Grund dagegen spricht.

    Die bisherige php-Datei wird mit der Methode POST grundsätzlich wie jede andere Ressource beim Webserver angefragt, mit dem Unterschied, dass jetzt im Header steht, dass es sich eben um POST handelt, wieviele Daten folgen und die zu übertragenden Daten selbst, hier also die Formulardaten. Der Webserver muss nachgucken, ob er das angefragte Dokument ausliefern darf, was er normalerweise direkt tut. Wenn jedoch für bestimmte Dateinamen oder -typen konfiguriert ist, dass ein Skriptinterpreter zur Vorverarbeitung zu verwenden ist, wie hier im Fall von PHP, kann der natürlich zwischendrin unabhängig agieren.

    Bei einer Fehlkonfiguration des Servers, z.B. wenn ihm nicht gesagt wird, dass er den Skriptinterpreter zwischenschalten soll, kann versehentlich das Dokument im Klartext ausgeliefert werden, weshalb die entprechenden Funktionen ausgelagert werden, was dazu führt, dass man nur noch deren Aufrufe sieht.
    Wenn jedoch bei Fehlern im Skript oder beim Interpreter Informationen aus dem Text sichtbar werden, z.B. in Form von Fehler- oder Debugmeldungen, ist diese Methode wirkungslos. Wenn dort irgendwelche Userdaten drinstehen, wird es kriminell. Daher sollten immer nur diejenigen Daten abgeholt werden, die gerade benötigt werden, wobei die so temporär wie möglich zu halten sind. Rückgabewerte von Funktionen sind zu prüfen und haben im Fehlerfall zum Abbruch zu führen, um Schlimmeres zu verhindern. Am gefährlichsten sind nämlich diejenigen Fehler, bei denen augenscheinlich alles ganz normal läuft.

    Zu Testzwecken ist es manchmal ganz praktisch eine seprate Testumgebung zu haben, die nicht direkt aus dem Internet erreichbar ist. Das entsprechende System braucht in der Regel nicht mal viel Leistung. N kleines Raspberry-Pi als Webserver (komplette Kiste ) reicht oft schon aus. Oder ne Virtuelle Maschine.
    Abgesehen von den unzweifelhaften Vorteilen vorstehender Lösungen genügt beim Apache meistens für den Anfang ein lokal installiertes Paket mit allem, was man meistens braucht:
    XAMPP
    WAMP

    Hier ein wichtiger Hinweis: Ich bin kein Webentwickler, also vorsichtshalber alles gegenchecken, was ich so von mir gebe.
    jabu ist offline Geändert von jabu (10.02.2015 um 14:07 Uhr) Grund: Korrekturen und Ergänzungen

  15. #15 Zitieren

    Chef Zauberer
    Avatar von Sweil
    Registriert seit
    Apr 2004
    Ort
    Glasgow
    Beiträge
    8.248
    Wegen den Benutzer-Passwörtern in PHP: Einfach PHP 5.5 nutzen und dann nicht mehr darüber nachdenken - sondern es denen überlassen die wirklich Ahnung davon haben.
    [Bild: TW3_Ev_04.jpg]
    »Jeder sollte einen Milgo zu Hause haben, denn er verursacht nur sehr geringe Kosten.«
    Sweil ist offline

  16. #16 Zitieren
    Sergej Petrow
    Gast
    Heute habe ich Antworten bekommen auf meine Anfragen. Wie hier schon gesagt wurde, ziemlich unbefriedigende Antworten.

    Mein Passwort selbst kann ich nicht anpassen. Sie können mir aber gerne ein neues senden, wenn ich möchte. Bringt also nichts. Wobei der Punkt wohl eh egal ist, da die Admins immer drauf schauen können, wenn sie das wollen. Ich wollte gerne ein längeres Passwort. Das sei aber derzeit nicht möglich.
    Das würde in meinen Augen schon was bringen, da ein Zugriff von außen damit erschwert wird.

    Zu guter Letzt: Die Zugriffsrechte von Dateien, können Sie über Ihr FTP Programm durchführen/anpassen.

    Da das oben auch schon mal Thema war.

    Ich habe das wohl noch nicht richtig verstanden.

    Kann ich die Zugriffsrechte so verteilen, dass ich über eine php-Datei die Zugriffsdaten meiner Datenbank einlesen kann, aber niemand über die Adresszeile im Browser oder was auch immer Zugriff auf diese Datei hat? Ist das damit gemeint?

  17. #17 Zitieren
    Held Avatar von Lolomoloko
    Registriert seit
    Aug 2006
    Ort
    ~/
    Beiträge
    5.700
    Zitat Zitat von Vertaler Beitrag anzeigen
    Insbesondere nicht, wenn das ganze schon ein paar Jährchen alt ist. Die mysql_-Funktionen sind seit PHP 5.5 (Mitte 2013) deprecated (veraltet, überholt), man sollte stattdessen lieber auf MySQLi oder PDO zurückgreifen. Zu MySQLi ist es leichter von den alten Funktionen zu migrieren, im Prinzip kann man alle mysql_-Funktionsaufrufe durch mysqli_-Aufrufe ersetzen (das nutzt dann zwar nicht alles, was MySQLi zu bieten hat, aber für den Einstieg reicht es).
    Und wenn man das migriert hat (bzw. während man das tut) kann man direkt zu prepared statements wechseln.
    Lolomoloko ist offline

  18. #18 Zitieren
    Tieftöner Avatar von Lookbehind
    Registriert seit
    Dec 2007
    Beiträge
    15.176
    Zitat Zitat von Sergej Petrow Beitrag anzeigen
    ...
    Zu guter Letzt: Die Zugriffsrechte von Dateien, können Sie über Ihr FTP Programm durchführen/anpassen.

    Da das oben auch schon mal Thema war.

    Ich habe das wohl noch nicht richtig verstanden.

    Kann ich die Zugriffsrechte so verteilen, dass ich über eine php-Datei die Zugriffsdaten meiner Datenbank einlesen kann, aber niemand über die Adresszeile im Browser oder was auch immer Zugriff auf diese Datei hat? Ist das damit gemeint?
    Ja, nein.

    Also, ja, die Idee ist schon, dass du auf dem Server eine php-Datei mit den Zugangsdaten zur Datenbank liegen hast, auf die aber keiner über eine passende Browser-URL zugreifen kann.

    Aber, nein, das regelt man nicht über die Zugriffsrechte per FTP. Du kannst zwar generell über dein FTP-Programm auch Zugriffsrechte anpassen. Aber um zu verhindern, dass die Datei jemand per Browser aufrufen kann, müsstest du die Zugriffsrechte so setzen, dass deine Webseite (dein PHP-Programm) da auch nicht mehr ran kommt. ... well... Blöd.

    Der richtige Weg wäre, das über die Konfiguration des Virtual-Hosts in der Webserver-Konfiguration zu machen (Document-Root). Da kommt man aber als reiner "Nutzer" eines solchen Web-Hosting-Pakets oft nicht ranl. Man kann sich manchmal mit .htaccess behelfen, was ich, wenn es denn überhaupt geht, auch kackendreist machen würde. Wird den Betreiber zwar nicht freuen, weil .htaccess gewisse Performance-Nachteile hat, aber das würd ich in so einem Fall einfach mal seine Sorge sein lassen.



    Ach ja, Passwort-Längen begrenzen ist ja mal sowas von 90er...
    Lookbehind ist offline

  19. #19 Zitieren
    Legende Avatar von jabu
    Registriert seit
    Jul 2011
    Beiträge
    7.383
    Zitat Zitat von Sergej Petrow Beitrag anzeigen
    Zu guter Letzt: Die Zugriffsrechte von Dateien, können Sie über Ihr FTP Programm durchführen/anpassen.
    [...]
    Kann ich die Zugriffsrechte so verteilen, dass ich über eine php-Datei die Zugriffsdaten meiner Datenbank einlesen kann, aber niemand über die Adresszeile im Browser oder was auch immer Zugriff auf diese Datei hat? Ist das damit gemeint?
    Du musst klar zwischen Berechtigungen auf Dateiebene (Sache des Betriebssystems) und denen des Webservers/Apaches (Sache der Anwendung) trennen! Das sind, ähnlich Zwiebelschalen, zwei ineinanderliegende Sicherheitsebenen:

    Dabei befindet sich der Webserver ganz außen, denn er kann darüber bestimmen, was nach außen gelangt und was nicht, da er mit der Außenwelt kommuniziert. Deswegen must du dem Webserver sagen, was er ausliefern darf und was nicht, indem du ihn konfigurierst. Trotzdem kannst du nicht hundertprozentig sicher sein, dass deine Einstellungen greifen, denn dein Anbieter könnte die Konfiguration ändern, was z.B. eine .htaccess unwirksam machen könnte. Aber das ist nicht die richtige Konfigurationsdatei, sondern sie überschreibt die übergeordnete Konfiguration.
    Mit Glück gibt es aber, wie ich bereits schrieb, eine sinnvolle Vorkonfiguration, indem es bereits weiter oben im Verzeichnisbaum möglich ist, Verzeichnisse oder Dateien anzulegen, welche der Webserver nicht ausliefert. Diese Möglichkeit würde ich unbedingt prüfen, weil sie üblich und sinnvoll ist.

    Die nächste Schale nach innen ist das Dateisystem, worauf deine Frage abzielt. Nun, wie so oft im Leben kommt es darauf an: Du musst grundsätzlich davon ausgehen, dass der Webserver und das PHP-Modul unter demselben Benutzer und seinen Rechten laufen, sodass sich über Berechtigungen, welche du mit deinem FTP-Programm setzen kannst, nichts ausdifferenzieren lässt.
    Jetzt kommt das große Aber....
    Beispielsweise ist das bei meinem Anbieter trotzdem möglich. Der Webserver läuft unter einer Gruppe, deren Berechtigungen man mit einem FTP-Programm abändern kann, was üblich ist. Normalerweise würde das auch für ein PHP-Modul gelten. Nicht so bei meinem Anbieter: Der Zugriff durch Skripte ist immer noch möglich, obwohl der Webserver keinen Zugriff hat, was deinen Forderungen ebenfalls entspricht. Vermutlich verwendet er aktuell CGI oder Fast-CGI und einen alternativen Benutzerkontext. Falls sich das mal ändert, könnte sich an den Zugriffsmöglichkeiten urplötzlich etwas ändern, wobei man nicht genau weiß, in welche Richtung, also ob die Skripte dann entweder nicht mehr zugreifbar sind, oder ob sie vom Webserver ausgeliefert werden, was schlimmer wäre.

    Also ist dieser Weg mit Berechtigungen auf Dateiebene zwar im Einzelfall möglich aber auch nichts, worauf man sich allein verlassen sollte. Die Konfiguration des Webservers, hier wohl eines virtuellen Hosts, ist schon vorzuziehen, notfalls schmeisst du eine .htaccess rein und hoffst, dass es funktioniert. Zusätzlich kannst du immer noch selektiv Dateirechte entziehen, wobei du das aber separat testen musst.
    Solange der Server dermaßen fremdbestimmt ist, würde ich jedoch alles versuchen, was einen Sicherheitsgewinn bringt, damit die Zwiebel möglichst viele Schalen hat, um die Wahrscheinlichkeit sich überlappender Schutzlücken möglichst geringzuhalten.

    Ich hatte wegen der Sicherheit reflexhaft und damit voreilig reagiert, denn ich hatte den allgemeinen Fall im Blick, wenn PWs geprüft werden, wozu tunlichst kein PW gespeichert werden sollte, sondern ein Hash. Hier kann das natürlich nicht funktionieren, weil dem Datenbankserver ein PW übermittelt werden muss. Dieses sollte nicht zu mehr berechtigen als unbedingt nötig. Zudem sollte die DB selbst nur lokal erreichbar sein, und es sollte bei aus dem Web erreichbarer Konfigurationssoftware für die Datenbank neben einem sicheren Kennwort erwogen werden, ob man diese Zugriffsmöglichkeit überhaupt braucht.
    jabu ist offline

  20. #20 Zitieren
    Sergej Petrow
    Gast
    Zur Datenbank würde der User keinen Zugriff erhalten. Er muss sich lediglich einloggen, kann aber direkt keinerlei Abfragen oder so stellen. Mir schwebt vor, ein Tool zu entwickeln für Anno Online, um den Wirtschaftskreislauf besser im Blick zu haben. Das habe ich eigentlich in Form einer OpenOffice Calc Anwendung schon erstellt. Also reichlich Makros mit Starbasic.
    Online wäre es aber noch ein bisschen schöner, weil einfacher. Hierzu müssen natürlich die Wirtschaftsdaten des jeweiligen Users gespeichert. Die wollte ich in der Datenbank speichern.
    Sind also jetzt keine hochbrisanten Daten. Nur geht es mir einfach ums Prinzip.

    Hm, die Root ist eine Ebene höher, als meine Website. Muss mal probieren, ob ich da schon Verzeichnisse anlegen kann.

    Hier ist insgesamt noch sehr viel neues für mich. Muss mich da erst vernünftig reindenken.

Seite 1 von 2 12 Letzte »

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •