2012-03-27 14 views
0

Ich versuche, eine gute Lösung zu finden, um URL-Rewriting zu verhindern. Bisher habe ichPHP URL-Manipulation verhindern

session_start(); 
$userEmail = $_SESSION["email"]; 
$user = $_GET["user"]; 

if(!isset($_SESSION["email"])){ 
header("Location:login.php"); 
} 

if($user !== $_SESSION["email"]){ 
header("Location:notes.php?user=$userEmail"); 
} 

Das letzte Bit des Codes erzeugt einen Umleitungsfehler.

+0

Ist diese Datei notes.php? – BoltClock

+0

Ja notes.php ist eine Datei – Unsuspected

+1

Zeigen Sie den Inhalt von notes.php. – davidethell

Antwort

1

Möchten Sie URL-Manipulationen auf dieser Seite verhindern, oder notes.php?

Ohne notes.php oder andere Seiten zu sehen, ist es schwer zu sagen. Aber zu verhindern URL Manipulation, es ist immer gut, um die $_SERVER['HTTP_REFERER'] auf sensible Seiten zu überprüfen, indem Sie etwas zu tun, wie:

if ($_SERVER['HTTP_REFERER'] !== "previous_page.php") { 
header("Location: error_page.php"); 
session_destroy(); 
exit; 
} 

Aber das ist nicht voller Beweis, denn wenn ein Angreifer auf previous_page.php ist, kann er einfach auf der Seite durchsucht Wir versuchen zu schützen, daher ist weiterer Schutz erforderlich.

Sie könnten (und sollten) ein Tokensystem implementieren. Dies geschieht folgendermaßen:

$_SESSION['token'] = md5(uniqid(rand(), TRUE)); 

Dies wird eine schöne lange Zeichenfolge generieren, die für die Person eindeutig ist, die diese Seite durchsucht. Der Zweck dabei ist, diese Session-Variable als $_GET Variable in die nächste Seite zu übergeben, dann vergleichen Sie die beiden, um sicherzustellen, dass sie einander gleich sind. Dies ist so gemacht:

$token = $_SESSION['token']; 
header("Location:notes.php?user=$userEmail&token=$token"); 

//...then, on notes.php: 
if ($_GET['token'] !== $_SESSION['token']) { 
header("Location: error_page.php"); 
session_destroy(); 
exit; 
} 

Allerdings könnte eine sehr schlaue Person dies umgehen. Ich würde vorschlagen, mehr über "CSRF Forgery" zu recherchieren. Hoffe, das bringt dich in die richtige Richtung.

+0

Der Header HTTP_REFERER wird vom Browser bereitgestellt und kann daher nicht vertrauenswürdig sein. Jeder mit 'curl' oder' wget' kann es leicht fälschen. – ghoti

+0

Es gibt Löcher in fast allen Arten von Sicherheit. 'HTTP_REFERER' ist leicht by-passable, aber es stumpft zumindest ein paar Leute, was den gesamten Schutz erhöht. – Norse

+0

Ich stimme nicht zu. Die Implementierung einer sicheren Lösung ist der einzige Schutz. Wenn Sie wissen, dass es leicht gefälscht ist, warum überhaupt implementieren? Halbe Lösungen verschwenden nur Zeit, indem sie Sie von der eigentlichen Aufgabe ablenken. Sie können HTTP_REFERER nicht vertrauen. Also nicht, und gehe zu etwas, dem du vertrauen kannst. – ghoti

0

Es scheint so, als ob die URL-Manipulation, die Sie vermeiden möchten, nur angemeldeten Benutzern den Zugriff auf eine Seite ermöglicht. Wenn dies der Fall ist, geben Sie ihnen entweder einen signierten Cookie oder eine Sitzungs-ID, die Sie in einem Cookie speichern.

Wenn das nicht das ist, was du meinst, bitte formuliere die Frage - was versuchst du zu verhindern?

Verwandte Themen