PHP uns sein Login

Erstmal einen guten Tag an alle...

Ich bin momentan bei der Rechere für einen "sicheren" Login Bereich in PHP.
Der Bereich soll die Zugangskontrolle sein für eine Kontaktseite.

Jetzt gibt es vor und Nachteile, ob man PHP nutzen sollte oder nicht, Ich weis.

Habe mir, so denke ich jetzt einigermaßen wissen angelesen, und wollte mal nach Eurer Meinung fragen. Ich denke das viele Leute auch mehr sehen...

Habe mir jetzt ein Script herausgesucht ("BasisScript"), welches als Grundlage dienen sollte. Wo würdet Ihr bedenken dabei haben, bzw. um was sollte man es erweitern.
Hier der Link:
http://tut.php-quake.net/login.html

Für mich gilt soweit:

1. Alles was der Benutzer eingibt sollte auf alles geprüft werden.
2. Eventuell, wenn Möglich SQL Fehlermeldung umleiten in .txt Datei und nicht am Screen zeigen.
3. 3x PW falsch, IP sperren
4. SQL Abfrage in der DB oder in einer Datei Speichern und von dort abrufen.
5. Select prüfen, und auswerten bevor er an dei DB geht

Ist das spweit ansatzweise richtig?

Wäre super wenn Ihr Euch kurz die Zeit nehmen könntet um das Script zu analisieren...
Ich weis es ist Aufwendig...

Vielleicht kann man hier ja daraus auch ein Beispiel Example entwickeln,
Was andere User helfen könnte... <-- Nur als Vorschlag... soll nicht heißen das ich zu faul bin... ;-)

Ok Danke soweit...

ByteSurfer
 
Hallo,
Original von ByteSurfer
1. Alles was der Benutzer eingibt sollte auf alles geprüft werden.
Hoffe du hast das Konzept richtig verstanden

2. Eventuell, wenn Möglich SQL Fehlermeldung umleiten in .txt Datei und nicht am Screen zeigen.
Gibt ne Einstellung in der php.ini, screen errors oder so ähnlich.

4. SQL Abfrage in der DB oder in einer Datei Speichern und von dort abrufen.
Macht gar keinen Sinn, kann sogar gefährlich werden wenn sie in einer Db stehen.

5. Select prüfen, und auswerten bevor er an dei DB geht
Ein escapen mit mysql_escape_string() der User-Parameter reicht vollkommen aus.


Ist das spweit ansatzweise richtig?
Viel wichtiger ist die sichere Programmierun, dazu gibts aber im Netz (auch hier) genug zu lesen
 
Ich arbeite auch gerade an einem PHP-Projekt, in dem ich versuche, die Sicherheit zu maximieren. Dabei bin ich auf zwei Sachen gestoßen:

1) Lege einen extra Speicher für Benutzervariablen an, den du nur im Bedarfsfall befüllst:
Script benötigt GET-Variable $x -> befülle $Uservars mit $_GET['x'] (gleichzeitig exscapen, evtl. sogar Typencheck auf Integer o.ä.) -> Lese $Uservars['x'].
Wenn du niemals Variablen diurekt ansprichst (am ende sogar über register_globals!), kann es nur schwer passieren, dass dir jemand da was ungewolltes untermogelt.

2) Wenn du PHP >= 5 und MySQL >= 4.2 hast, kannst du statt der mysql die mysqli-Erweiterung von PHP nehmen (falls sie auf deinem Host vorhanden ist). Dort kannst du statt normalen Queries sogenannte "Prepared Statements" absetzen, welche von MySQL selbst gegegn MySql-Injections geschützt werden.
PHP:
<?php
$db = new mysqli($host, $user, $password, $db);
if (mysqli_connect_errno()) {
  die(__("Fatal Error: MySQL connection refused. Error Code:<br>\n") . mysqli_connect_error());
}
$stmt =  $db->stmt_init();
$success = $stmt->prepare('select feld1, feld2 from table where feld3 = ?');
// ? = Statement-Platzhalter
$wert = $Uservars['userwert'];
$stmt->bind_param("s", $wert);
$stmt->bind_result($feld1, $feld2);
$stmt->execute();
$stmt->store_result();
for ($i = 0; $i < $stmt->num_rows; $i++) {
  $stmt->fetch();
  echo "Feld1: $feld1, Feld2: $feld2 \n";
}
?>
Genaueres findest du in Netz.

mfg, metax.
 
Was ich auf http://tut.php-quake.net/login.html finde, sieht korrekt aus:
- Parameter an den richtigen Stellen escaped
- nichts Uninitialisiertes
- korrekte Logik

Wenn Du daran denkst, daß das Zeug auch öffentlich verbreitet wird (wobei ich z.B. an die PHP-Sonntags-Coder in einer Firma meiner Stadt denke, die mit einiger Wahrscheinlichkeit irgendwann über sowas stolpern könnten), würde ich noch empfehlen, in den Code eine Zeile zur Sicherung gegen falsch konfigurierte Server einzubauen, die dem unbedarften Anfänger dennoch einen einigermaßen sinnvollen Kommentar in das ausgelieferte Dokument setzt.
 
PHP:
if($_SESSION['IP'] != $_SERVER['REMOTE_ADDR']) {
            echo "<p class=\"error\">\n";
            echo "    Sie dürfen nicht die Session von einem\n";
            echo "    anderen user Benutzten. Bitte benutzen sie\n";
            echo "    folgenden Link um zur Homepage zu gelangen.\n";
            echo "    <a href=\"/\">Zurück zur Homepage</a>\n";
            echo "</p>\n";
            die(); // Aus Sicherheitsgründen die Abarbeitung sofort beenden
}

Wobei ich diesen Teil überdenken würde, da man sich mit dieser Methode auch User aussperren kann. Es gibt Provider die Ihre Kunden über verschiedene Proxys schicken, so z.B. AOL, mit dieser Methode würdest Du diese User einfach aussperren. Klar, die Sicherheit wird mit dieser Methode erhöht, man sollte aber auch an evtl. auftretende Probleme denken.
 
Das interessiert mich jetzt nochmal: AOL schickt seine Benutzer WÄHREND einer Einwahlperiode über verschiedene Proxys (so daß zwei verschiedene Klicks im Browser über zwei verschiedene IPs vermittelt werden können)?

Falls das stimmt, könnte dieser Schutz gegen Session-Klau aber auch optional gemacht werden. Immerhin geht es dabei darum, einen UNBEDARFTEN DAU vor dem versehentlichen Preisgeben seiner Session (durch dummes Surf-Verhalten) zu schützen. Ein Benutzer, der es anders benötigt (z.B. TOR-Benutzer), sollte den Schutz bewußt abschalten dürfen. Und falls gewisse Provider so eine Proxy-Streuung zwangsweise anwenden, könnte man für genau deren IP-Bereiche das Zeug umgehen.

Lange Rede, kurzer Sinn: einfach zwei Zusatzbedingungen in das if-Konstrukt aufnehmen: Einmal für eine User-Präferenz, einmal für einen preg_match gegen einen Remote-IP-Bereichs-Ausdruck!
 
Das interessiert mich jetzt nochmal: AOL schickt seine Benutzer WÄHREND einer Einwahlperiode über verschiedene Proxys (so daß zwei verschiedene Klicks im Browser über zwei verschiedene IPs vermittelt werden können)?

Ein AOL User wird/kann während seiner Session über verschiedene AOL-Proxys geschickt werden. Es gibt auch noch ein weiteres Problem mit dieser Art, nehmen wir z.B. mal ein Labor, in dem 100 Leute arbeiten und alle auf der gleichen Plattform angemeldet sind, hier wäre ein Sessionklau auch sehr einfach.

Immerhin geht es dabei darum, einen UNBEDARFTEN DAU vor dem versehentlichen Preisgeben seiner Session (durch dummes Surf-Verhalten) zu schützen.

Tja, leider ist das nicht so einfach, denn wenn Du mit dieser Methode einen User aussperrst wird sich dieser User beim Betreiber beschweren und dieser beschwert sich bei der Firma die das ganze entwickelt hat.

Und falls gewisse Provider so eine Proxy-Streuung zwangsweise anwenden, könnte man für genau deren IP-Bereiche das Zeug umgehen.

Was ein ziehmlicher Aufwand werden kann, da man ja vorher noch nicht weiss woher der User kommt, er könnte ja genau so gut in einer Firma hinter einem Proxy sitzen.

Und ich spreche hier aus Erfahrung, da wir gerade ein Social Network Portal programmieren und genau diese Problematik hatten.

Für eine kleine private Seite oder einen Adminbereich ist diese Methode schon ok, aber wenn es größer wird bekommst damit nur Probleme.
 
Gute Diskussion zum Thema...

Wenn eine Gruppe von Benutzern hinter einem Proxy sitzt, bedeutet das nicht ein Wechseln der Adresse. Sondern halt nur, daß mehrere Benutzer dieselbe Adresse verwenden. Also ist das KEIN Gegenargument gegen diese Sicherungsmaßnahme. Sondern nur ein Fall, in dem diese Sicherungsmaßnahme gerade nicht zur Wirkung kommt (ohne positive, aber auch ohne negative Wirkung).

Ich würde nicht deswegen, weil sie eventuell in dem einen oder anderen Detailbereich NICHT wirksam werden könnte, ALLEN usern der Welt diese Unterstützung verweigern. Immerhin geht es darum, diese anderen Leute da draußen zu unterstützen. Selbst wenn das nur für 10% wirksam wäre (während die restlichen 90% unberührt bleiben würden), wären diese 10% dann schon dankbar (oder zumindest gut bedient).
Und ich denke nicht, daß diese 5...6 Zeilen PHP-Code - die ja eh schon existieren - überhaupt als Belastung diskussionswürdig sind.

Zu AOL: Die dürften doch aber mit dieser Vorgehensweise recht einsam dastehen, oder? Und die haben doch für diese Zuweisungsmethode einen konkreten, fest definierten Bereich von Adressen, oder? Also sollte das doch durch einen einfache Testausdruck abzufangen sein, oder?

Als Boardbetreiber kann ich mir zwei Methoden zur Einrichtung dieses Ausdrucks vorstellen:
1) Für AOL-User einen extra Text auf die Seite stellen, daß sie ein Häckchen in einer Checkbox setzen mögen (und diesen Parameter einfach in den Session-Daten hinterlegen).
2) Die Zugriffe mit diesem Parameter protokollieren lassen. Das führt in kürzester Zeit zu einer Übersicht eben jenes - aktuell verwendeten - Adreßbereiches und kann auch in Zukunft helfen, eventuelle Änderungen dieses Bereiches mitzukriegen.
 
hmm. komisch ich dachte immer sichere logins wären garnicht schwierig. o_O

Ich hab die bis jetzt immer so verwirklicht, dass ich nach dem formular mit name + pw geprüft hab ob zum passenden mysql_escape_string(name) das passwort das selbe ist wie das eingegebene. (also dann den hash) wenn ja, schreib ich den namen in die session.
jetzt prüf ich vor jeder aktion oder seite die man nur eingeloggt sehen darf ob die session mit einem namen aus der db gesetzt ist. was kann denn daran gefährlich werden? o_O

grüße
 
Na ja: Zum Beispiel eben das hier diskutierte Abfischen von Session-IDs.

Das funktioniert so: PHP sendet, wenn man PHP-Sessions benutzt, ein Browser-Cookie, das eine Nummer darstellt. Dieses KANN man im Datenstrom an allen Ecken des Internet, an denen die betreffenden Datenpakete vorbeikommen, lesen. Sobald man so ein Cookie findet, kann man sich - ein bißchen Ahnung vorausgesetzt - seinen Browser so manipulieren, daß er eben dieses Cookie benutzt, wenn man eine Verbindung mit dem betreffenden Server aufbauen möchte.

Schwups - ist man auf dem Server, wenn der genau so funktioniert, wie Du es hier beschreibst, als jener user angemeldet, aus dessen Datenstrom man das Cookie gelesen hat.

Um dem eins draufzusetzen, bauen manche PHP-Freizeit-Bastler (wozu leider auch einige ältere viel benutzte PHP-Projekte gehören) ihre Scripte so, daß die Session-ID in der URL übertragen wird. Und dazu passend kümmern sich die Besucher jener Server einen kalten Kehricht darum, daß ihr Browser diese URLs beim Seitenwechsel immer als "Referrer" mit überträgt. Dadurch kann man als x-beliebiger Serverbetreiber ständig irgendwelche Session-IDs einsammeln.

Der Test auf gleich bleibende IP-Adresse schränkt diese Mißbrauchs-Möglichkeit ein.
 
Der Test auf gleich bleibende IP-Adresse schränkt diese Mißbrauchs-Möglichkeit ein.

kleine Spritze :p

@BasicAvid
Also ich sehe den Sinn und den Zweck noch nicht ganz darinne ...
Welcher Provider bzw. Web Hoster, oder Programmiere proggt php so das ein user meherer IP's beim Zugriff haben könnte. Verstehe deinen Grundgedanken das dieses für einen Anwender Nervig ist,a ber wenn ich das richtig verstanden habe hast du das mit Tool's welche das auch von einem Clientrechner durchführen können auch. Jetzt die Frage "Wo hört das auf und wo fängt es an??"

@PapaJanus
Es geht darum Möglichst viel Sicherheit in den Login zu bringen, so dass ein "Spitzbub" mehr Zeit ("relativ") verbringen müsste ungewollt Zugriff zu erhalten.
Bzw. kein Zugriff erlangen kann!
Problem ist mit Tools kannst du die Cookies ändern, also die nummer und die Session() wird dann Serverseitig erstellt.... ohne Session und Cookie kein Zugriff... Genauso klickst du den Browser oben rechts zu, ist die Session weg und auch der Zugang... sonst könnte man ne geraume Zeit später einfach wieder uff die Seite.... ohne Login... X(

Mmhhh... löscht sich der Cookie auch... denke nicht?! Ist das schlimm? ?(
 
Zu den letzten beiden Gedanken: Es gibt ja immer sowohl serverseitig als auch clientseitig die Möglichkeit, Cookie-Lebzeiten zu beenden.

Wenn man am Browser einstellt, daß DER das Cookie vergessen soll, wenn man ihn schließt, heißt das eben noch lange nicht, daß das Cookie auf dem Server verschwunden ist. Und solange der das Ding aufhebt (standardmäßig steht da bei PHP wohl sowas wie eine Stunde, wenn ich das richtig in Erinnerung habe), kann es dort auch mißbraucht werden - WENN man seine PHP-Anwendungen nicht dagegen schützt.

Normalerweise MÖCHTE man serverseitig eine gewisse Reserve-Lebzeit, weil es - wei hier im Hackerboard zum Beispiel recht oft - passieren kann, daß man recht lange auf einer Seite wie dem Schreiben eines Beitrags verweilt, und es einen sehr schlechten Eindruck macht, wenn man dann immer schon nach nur ner Viertelstunde schreiben und nebenbei recherchieren gleich wieder rausgeschmissen ist und dann zum Beispiel bei einer Kombination aus nicht sehr guten Browser und nicht sehr guter Weboberfläche der gesamte geschriebene Beitrag im Jenseits gelandet ist.

Jedenfalls ist das Thema ein durchaus interessantes...
 
Wie ist das nun mit den rotierenden IP-Adressen bei ISPs?
Kann mir jemand was Konkretes dazu sagen, ob es in Realität tatsächlich vorkommt, dass normale Benutzer während einer Session ihre IP ändern? Am besten mit vertrauenswürdigen Quellen!

Ich würde nämlich auch gerne in meine Webapplikationen diesen IP-Schutz einbauen.

Wenn das nur auftritt, wenn der Benutzer über Spezialtools surft, ist mir das egal, aber wenn AOL oder sonst jemand diese Praxis betreibt, kann man das Konzept, die Session bei unpassender IP zu verwerfen, ja nicht wirklich einbauen.

Bitte um Aufklärung,

mfg, metax.
 
Mmmmhh....
werde mich mal rann setzen und was proggen...

Schmeiße das dann auf den Markt und ihr dürft dann alle mekkern und ergänzen...
Ziel sollte es dann sein ein sicheres Konzept zu erreichen...

Oder, als Frage Vorweg... hat schon jemand eine Login Basis???

Wäre für mich von großem Interesse da was zu entwickeln.
Ich hoffe ich stehe nicht alleine auf weiter Flur...

<------------------------------------------------------------------------>
Edit:
So habe jetzt mal einen Login gestrickt...
Also der Benutzer kann sich anmelden und es wird bei richtiger Eingabe eine Session angelegt.
Die Eingabe wird 2 mal (macht das Sinn) geprüft
- addslashes
- my_sql_real_escape_string

Das Passwort ist noch nicht in MD5 gespeichert, also im Klartext in der DB...

Die connect.inc.php ist die Verbindung <-- ist wohl selbst erklärend

die user.sql ist wie folgt, kann erweitert werden wenn es wichtig ist!
Table Name : Login
CREATE TABLE users (
ID TINYINT AUTO_INCREMENT PRIMARY KEY,
Name VARCHAR(20),
Password CHAR(32),
Email VARCHAR(60)
);(

So nun die index.php
Vorweg bleibt fair!
Ist die Sotware noch so klein, geht immer noch ein Bug hinein =)

Über alle Anregungen, Anmerkungen, Ergänzungen und Kritiken in Sachlicher und fairer Art würde ich mich sehr freuen!
Wäre super hier ein Adequaten Login Bereich zu erstellen, welcher ein hohes Maß an Sicherheit bieten würde... Stand Today...

PHP:
<?php
if(isset($_POST['Go']) &&  $_POST['userpass'] != "" && $_POST['username'] != "")
      {
         //Strings von Tags beseitigen  --> %_,<>';"
         $clean_pass = addslashes($_POST['userpass']);
         $clean_name = addslashes($_POST['username']);

         echo "<b>Name:</b>  ";
         echo  $clean_name;
         echo "<br>  ";
         echo "<b>Pass:</b>   ";
         echo  $clean_pass;
         echo "<br> ";

         if(isset($_POST['Go']) && $clean_pass != $userpass  or $clean_name!= $username)
         {
          // nix machen
          echo  "SQL Fehler";
         }else{

         include "connect.inc.php";  // die Konfigurationsdateien Connect lesen und Verbindung herstellen

         $clean_name = mysql_real_escape_string($clean_name);
         $clean_pass = mysql_real_escape_string($clean_pass);

         // Ein kleiner Part zur Quellcode Prüfung, um sich die Daten anzeigen zulassen
         echo "<br>";
         echo "<b>clean_name:</b>  ";
         echo  $clean_name;
         echo "<br>";
         echo "<b>clean_pass:</b>  ";
         echo  $clean_pass;
         echo "<br><br>";

         $sql = "SELECT
               	ID, Name, Password FROM
                 users where Name = '$clean_name' and password = '$clean_pass'";

                 $query = mysql_query($sql) OR die(mysql_error());
                 $result=  mysql_fetch_array($query);

                 echo "Select durchgeführt<br>";

                 if($result['Name'] == $clean_name && $result['Password'] == $clean_pass )
         		{
                         $anzahl = 0;   				//anzahl der Login versuche auf 0 zurücksetzen

                         Session_start(); 			// Session starten
                         echo "Session gestartet <br>";

                         $_Session["id"] = $result['ID'];  	// ID in die Session schreiben
                         $_Session_register["id"];       	// bei der Session registrieren
			$_Session["user"] = $result['Name'];    // Name in die Session schreiben
                         $_Session_register["user"];     	// bei der Session registrieren

                         // Ein kleiner Part zur Quellcode Prüfung, um sich die Daten anzeigen zulassen
                         echo "<br>";
                         echo "<b>Session:</b> <br>";
                         echo "S_Id : ";
                         echo $_Session["id"];
                         echo " <br>";
                         echo "S_Name : ";
                         echo $_Session["user"];
                         echo "<br><br>";

                         mysql_close($connect); // Verbindung zur Datenbank beenden

                         echo "Right Paswort";
                         }else{
                         echo "<br>";
                         echo "Bitte überprüfen Sie Ihre Eingabe!";
                         }
              }
         }else{
        		if(isset($_POST['Go']) &&  $_POST['userpass'] != "" || $_POST['username'] != ""){
	         echo "Bitte überprüfen Sie Ihre Eingabe";
	         }else{
	         echo "Bitte melden Sie sich an";
	         }
         }
?>

<html>
<head>
<title>LogIn</title>
</head>
<form  action="<?php $PHP_SELF ?>" method="post">

<body bgcolor="#F5EB80">

<table border="0" cellspacing="0" cellpadding="0">
<tr>
  <td>&nbsp</td>
</tr>
<tr>
  <td><label><font size="2" color="#3E0E04"><strong>Name:</strong></font></td>
</tr>
<tr>
<td></label><input name="username" type="text" id="name" size="15" maxlength="15" style="BORDER-RIGHT: 0px;BORDER-LEFT: 0px ;BORDER-TOP: 0px;BORDER-Bottom: 0px;background-color:#FFFFFF;"></td>
</tr>
<tr>
  <td><label><font size="2" color="#3E0E04"><strong>Passwort:</strong></label></td>
</tr>
<tr>
<td><input name="userpass" type="password" id="userpass" size="15" maxlength="15" style="BORDER-RIGHT: 0px;BORDER-LEFT: 0px ;BORDER-TOP: 0px;BORDER-BOTTOM:0px;background-color:#FFFFFF;"></td>
<td>

 <input type="submit" name="Go" value="Go" style="BORDER-RIGHT: 0px;BORDER-Bottom: 0px; Border-Color:#3E0E04 ; background-color:#F5EB80;font-size:10px; font-color:#3E0E04; id="login" value="Go" style="BORDER-RIGHT: 0px;BORDER-Bottom: 0px; Border-Color:#3E0E04 ; background-color:#F5EB80;font-size:10px; font-color:#3E0E04;">  </td>
</tr>

</table>
</div>

</form>
<a href="pwvergessen.html"><font size="2" color="#3E0E04"><strong><u>Passwort vergessen?</u></strong></a>

</body>
</form>
</html>
 
Original von metax.
Kann mir jemand was Konkretes dazu sagen, ob es in Realität tatsächlich vorkommt, dass normale Benutzer während einer Session ihre IP ändern?

das kann durchaus vorkommen.
nehmen wir z.B. mal folgende Fälle an
  1. jemand hat eine nicht ganz so stabile Internetverbindung und wird disconnected, connected neu (bekommt daher neue IP-Adresse) und will nen Beitrag abschicken --> "bitte neu einloggen" und mühevoll geschriebener Beitrag ist im Nirvana...
  2. jemand hat seinen Router so konfiguriert, dass er nach 5 Minuten Inaktivität disconnected und bei neuen Anfragen automatisch wieder connected.... braucht zum Schreiben eines Beitrags 10 Minuten --> hat also beim Einloggen ne andere IP gehabt als beim Beitrag abschicken
  3. jemand hat den Router auf Dauerverbindung, befindet sich auf deiner Seite und dann kommt die Zwangstrennung, die nunmal 1 mal alle 24h stattfindet... --> neue IP


Ich bastel ja noch immer an nem kleinen eigenen CMS und hab mich dabei dafür entschieden, dem User die Paranoids-Stufe zu überlassen:
  • IP-Bereich überprüfen
  • IP genau überprüfen
  • darf User auf mehreren Rechnern oder in mehreren Browsern gleichzeitig eingeloggt sein oder wird - sowie eine andere Browser-Signatur oder IP anliegt als die letzte - der User ausgeloggt
  • etc.
Nur bedingt durch's Studium kam ich noch nicht weiter zur Umsetzung des Projekts...
 
Hm, damit hast du zweifellos Recht ... *grübel*

Das hieße ja dann, man darf (praktikablerweise) keine Session-IP Zuordnung erzwingen.

Auf der anderen Seite kann so jeder, der eine Session-ID abphischt, damit beliebigen Schabernack treiben, oder wie?
Gefällt mir garnicht. Gibt's dafür eine Lösung?
Wie machen das andere große CMS? (Vermutlich ignorieren die meisten das Problem einfach ...)

mfg, metax.
 
dachte das Interesse ist etwas größer...

Mmmh... ;(

ich warte noch etwas ab, sonst nehme ich den Source und so raus....

Wie gesagt und auch gemeint es galt halt etwas zusammen zu erstellen...

Vielleicht hat jemand ja noch Änderungen bzw... Lücken oder auch fehler!? =)

Wäre trotzdem schön gemeinsam einen sicheren Login zu erstellen und darüber zu Diskutieren...

Greetz
 
Na gut, dann sag ich halt mal was dazu:

I. Zeile 7+8:
Code:
$clean_pass = addslashes($_POST['userpass']);
Wieso machst du das? Wieso muss deine Datenbasis hier escaped werden, nur weil das Format später mit der SQL-Syntax kollidieren könnte? Lass hier lieber alles im Klartext und wende den Filter nur an, wenn du die SQL-Abfrage baust.
Außerdem (wichtig!): Wenn die INI-Option "magic_quotes_gpc" aktiv ist, sind die Eingabedaten bereits escaped. In diesem Fall würdest du die Funktion doppelt anwenden, was zu einer Verfälschung der Datenbasis sorgt.
Mein Tipp: Kein addslashes, sondern bei "magic_quotes_gpc" im Gegenteil noch ein stripslashes. Dann hast du die Daten als puren String. Ist wohl geschmackssache.

II. Zeile 11+14:
Code:
echo  $clean_name;
Damit kann dir jemand leicht HTMl-Code unterschieben.
Lieber:
Code:
echo htmlentities($clean_name);

III. Zeile 17-21:
Code:
if(isset($_POST['Go']) && $clean_pass != $userpass  or $clean_name!= $username)
{
// nix machen
echo  "SQL Fehler";
}
Was soll das ???
(i) isset($_POST['Go']) bereits durch erste If-Bedingung in Zeile 4 gewährleistet
(ii) $userpass, $username nur bei register_globals (deprecated !!!) definiert
(iii) WTF soll das überhaupt?

IV. Zeile 25+26:
Code:
$clean_name = mysql_real_escape_string($clean_name);
Wenn die Variable bereits vorher mit addslashes maskiert wurde, hast du alles doppelt maskiert (dreifach, falls zusätzlich noch magic_quotes_gpc aktiv war :D). Daher: hier unmaskierten String einsetzen. Mir wäre es auch lieber, eine neue Variable zu nehmen, um die Veränderung besser zu Strukturieren.

V. Zeile 31+34:
Siehe II.

VI. Zeile 42:
Code:
$result=  mysql_fetch_array($query);
Wenn du nur den assiziativen Teil des Arrays brauchst, reicht auch ein
Code:
$result =  mysql_fetch_assoc($query);
Außerdem: Du solltest erstmal mit mysql_num_rows() schauen, ob du überhaupt ein Ergebnis kriegst. Sonst kann das fetch bzw. die spätere Abfrage des Arrays nämlich ein Warning erzeugen.
Außerdem ist das Abfragekonzept imho nicht sehr elegant. Frage lieber nur ID und password von der Tabelle ab und vergleiche das Ergbnis mit dem eingegebenen Password. Somit kannst du nämlich besser differenzieren, ob der User denn nicht existiert oder nur das Password nicht stimmt.

VII. Zeile 50:
Code:
Session_start();
wird fehlschlagen, wenn du vorher schon Programmausgaben hattest. Du musst noch ganz am Anfang der Datei (bevor auch nur ein einziges Zeichen ausgegeben wurde) mit ob_start() die Ausgabepufferung aktivieren, wenn du die Session erst so spät starten willst.

VIII. Zeile 54:
Code:
$_Session_register["id"];
Das macht keinen Sinn. Falls du die Funktion session_register() meinst: Die brauchst du nicht. Du kannst einfach die $_SESSION[] Variable befüllen, das wird automatisch registriert.

IX. Zeile 62+65:
Siehe II.

X. Zeile 4+17+77
Die könntest die If-Abfragen etwas mehr optimieren (verschachteln). Du brauchst nicht in jeder Abfrage auf isset($_POST['Go']) zu prüfen.

XI. Allgemein
Du könntest noch nach der Login-Prozedur dafür sorgen, dass die temporären Variablen (z.B. für Password) nach dem Vergleich mittels unset() eliminiert werden, damit sie keiner über irgendwelche Include-Tricks doch noch ausgeben oder sniffen kann.

XII Fazit
Naja, so ganz optimal ist die Routine noch nicht. Du sollest das ganze evtl. noch in sinnvolle Unterfunktionen aufteilen und das ganze etwas robuster und überschaubarer machen, wenn du das System irgenwo integrieren willst. Außerdem solltest du dir mal über das Logout Gedanken machen. Was ist denn z.B: wenn vorher schon eine Session existiert? Lauter Sachen, die noch bedacht werden müssen.
Am Optimalsten wäre es, wenn du die ganze Login-Funktion in eine private statische Methode einer Utility-Klasse einbaust, dann wären die einzelnen Schritte in einer "Blackbox" und außer über die Reflection-Funktionen würde auch ein eingespeistes Schadscript nicht an die Daten kommen.

Das sollte erstmal reichen.

Gruß, metax.

~edit:
Da du gefragt hast, ob schon jemand eine Login-Basis hat:
Du kannst dir hier mal eine Vorabversion meines Login-Systems ansehe, wie es in meinem CMS vorkommen wird.
Könnte allerdings etwas verwirrend sein, weil ich objektorientiert arbeite und das Auth-Modul auch noch Gruppen und Benutzerprofile managt. Außerdem sidn Routinen wie "Passwort generieren" und "Password ändern" implementiert. Natürlich werden einige Funktionen benutzt, die ich in anderen Modulen zur verfügung stelle.
Naja, vielleicht bringt es dir trozdem ein Bisschen was:
http://www.planet-metax.de/hotlink/auth.phps
 
Zurück
Oben