windhund: Authentifizierung mit einer Sessionvar.?

Ich bin dabei eine Applikation zum Administrieren von Userdaten zu entwickeln. Die Userdaten sind alle in einer mySQL DB.

Man logt sich ein auf einer Seite login.html. Diese schickt POST Var. an index.php.
index.php reagiert ausschliesslich auf diese POST Variablen,
Bleiben die aus oder sind diese falsch, so bricht das Script mit Fehlermeldung ab. In index.php wird eine Session gestartet.

Im nächsten Script 'admin.php' nun sollen die User administriert werden. Man gelangt dorthin über hardlinks die index.php ausgibt, zB. etwa so:

admin.php?act=update&sort=all

dort wird die Session normal wiederaufgenommen (1. zeile im script):

session_start()

ich plane, in dieser Session vorher eine geheime Var. zu hinterlegen, die auf "admin.php" ausgelesen werden soll. Eine Art Passwort.

also in der index.php:
$_SESSION['auth_key'];

auslesen in der admin.php:

$auth = $_SESSION['auth_key'];  
if ($auth == '') {  
//routinen zum administrieren, DB connect, usw. usw.  
//bis schliesslich zum link zum logout  
}  
else {  
// nicht auth., abbruch!  
}

Ein Angreifer könnte evtl. die admin.php aufrufen, und, und selbst wenn er die original SID nicht kennt, in den Adminbereich gelangen. Daher plane ich eine Authentisierung wie oben. Ist das ok so oder gibt es (vermutlich) "geschicktere" Methoden?
achja, https:// scheidet aus.

  1. echo $begrüßung;

    Man logt sich ein auf einer Seite login.html. Diese schickt POST Var. an index.php.
    index.php reagiert ausschliesslich auf diese POST Variablen,
    Bleiben die aus oder sind diese falsch, so bricht das Script mit Fehlermeldung ab.

    Das würde ich so nicht machen. Beim Anmelden vertippt man sich ja gelegentlich, und dann möchte man sicher gern einen zweiten Versuch starten können. Stattdessen schriebe ich ein Login-Modul, das in alle Seiten eingebunden wird, die durch Login gesichert sein sollen. Dieses Modul prüft
    a) auf gültige Session-Daten,
    b) gesendete Anmeldedaten oder
    c) stellt ein Formular zum Eingeben dieser zur Verfügung.

    Im Fall a) macht es nichts weiter, gibt vielleicht eine Logged-In-Meldung aus. Fall b) prüft die Daten und scheibt in die Session das Ergebnis (angemeldet ja/nein oder welche Berechtigungsstufe der Nutzer hat). Wurden fehlerhafte Daten gesendet, gibt es einen Meldungstext und das Anmeldeformular. Ohne POST-Daten ist es Fall c) und der gibt nur das Formular aus.

    In index.php wird eine Session gestartet.

    Das musst du in jedem zu sichernden Script machen. Bei mir übernähme das das Login-Modul. Der Haupt-Teil der Seite sucht in der Session nach einer gültigen Berechtigung und gibt dementsprechend Inhalt aus oder auch nicht.

    Im nächsten Script 'admin.php' nun sollen die User administriert werden. Man gelangt dorthin über hardlinks die index.php ausgibt, zB. etwa so:
    admin.php?act=update&sort=all

    Bei mir wäre es auch egal, woher ein Nutzer kam oder was er aufruft, denn ein Woher gibt es in sowieso HTTP nicht. Jedes Script muss deshalb selbst prüfen, ob es seinen Inhalt preisgibt oder nicht.

    ich plane, in dieser Session vorher eine geheime Var. zu hinterlegen, die auf "admin.php" ausgelesen werden soll. Eine Art Passwort.

    Jede Art Daten in $_SESSION sind im Prinzip geheim [1]. Da kannst du Klartext reinschreiben. Der Anwender bekommt diesen nicht zu Gesicht, wenn du ihn nicht ausgibst.

    [code lang=php]$auth = $_SESSION['auth_key'];
    if ($auth == '') {

    Es ist Unfug, den $_SESSION-Eintrag einerseits umzukopieren, andererseits ihn ohne auf dessen Existenz zu prüfen einfach auszulesen.

    if (isset($_SESSION['auth_key']) and $_SESSION['auth_key'] == '...')
        // berechtigt
      else
        // nicht berechtigt

    Ein Angreifer könnte evtl. die admin.php aufrufen, und, und selbst wenn er die original SID nicht kennt, in den Adminbereich gelangen.

    Wenn er die SID nicht kennt, oder eine falsche mitbringt, wird eine neue Session erstellt. Die hat ja keine Daten gespeichert, also schlägt schon die Existenzprüfung fehl. Erledigt der Fall. Bringt er hingegen eine SID mit, zu der gültige Session-Daten hinterlegt sind, kannst du sowieso nicht unterscheiden, ob der Aufrufer nun im berechtigten Besitz der SID war oder nicht. Ebenso wenig, wie du anhand einer korrekt eingegebenen Usernamen-Passwort-Kombination eine Aussage über einen Missbrauch treffen kannst oder nicht. Du solltest einfach der SID und den Anmeldedaten vertrauen, das sollte hinreichend sicher sein. Wenn du sensible Daten per Webinterface verwalten willst, bei deren Missbrauch erheblicher Schaden entstehen könnte, solltest du jedoch die Sache mit einem Sicherheitsexperten planen.

    [1] Obacht geben sollte man bei der Konfiguration der Session, wenn man auf einem Server arbeitet, der weitere User oder Projekte beherbergt. Oft ist nur das allgemeine Temp-Verzeichnis als Speicherort für die Session-Daten konfiguriert und hier kann zum einen normalerweise jeder alle Daten lesen und zum anderen jeder mit seinen individuellen Einstellungen die Sessions der anderen beeinflussen. PHP läuft ja nur, wenn ein Script gestartet wurde. Also kann es auch nur dann Wartungsarbeiten durchführen. PHP prüft bei jedem Session-Start gemäß der individuellen Konfigurationswerte die Gültigkeit der Session-Dateien und räumt gegebenenfalls auf. Hat nun jemand die Verfallszeit aggressiv eingestellt, betrifft das alle Session-Dateien am eingestellten Ort. Deshalb ist es sinnvoll, sich einen eigenen session.save_path konfigurieren. Dieser sollte selbstverständlich außerhalb des per Web abrufbaren Bereichs liegen.

    echo "$verabschiedung $name";

    1. In index.php wird eine Session gestartet.
      ..Der Haupt-Teil der Seite sucht in der Session nach einer gültigen Berechtigung und gibt dementsprechend Inhalt aus oder auch nicht.

      aha danke. ich denke das bringt mich auf die richtige Spur

      if (isset($_SESSION['auth_key']) and $_SESSION['auth_key'] == '...')
          // berechtigt
        else
          // nicht berechtigt

      ok das liest sich besser. ich denke ich hab's (weitgehend ) verstanden :)

      Danke, Gruß