"Mein" Login-System mit PHP, MySQL & Co - ist das "sicher"?

[Boris]

Hi,

ich habe ebenso wie tiger ein soweit tadellos funktionierendes Loginsystem erstellt. Benutzt habe ich PHP4-Sessions, die Zugangsdaten (Log + Pass) sind in einer Datenbank gespeichert. Das Passwort ist zusätzlich mit md5() verschlüsselt.

Rein theoretisch müsste es auch mit abgeschalteten globals funktionieren

Jetzt zur Frage - ich selbst habs nicht geschafft, das System irgendwie zu "umgehen" ... schaut es Euch mal bitte an, seht Ihr in diesem Verfahren ein Sicherheitsproblem?

Das Formular und den HTML-Rest hab ich jetzt einfach mal weggelassen...

Index.php:

PHP-Code:

if ($_POST["submit"])
{
    if ($_POST["username"] && $_POST["passwort"])
    {
        $passwort=$_POST["passwort"];
        $passwort=md5($passwort);
        
        $check = mysql_fetch_array(mysql_query("SELECT user_login FROM user_data WHERE user_login='$username' AND user_pass='$passwort'"));
        if(!empty($check))
        {
            $logged_in=true;
            session_register("logged_in");
            
            $sn=session_name();
            $sid=session_id();
            header("Location: news/index.php?$sn=$sid");
        }
          else
          {
            $error="Der Loginname oder das Passwort waren falsch.<br>Bitte versuchen Sie es noch einmal.";
          }
    }
    else
    {
        $error="Bitte geben Sie den Benutzername und das Passwort ein.";
    }
} 


Nach einem erfolgreichen Login wird in die Session die Variable $logged_in geschrieben. Diese wird nun auf jeder Seite, die geschützt sein soll, so überprüft:

PHP-Code:

if (!$_SESSION['logged_in'])
{
  header("Location: index.php");
} 


Sprich: ist in der Session die Variable vorhanden, wird die Seite dargestellt. Ist sie es nicht, wird das Loginformular gezeigt (index.php).

Nun, was sagt ihr? Sicher oder Sicherheitslecks ohne Ende?

[Toxical]

Ich mach es immer genauso..., das einzige was du noch machen könntest, ist anstatt nur logged_in zu übergeben, den name+pass zu übergeben, und dann bei jedem Seitenaufruf, diese neu mit der Datenbank abzugleichen, falls sich eben während einer Besuchsession des Users etwas an seinen Zugangsdaten ändert.

Steigert natürlich den DB-Traffic enorm...

Aber ich find' es im Prinzip sicher genug so, bin aber kein Security Experte

[mike]

nur bedingt.

vorausgesetzt, du benennst deine übergabevariablen genauso wie die datenbankfelder, oder diese sind mir bekannt, dann ist es relativ einfach via sql-boardmittel dein script auszuhebeln.

gebe ich: %' or user_login like '%' or user_pass like '%

in das feld username ein, hab ich mich schon eingeloggt.

in deinem fall ist es eher unwahrscheinlich, dass jemand deine datenbankfelder errät. hat man aber ein freies script = quellcode, dann ist das durch solch einen befehl relativ einfach sich zugang zu verschaffen - trotz md5.

nochmal einen gegencheck zum übergebenen passwort und dem db-passwort könnte einen zusatzschutz schaffen.


imho ist die sicherste variante, sich einzuloggen, - und daran arbeite ich gerade - ist via db-user.
soll heissen:
jeder user wird als db-user angelegt und ich grante dem user minimale rechte auf die db.

identifikation passiert dann via db-connect. geht diese in ordnung, dann gibt es den user wenn nicht, dann falsches login.
hier dürften solch simple sql-tricks nicht arbeiten.

was haltet ihr davon. hat das schwächen? spricht was dagegen?

lf

[Boris]

Sorry, aber das verstehe ich nicht. Wieso soll ich das Passwort nochmal "gegenchecken"? Das Passwort wird doch mit dem in der Datenbank verglichen, passend zum Usernamen, der eingegeben wurde. Selbst wenn einer den Usernamen WEISS, ohne das Passwort kommt er auch nicht weiter.

Der Username allein wird Dich nicht ins System bringen

Mein System funktioniert doch so, wie Du es vorhast. Existiert der User nicht in der DB, kommt man nicht rein. Existiert er, und das Passwort ist nicht richtig, kommt man nicht rein. Erst wenn beides übereinstimmt, kommt man rein.

Sicherheitshalber hab ich Deine Query mal eingetragen (%' or user_login like '%' or user_pass like '%) - es ging nicht

[mike]

Der Username allein wird Dich nicht ins System bringen

schlimmer noch ich brauch weder username noch passwort!


dein script rettet die variablenübergabe aus dem loginscript.

hier werden die ' gequoted übergeben. das zerbröselt dann den db-string.
ich hatte aus faulheit dein gepostetes script mit dummys gefüttert und die var username direkt im script definiert.

entwarnung also nur, wenn quoting eingeschaltet ist.
das ist aber via magic_quotes_gpc in der php.ini definiert. somit vorher auf den host gucken ob der magic_quotes_gpc =on hat.

Übergabe mit magic_quotes_gpc =on
SELECT user_login FROM user_data WHERE user_login ='%\' or user_login like \'%\' or login_pass like \'%' AND login_pass ='68bd3904233f2eb524f3ca047d9eac04'
geht net.

Böser Sql - String magic_quotes_gpc =off
SELECT user_login FROM user_data WHERE user_login ='%' or user_login like '%' or login_pass like '%' AND login_pass='68bd3904233f2eb524f3ca047d9eac04'
zerbröselt dir dein login.

Mein System funktioniert doch so, wie Du es vorhast. Existiert der User nicht in der DB, kommt man nicht rein. Existiert er, und das Passwort ist nicht richtig, kommt man nicht rein. Erst wenn beides übereinstimmt, kommt man rein.

schon richtig. das machst du mit deinen strikten zuweisungsoperatoren (=) aber:
durch den sql-string overrulst du deine = - zeichen in der query durch 'OR' und es werden alle user egal mit welchen passwörtern ausgegeben.
und ich in den geschützten bereich komm ich in deinem script sobald ich mehr als keinen user gefunden hab.
das ist somit der fall - weil er mir alle user ausgibt.

durch den gegencheck zur übergebenen variable kann ich mir aber nochmal gewissheit schaffen ob auch wirklich nur der user mit dem richtigen passwort reingekommen ist.
is aber eben nur im speziellen fall notwendig, wenn der user ausgehebelt wurde.


lf

p.s. haben wir irgendwo aktualisierungsprobleme mit dem tp?
hatte immer noch den letzten eintrag vom 9:35 oder so in der übersicht
- und JA ich hab reloaded

[Boris]

Original geschrieben von Longfang

Übergabe mit magic_quotes_gpc =on
SELECT user_login FROM user_data WHERE user_login ='%\' or user_login like \'%\' or login_pass like \'%' AND login_pass ='68bd3904233f2eb524f3ca047d9eac04'
geht net.

Böser Sql - String magic_quotes_gpc =off
SELECT user_login FROM user_data WHERE user_login ='%' or user_login like '%' or login_pass like '%' AND login_pass='68bd3904233f2eb524f3ca047d9eac04'
zerbröselt dir dein login.

Nun, magic_quotes sind eingeschaltet. Und selbst wenn nicht, dann brauche ich doch nur ein "addslashes()" hinzufügen und das Problem ist gegessen, oder?

[mike]

Und selbst wenn nicht, dann brauche ich doch nur ein "addslashes()"

den zufall zur methode machen

aber ansich ja, hast recht.

anderer ansatz:

PHP-Code:

mysql_fetch_array(mysql_query("SELECT user_pass FROM user_data WHERE user_login='$username' AND user_pass='$passwort'"));
       "));
       
if($check[0]==$passwort)
.... login
else
.... baba 


? was sagst dazu ?

lf

[Boris]

Ja, das wäre auch eine Lösung

Hmm, wir könnten doch "das" Loginsystem überhaupt entwickeln und es dem TP als Script überreichen

[mike]

gibts doch schon eine pear-klasse dafür.
die wird quasi freihaus mit jeder php-installation mitgeliefert.

aber warum net.... ist doch eh schon fast fertig, oder?


lf

[Boris]

"pear-klasse" ... äh, das sagt mir jetzt nix ... kannst Du mir das näher erläutern?

Das schöne an dem Teil ist doch, dass es "selbst" erstellt ist und nix vorgefertigtes ist.

[mike]

pear is eine super sache.

pear.php.net

da haben sich entwickler zusammengesetzt und bauen php-standardcode um das radl net immer neu zu erfinden.

main-parts:
db-abstraktion, die ich persönlich schon nutze
html-klassen von tabellengenerator bis formgenerator und menüklasse
mail-klasse für die mail bis mime-mail funktionalität
und wie gesagt auch eine klasse die das login übernimmt.

uvm.

wenn man es schon net verwendet kann man sich immer wieder die eine oder andere inspiration holen.

Das schöne an dem Teil ist doch, dass es "selbst" erstellt ist und nix vorgefertigtes ist.

totaly ack.

lf

[TobiasKa]

da hat vorhin jemand was von abgeschalteten globals gesagt!
gibts die wohl bald net mehr????

HILFE, dann wär mein ganzes CMS im ARSCH

[SMURF]

hi,

wäre schon besser wenn du dich langsam daran gewöhnen würdest auf globals zu verzichten. Die meisten Provider haben glaube ich register globals noch auf on gesetzt, um zahlreichen Beschwerdemails vorzubeugen

solltest du Zugriff auf die php.ini haben kannst du die Einstellungen ohnehin vornehmen wie es dir passt. Aber allein aus Sicherheitsgründe ist es ratsam register globals auf off zu setzen.

Gruß
SMURF

[mike]

ich arbeite mittlerweile auch mit den superglobals.
glaubt man gar net, wie übersichtlich dann so ein script werden kann...

ich find den schritt wichtig und gut.

lf

[TobiasKa]

Superglobals???