2010-01-09 6 views
15

Ich bin ein Anfänger arbeiten an einem Login-Skript in PHP. Dies ist die Form Token Aussage, dass ich so weit:PHP Form Token Verwendung und Handhabung

$_SESSION["form_token"] = md5(rand(time(), true)) ; 

Die Aussage unmittelbar nach dem Benutzer ausgegeben wird, zeigt, dass er/sie sich anmelden will.

Mein begrenztes Verständnis besteht darin, dass der Zweck des Tokens darin besteht, einen eindeutigen Benutzer zu einem bestimmten Zeitpunkt zu identifizieren und die Form Token-Informationen zu verschleiern.

Dann wird alles verschwommen. Hier sind meine 3 offenen Fragen:

  1. Wann ist die beste Zeit, um das Formular-Token aus Sicherheitsgründen zu überprüfen?

  2. Wie überprüfe ich es?

  3. Wann, wenn überhaupt, zerstöre ich das Formular-Token? (IOW, würde die Form Token "aktiv" bleiben, bis der Benutzer?

  4. abmeldet
+2

FYI MD5 ist etwas begrenzt, und wenn Sie eine zufällige Zeichenfolge erzeugen, muss ich schlage vor, Sie verwenden diese stattdessen: $ id = SHA1 (mt_rand()); Wenn Sie rand() verwenden, erhalten Sie nur 32.000 mögliche Kombinationen. – TravisO

+0

verwandt: http://stackoverflow.com/questions/5111007/does-php-have-an-authenticity-token-like-rails – baptx

Antwort

12

Es gibt keine Notwendigkeit zu tun, was Sie versuchen. Wenn Sie eine Sitzung in PHP mit session_start() starten, wird bereits eine eindeutige SESSIONID für Sie generiert. Sie sollten nicht setzen dies auf das Formular. Es wird standardmäßig über Cookies behandelt. Es besteht auch keine Notwendigkeit, die SESSIONID zu überprüfen, die wiederum für Sie behandelt wird.

Sie sind verantwortlich für den Benutzer zu authentifizieren und ihre authentifizierte Identität zu speichern (zB $ _SESSION [ ‚user_id‘] = $ userId in der Sitzung. Wenn ein Benutzer Sie ihre Sitzung mit session_destroy zerstören abmeldet.

Sie sollten Stellen Sie sicher, dass session_start() einer der ersten Dinge für alle Seiten auf Ihrer Website ist.Hier

ist ein einfaches Beispiel:

<?php 
session_start(); // starts new or resumes existing session 
session_regenerate_id(true); // regenerates SESSIONID to prevent hijacking 

function login($username, $password) 
{ 
    $user = new User(); 
    if ($user->login($username, $password)) { 
     $_SESSION['user_id'] = $user->getId(); 
     return true; 
    } 
    return false; 
} 

function logout() 
{ 
    session_destroy(); 
} 

function isLoggedIn() 
{ 
    return isset($_SESSION['user_id']); 
} 

function generateFormHash($salt) 
{ 
    $hash = md5(mt_rand(1,1000000) . $salt); 
    $_SESSION['csrf_hash'] = $hash 
    return $hash; 
} 

function isValidFormHash($hash) 
{ 
    return $_SESSION['csrf_hash'] === $hash; 
} 

Edit: ich die ursprüngliche Frage falsch verstanden. Ich habe oben die relevanten Methoden zum Generieren und Validieren von Form-Hashes hinzugefügt.

Bitte beachten Sie die folgenden Ressourcen:

+0

Da ist etwas, das ich nicht verstehe. Ich benutze auch PHP-Sitzungen für Token, aber jedes Mal, wenn ich eine Sitzung modifiziere, werden alle modifiziert (das "Datum geändert" aller tmp-Dateien ändert sich). Gibt es eine Verbindung zwischen Sitzungen, die unterschiedliche Benutzer identifizieren? – Sthe

18

diese CSRF-Angriffe zu verhindern ist

http://en.wikipedia.org/wiki/Cross-site_request_forgery

eine bösartige Site könnte theoretisch ein Formular an, dass Beiträge zu Ihre Anwendung Das Formular könnte Anweisungen enthalten, die eine Datenverletzung oder eine unerwünschte Aktion verursachen Der Benutzer könnte dazu verleitet werden, das Formular zu senden, das die App annehmen würde, weil der Benutzer bereits angemeldet ist. Ein Formular-Token stellt sicher, dass das Formular von Ihrem erstellt wurde Website und nicht irgendeine andere Seite

Überprüfung der HTTP_REFERER ist oft gut genug, aber nicht als vollständige Lösung (https zum Beispiel wird die Referrer-Zeichenfolge nicht senden).

Wenn Sie wirklich alle Formulare mit einem Token sichern möchten, können Sie einige Komfortfunktionen wie emitToken() und checkToken() erstellen, die es für die gesamte Site funktionieren lassen.

einige Beispiele:

http://phpsec.org/projects/guide/2.html

http://www.rodsdot.com/php/CSRF_Form_Protection.php

+2

HTTP_REFERER ist NICHT vertrauenswürdig, verlassen Sie sich nie darauf, weil es leicht bearbeitet werden kann! – Heitor