nicht angemeldet
Übergabe der Session ID???
Hallo,
Ich bin gerade dabei einen kleinen Passwortschutz in PHP und Sessions zu programmieren. Das ist mit meinen rudimentären Kenntnissen ein recht grosses problem, und ich habe schon einige Seiten durchgelesen, aber ich bin glaube ich einfach zu dumm dazu.
Hier die Quelltexte:
------------------------
Datei 1: "logon.php"
<?php
$usrname = "julian";
$pass = "test"; // Definition Username und Passwort
if($gesendet) {
//Mache die PW-Überprüfung nur, wenn das Formular gesendet wurde (siehe submit-button)
if($usr == $usrname && $pw == $pass) { //Überprüfe ob PW und Usern OK
session_start(); //Wenn ja erstelle Session
session_register("zugriff");
$zugr = "ok"; // Schreibe in Session die Variable zugriff = ok
//Gib Header aus mit automatischer Weiterleitung:
echo "<html><head><meta http-equiv="refresh" content="0; URL=geheim.php"></head>"; }
else { //Wenn PW Falsch gebe Fehlermeldung aus
echo "<html><head><title>Falsches Passwort!</title>
<script language="JavaScript">alert('Username oder Passwort falsch!');</script></head>"; }
}
else { // Gebe normalen head-bereich aus.
echo "<html><head><title>Es wird ein Passwort benötigt!</title></head>"; } ?>
<BODY>
Username: <input type="text" name="usr"><br>
Passwort: <input type="password" name="pw"><br>
<input type="submit" value="Abschicken" name="gesendet">
</form>
</BODY>
</HTML>
------------------------
Erläuterung Datei 1: Das Script soll bei richtigem Passwort eine Session erstellen und in sie die Variable "$zugriff = ok" schreiben, danach soll sie eine weiterleitung auf die geheim.php machen.
------------------------
Datei 2: geheim.php
<?php
session_start(); //Lade Session ein
$db1 = session_encode();
$db2 = session_decode($db1); //Dekodiere Session
if($zugriff != "ok") {
echo "<html><head><meta http-equiv='refresh' content='0; URL=logon.php'></head></html>";
}
?>
<html><body>NORMALER INHALT DER SEITE, WENN DAS PASSWORT OK IST.</body></html>
------------------------
Erläuterung Datei 2: Erst wird die Session eingeladen, anschliessend dekodiert und getestet, ob in der Session die Variable "$zugriff == ok" ist, wenn nicht, wird auf die logon.php weitergeleitet.
Das Problem: Wird die geheim.php ohne Variable einfach in die Adresszeile eingegeben, wird auf die logon.php weitergeleitet. Wird aber in die adresszeile des Browsers "geheim.php?abc=xyz" oder so, wird der Inhalt der geheim.php (ohne Passwortabfrage) angezeigt.
Kann mir hier jemand helfen???
MFG Julian
-
Hallo Julian,
auch auf die Gafahr, hier Stürme zu enfachen, geb ich Dir den Rat:
Sessions nur dann, wenn der Client temporäre Cookies akzeptiert.
Sonst arbeinte mit Auth: Formular und header() und Err401.Sessions in den "geschützten Seiten" nur starten, wenn der "Session-Cookie" übertragen wurde
if (strlen($HTTP_COOKIE_VARS["PHPSESSID"])==32)
{
session_start();
}Wenn Du register_globals = off stehen hast, dann benutze nicht mehr die Funktionen session_regsiter(), unregister_session(), session_encode(), session_decode().
Schreibe stattdessen die Werte direkt in das Session-Array ($HTTP_SESSION_VARS)
Am Ende jedes Scriptes wird es automatsich gespeichert.
Wenn Du noch Fragen hast, dann melde Dich
Liebe Grüße aus http://www.braunschweig.de
Tom
--
Intelligenz ist die Fähigkeit, aus Fehlern Anderer zu lernen und Mut die, eigene zu machen.-
Hallo Thomas
Sessions nur dann, wenn der Client temporäre Cookies akzeptiert.
Sonst arbeinte mit Auth: Formular und header() und Err401.Das das mit temporären Cookies funktioniert, ist mir bekannt.
Meinst du mit Auth: header() irgendwas mit .htaccess?Sessions in den "geschützten Seiten" nur starten, wenn der "Session-Cookie" übertragen wurde
if (strlen($HTTP_COOKIE_VARS["PHPSESSID"])==32)
{
session_start();
}Gut Danke!
Wenn Du noch Fragen hast, dann melde Dich
Ich hab noch Fragen: Kann mir jemand das mit dem Auth (siehe oben) erklären oder mir sagen, wie ich das ganze ohne cookies machen kann (muss ich bei jedem Link die Session ID Manuell einfügen? Wie geht das).
Warum hasstt du oben "geschützte Seiten" in Anführungszeichen (") gechrieben, ist mein "Passwortschutz" unsicher??Tut mir leid, wenn ich mit meinen rudimentären 0815-Kenntnissen nerven sollte.
Mfg Julian
-
Hallo Julian,
Sessions nur dann, wenn der Client temporäre Cookies akzeptiert.
Sonst arbeinte mit Auth: Formular und header() und Err401.
Das das mit temporären Cookies funktioniert, ist mir bekannt.
Meinst du mit Auth: header() irgendwas mit .htaccess?Es ist ein ähnliches Verfahren, nur dass Du dann in JEDEM Script selber prüfen musst, ob $HTTP_SERVER_VARS["PHP_AUTH_USER"] und $HTTP_SERVER_VARS["PHP_AUTH_PW"] dir gefallen, also zusammenpassen.
PHP unterstützt Sessions auf zwei Arten:
Hinzufügen eines Cookies, der ja bei jedem Seitenaufruf der passenden Domain vom Client an den Server übertragen wird. Wenn Du jetzt session_start() aufrufst, sucht php nach dem Cookie und stellt die Verbindung zur passenden Sessiondatei in session_save_path (standard: /tmp/ würde ich aber verschieben auf /tmp/irgendwas/...) wieder her. Die Variablen $HTTP_SESSION_VARS werden in diesem Moment automatisch aus der Datei wieder hergestellt und beim Ende des Scriptes automatisch wieder dorthin gesichert. Wenn Du also etwas aufbewahren willst, brauchst Du es nur in eine $HTTP_SESSION_VARS["DeinName"] zu schreiben.
Benutze nicht mehr die alten Funktionen session_register() & CO.
Die zweite möglichkeit ist, dass php automatisch in deinem Formular Hidden-Fields und an jeden Link einen Datenbereich anhängt. Dort wird dann die Session-ID untergebracht und kann so von PHP beim Seitenaufruf ___aus einer solchen Sietwe heraus___ wiedergefunden werden. Wenn allerdings eine Deiner Seiten auf eine andere Art aufgerufen wird (Vor- und Zurückbuttons im Browser, Direktaufruf per Adresszeile, Favoriten oder Bookmarks...) dann fehlen diese Angaben ja. Die Seite würde dann ohne Session laufen oder, viel schlimmer, mit einer neuen. Die Methode phne Cookies ist daher ungeeignet für die Praxis.
Du musst sowieso vor jedem session_start() nachschauen, ob ein "Session-Cookie" da ist, mit Ausnahme des ersten session_start() natürlich. Wenn Du Sessions ausschließlicz mit Cookies benutzt, dann reicht es, auf Vorhandensein von $HTTP_COOKIE_VARS[SESSION_NAME] zu prüfen. SESSION_NAME ohne "" in den eckigen Klammern ist eine Konsante, die Du Dir baust und hinter der sich DEIN name für Sessions versteckt. Den stellst Du dann in jedem Script immer erst mit session_name(SESSION_NAME) ein, bevor du session_start() aufrufst. Alles Andere macht PHP dann für Dich.
Sessions in den "geschützten Seiten" nur starten, wenn der "Session-Cookie" übertragen wurde
if (strlen($HTTP_COOKIE_VARS[SESSION_NAME])==32)
{
session_name(SESSION_NAME);
session_start();
}Der Teil mit Auth folgt im nächsten Posting
Liebe Grüße aus http://www.braunschweig.de
Tom
--
Intelligenz ist die Fähigkeit, aus Fehlern Anderer zu lernen und Mut die, eigene zu machen.-
Und weiter gehts...
Hallo Julian,
Wenn Du das Ganze nun nicht mit Cookies machen willst, dann kannst Du auch Basic-Authentikation benutzen.
<?PHP
function authenticate()
{
Header("WWW-authenticate: basic realm="Privater Bereich"");
Header("HTTP/1.0 401 Unauthorized");// hier steht die Fehlerseite, die nach dreimaligem Fehlversuch
// oder bei Abbruch am Client angezeigt wird
echo "Benutzerdaten erforderlich!<br />";
echo "<a href='".$HTTP_SERVER_VARS["PHP_SELF"]."'>zurü</a></br />";exit;
}
//-------------- Hauptprogramm -----------------------------------
include("../~include/comp001.php");
$id=strtolower($PHP_AUTH_USER);if ((($CN == $id) and ($PW == $PHP_AUTH_PW)) or ($REMOTE_ADDR == "192.168.101.25"))
{
echo "<br>Ausgabe wird vorbereitet.<br>";
}
else
{
sleep(1); // als Schutz gegen BruteForceAttacks
authenticate();
}?>
<!-- hier gehts weiter -->
-------------------------------------------------------------------
In der includeteten Datei comp001.php stehen in diesem Beispiel nur zwei Variablen: $CN und $PW.
Die werden mit den durch den Auth-Dialog gelieferten Variablen $HTTP_SERVER_VARS["PHP_AUTH_USER"] und $HTTP_SERVER_VARS["PHP_AUTH_PW"] verglichen.Die Funktion authenticate() veranlasst den Client, ein Anmeldefenster aufzuklappen, wenn das am Client nicht ausgeschaltet ist. Nach Ausfüllen des Fensters sendet der Client die Daten an das Script zurück, von dem aus er dazu aufgefordert wurde. Der Client zählt dabei mit. Er wiederholt den Vorgang maximal 3 mal. Nach erfolglosen drei Mal oder Abbruch zeigt er die Seite an, die ihm mit der Aufforderung übertragen wurde. Da könnte man dann also auch einen Link einbauen, um zurpck zu kommen. (sieh Beispiel)
Bei Auth werden aber nun nicht automatisch Sessiondaten aus einer Datei wiederhergestellt. Das kann man aber selber besorgen. Mit erfolgreicher Authentikikation holt man sich den Namen der entsprechenden Datei aus der User-Kontrolldatei und lädt die Variablen. Die $HTTP_SESSION_VARS sind ja jetzt lehr, sodass man sie dafür benutzen kann (uns sollte)
Schau Dir mal die Funktionen serialize() und unserialize() an und die Funktion register_shutdown_function(). Du musst Dir eine "shutdown_userfunction" schreiben, die die Variablen sichert. Diese Funktion (eigentlich hier besser Interrupt-Prozedur) meldest Du mit register_shutdown_function() bei php an, wenn due die Varis am Scriptanfang wiederhergestellt hast. Dann werden die Variablen automatisch bei Beenden des Scriptes gesichert.
Die Methode mit Auth funktioniert dann fast genauso, wie die mit session_start().
Viel Erfolg
Liebe Grüße aus http://www.braunschweig.de
Tom
--
Intelligenz ist die Fähigkeit, aus Fehlern Anderer zu lernen und Mut die, eigene zu machen. -
Hallo!
Hinzufügen eines Cookies, der ja bei jedem Seitenaufruf der passenden Domain vom Client an den Server übertragen wird. Wenn Du jetzt session_start() aufrufst, sucht php nach dem Cookie und stellt die Verbindung zur passenden Sessiondatei in session_save_path (standard: /tmp/ würde ich aber verschieben auf /tmp/irgendwas/...) wieder her. Die Variablen $HTTP_SESSION_VARS werden in diesem Moment automatisch aus der Datei wieder hergestellt und beim Ende des Scriptes automatisch wieder dorthin gesichert. Wenn Du also etwas aufbewahren willst, brauchst Du es nur in eine $HTTP_SESSION_VARS["DeinName"] zu schreiben.
Benutze nicht mehr die alten Funktionen session_register() & CO.
Und benutze nicht mehr die alten Variablen $HTTP_*_VARS, die werden in absehbarer Zeit nicht mehr unterstützt! Dafür gibt es ja die neuen superglobals $_*, die auch in Funktionen... zur Verfügung stehen, die nur in alten PHP-Versionen nicht funktionieren.
Die zweite möglichkeit ist, dass php automatisch in deinem Formular Hidden-Fields und an jeden Link einen Datenbereich anhängt. Dort wird dann die Session-ID untergebracht und kann so von PHP beim Seitenaufruf ___aus einer solchen Sietwe heraus___ wiedergefunden werden. Wenn allerdings eine Deiner Seiten auf eine andere Art aufgerufen wird (
Vor- und Zurückbuttons im Browser,bei mir geht das?!
Direktaufruf per Adresszeile,
das geht auch nur so lange mit Session-Cockies wie Du im selben Browserfenster innerhalb vor dem Timeout was manuelle eingibst. Wenn sowas gemacht wird ist IMHO etwas an der Internetseite falsch!
Favoriten oder Bookmarks...) dann fehlen diese Angaben ja.
genauso wie der Cockie nicht mehr erxistiert.
Die Seite würde dann ohne Session laufen oder, viel schlimmer, mit einer neuen. Die Methode phne Cockies ist daher ungeeignet für die Praxis.
Sehe ich genau anders. Ich finde den Fall-Back Mechanismus von PHP perfekt. Man muß nur sicherstellen das die Seite auch ohne Cockies wirklich funktioniert. Aber trans-sid ist dermaßen flexibel, man lkann die Session_ID sogar automatisiert in Javascript einbauen... Ich finde eine Lösung die Cookies vorschreibt ist oftmals nicht wirklich praxistauglich, kommt aber auf die Anwendung an.
Du musst sowieso vor jedem session_start() nachschauen, ob ein "Session-Cookie" da ist, mit Ausnahme des ersten session_start() natürlich. Wenn Du Sessions ausschließlicz mit Cookies benutzt, dann reicht es, auf Vorhandensein von $HTTP_COOKIE_VARS[SESSION_NAME] zu prüfen. SESSION_NAME ohne "" in den eckigen Klammern ist eine Konsante, die Du Dir baust und hinter der sich DEIN name für Sessions versteckt. Den stellst Du dann in jedem Script immer erst mit session_name(SESSION_NAME) ein, bevor du session_start() aufrufst. Alles Andere macht PHP dann für Dich.
Und wofür?
if (strlen($HTTP_COOKIE_VARS[SESSION_NAME])==32)
da reicht doch auch if($_SESSION), oder?
{
session_name(SESSION_NAME);das brauchst Du im Prinzip auch nicht, für diese Prüfung reicht IMHO
if($_SESSION){
session_start();
}oder steht $_SESSION erst nach session_start() zur Verfügung? Aber die Prüfung bringt IMHO eh nicht viel, da man so sehr leicht an eine Session kommt.
Grüße
andreasPS: wenn Du den Namen brauchst nimm doch einfach session_name(), das gibt den aktuellen Namen zurück, also normalerweise PHPSESSID.
-
Hi,
ich frage mich, warum Andreas nicht gleich geantwortet hat. Könnt Ihr mir das sagen? In so ein paar Zeilen kann man auch nicht auf alle seine Einwände eingehen. Dafür braucht es eine Doku von ca. 150 Seiten. Die ist ja hoffentlich bald fertig.
oder steht $_SESSION erst nach session_start() zur Verfügung? Aber die Prüfung bringt IMHO eh nicht viel, da man so sehr leicht an eine Session kommt.
@ Andreas: Nun bring die Leute hier nicht durcheinander!
PS: wenn Du den Namen brauchst nimm doch einfach session_name(), das gibt den aktuellen Namen zurück, also normalerweise PHPSESSID.
Liebe Grüße aus http://www.braunschweig.de
@ Andreas: Auch der letzte Satz sollte besser gelöscht werden.
Nochmal für Julian:
Das Array mit den Sessionvariablen, dass entweder $HTTP_SESSION_VARS oder in der neuesten PHP-Version (die dazwischen liefen nicht sauber) heißt, steht selbstverständlich erst nach dem Einschalten des Session-Mechainsmus zur Verfügung. Wenn man den nun mit session_start() startet, und nicht automatisch durch Änderung der Voreinstellung in der php.ini, dann werden die gespeicherten Variablen aus der Session-Datei im tmp-Verzeichnis eben genau in diesem Moment zurückgeholt. Vorher sind sie nicht zur Verfügung.Um nun zu wissen, ob eine Atuhentifizierung des Clients via Session vorliegt, muss man erst nach dem Vorhandensein der Sessionnummer fragen. Dafür wird der Sessionname benötigt. Der Standardname PHPSESSID ist ebenfalls in der php.ini eingestellt, kann aber durch session_name(ANDERER_NAME) überschrieben werden. ANDERER_NAME sollte man sich als Konstante deklarieren. Alternativ kann man auch in der php.ini oder in den Virtual Hosts oder in einer .htaccess den Namen ändern. Unter diesem Namen sucht PHP dann die Variable mit der Länge von 32Byte (md5-codiert) in den Session-Cookies, den Get-Variablen und den Post-Variablen.
Da Blättern mit dem Vor- und Zurückbutton beim Client häufiger vorkommt, und dabei auch die VOR der Authentifizierung übertragenen Seiten angewählt werden könnten, sollte man auf die Authentifizierung über GET und POST verzichten und dann lieber auf Cookies setzen.
Tom
--
Intelligenz ist die Fähigkeit, aus Fehlern Anderer zu lernen und Mut die, eigene zu machen.-
Hallo!
ich frage mich, warum Andreas nicht gleich geantwortet hat. Könnt Ihr mir das sagen? In so ein paar Zeilen kann man auch nicht auf alle seine Einwände eingehen. Dafür braucht es eine Doku von ca. 150 Seiten. Die ist ja hoffentlich bald fertig.
Sorry, aber ich frage mich manchmal auch wie man aus der Sache so eine Wissenschaft machen kann!
oder steht $_SESSION erst nach session_start() zur Verfügung? Aber die Prüfung bringt IMHO eh nicht viel, da man so sehr leicht an eine Session kommt.
@ Andreas: Nun bring die Leute hier nicht durcheinander!
sorry, kam daher das ich so eine Authentifizierung immer etwas anders implementiere, mir geht es weniger um eine Überprüfung ob Session vorhanden, mehr darum die Zusgangdaten in der Session jedesmal zu prüfen. Ich speicher bei erfolgreichem löogin die ZTugangdatenm ind er Session und vergleiche dann immer mit Einträgen in DB oder Flat-Files.
PS: wenn Du den Namen brauchst nimm doch einfach session_name(), das gibt den aktuellen Namen zurück, also normalerweise PHPSESSID.
Liebe Grüße aus http://www.braunschweig.de@ Andreas: Auch der letzte Satz sollte besser gelöscht werden.
warum?
Das Array mit den Sessionvariablen, dass entweder $HTTP_SESSION_VARS oder in der neuesten PHP-Version (die dazwischen liefen nicht sauber) heißt, steht selbstverständlich erst nach dem Einschalten des Session-Mechainsmus zur Verfügung. Wenn man den nun mit session_start() startet, und nicht automatisch durch Änderung der Voreinstellung in der php.ini, dann werden die gespeicherten Variablen aus der Session-Datei im tmp-Verzeichnis eben genau in diesem Moment zurückgeholt. Vorher sind sie nicht zur Verfügung.
Um nun zu wissen, ob eine Atuhentifizierung des Clients via Session vorliegt, muss man erst nach dem Vorhandensein der Sessionnummer fragen.
Ich kenne ja nicht Deine komplette authentifizierung, ich wollte nur drauf hinweisen dass eine Prüfung ob der Client einen Cookie mit Namen der Session einen 32 Zeichen langen String sendet nicht wirklich sicher ist. Man sollte mindestens noch pprüfen ob die Session überhaupt auf dem Server vorhanden ist, oder besser noch den Benutzernamen und Passwort in der Session speichern und diese überprüfen, auch wenn das prinzipiell durch eine sehr durchdachte Vergabe der Sessions eigentlich nicht notwendig wäre, aber vielleicht hat man doch nicht an alles gedacht.
Dafür wird der Sessionname benötigt. Der Standardname PHPSESSID ist ebenfalls in der php.ini eingestellt, kann aber durch session_name(ANDERER_NAME) überschrieben werden. ANDERER_NAME sollte man sich als Konstante deklarieren. Alternativ kann man auch in der php.ini oder in den Virtual Hosts oder in einer .htaccess den Namen ändern.
(wenn man die Modul-Version installiert hat)
Unter diesem Namen sucht PHP dann die Variable mit der Länge von 32Byte (md5-codiert) in den Session-Cookies, den Get-Variablen und den Post-Variablen.
(und den Cookie-Variablen, oder?)
Verstehe mich bitte nicht falsch aber ich darf doch wohl noch meine Meinung dazu sagen! Und die Session umzubenennen halte ich auch für Sinnvoll, aber nur aus dem einzigen Grund das die potentiellen Angreifer dann noch eine Unbekannte mehr haben, oder ich PHP komplett verbergen will.
Viele Grüße
Andreas-
Hi!
Unter diesem Namen sucht PHP dann die Variable mit der Länge von 32Byte (md5-codiert) in den Session-Cookies, den Get-Variablen und den Post-Variablen.
(und den Cookie-Variablen, oder?)sorry, hatte ich überlesen ;-)
Grüße
Andreas -
Hallo nochmal,
Ich kenne ja nicht Deine komplette authentifizierung, ich wollte nur drauf hinweisen dass eine Prüfung ob der Client einen Cookie mit Namen der Session einen 32 Zeichen langen String sendet nicht wirklich sicher ist. Man sollte mindestens noch pprüfen ob die Session überhaupt auf dem Server vorhanden ist, oder besser noch den Benutzernamen und Passwort in der Session speichern und diese überprüfen,
Wie soll das denn gehen? Bei Authentifizierung über Sessions und Cookies wird i.d.Regel kein Benutzername übertragen. Wenn Du damit meinst, dass das Verfahren mit error401 und Session kombiniert werden soll, dann wird es wohl gehen. Da aber beide Werte immer noch im Klartext übertragen werden, hat das eigentlich keinen Vorteil, außer höherer Serverlast.
Liebe Grüße aus http://www.braunschweig.de
Tom
--
Intelligenz ist die Fähigkeit, aus Fehlern Anderer zu lernen und Mut die, eigene zu machen.-
Hi!
Wie soll das denn gehen? Bei Authentifizierung über Sessions und Cookies wird i.d.Regel kein Benutzername übertragen.
Und wofür dann die Bezeichnung "Authentifizierung"? Geht es also nicht um einen geschützen Login-Berreich? Wenn man nur prüft ob ein Cookie mit bestimmtem Namen und 32 Zeichen geschickt wird, wozu soll das gut sein? Ich dachte daran man loggt sich in einen privaten Bereich ein, wie auch immer. Und hierfür gibt man dann halt seinen Benutzernamen und Passwort in irgendein Forumlar ein. Ob ich das ganze jetzt mit .htaccess, mit der PHP basic auth. oder mit Sessions mache ist ja eigentlich egal. Die verschiedenen Varianten bieten halt verschiedene Vor- und Nachteile, was man wofür einsetzt kommt auf die Anwendung und auf die Gegebenheiten(PHP-Modul?...) an.
Wenn Du damit meinst, dass das Verfahren mit error401 und Session kombiniert werden soll, dann wird es wohl gehen.
Das ist ja unnötig, denn bei der basic-Authentifizierung braucht man ja gerade _keine_ Session, da der Browser Benutzernamen und Kennwort jedesmal mitsendet. Der Server prüft das dann halt bei jedem Request. Dieses Verfahren ist schön und gut, nur leider steht mir z.B. die Modul-Verison bei weitem nicht überall zur Vefügung, eher selten. Ich meine dagegen, man gibt die Zugangsaden in ein HTML-Formula rein, überträgt die einmal per POST, validiert die Daten und vergibt ggfs. eine SessionID _und_ speichert die Zugangsdaten in der Session, nur zur Sicherheit, falls man vielleicht doch noch eine Sicherheitslücke hat.Dieses Verfahren finde ich persönlich sicherer als basic oder digest Authentifizierung, denn wenn man danach nur noch die SessionID überträgt kann es mit gleicher Wahrscheinlichkeit dazu kommen das sich jemand Zugang verschafft wie bei den HTTP-Authentifizierungs-Verfahren, aber der Unterschied, bei den der SessionID hat der Einbrecher nur einmaligen Zugriff, also solange die Session läuft, was sicher schon schlimm genug ist, aber bei HTTP Authentifizierung hätte der Angreifer die Zugangsdaten und könnte sich damit immer wieder anmelden wie er lustig ist.
Das ich jedesmal in der Session die Zugangsdaten prüfe habe ich mir überlegt, da so auch ausgeschlossen wird, das jemand - wie auch immer - an eine gültige Session ID gekommen ist, den dan muss er immer noch in dieser Session gültige Zugangsdaten haben, wenn dem nicht so ist wird die Session sofort gekillt. Das hat sich bisher gut bewährt. Wenn ich dagegen nur auf Vorhandensein der Session prüfe (was Du in Deinem Beispiel noch nicht mal tust!), dann müßte ich 100%ig sicherstellen, dass man nicht mit irgendwelchen Tricks doch an eine Session auf meinem Server kommt, auch wenn ich annehme das das nicht möglich ist bis ich dennoch relativ sicher das es mittel und Wege dazu gibt. Wenn Du dagegen nur prüfst ob die Session formal richtig ist, dann ist das doch wirklich einfach durch einen kleinen zusätzlichen Header an eine Session zu kommen. Klar, das alles muß man erstmal wissen, aber ich denke viele unerfahrene Programmierer machen oft dieselben Fehler, so dass Profis wissen wo sie gucken müssen, außerdem ist es meiner Meinung nach erst ein gutes Sicherheits-Konzept, wenn der Angreifer trotz Kenntnis der der Interna nicht in den geschützen Bereich gelangen kann, da es duch gute Programmierung (statistisch so gut wie) unmöglich gemacht wird.Da aber beide Werte immer noch im Klartext übertragen werden, hat das eigentlich keinen Vorteil, außer höherer Serverlast.
Das hatte ich auch nicht vor, aber die so erzeugte Serverlast ist denke ich vernachlässigbar!
Viele Grüße
Andreas
-
-
-
-
-
-
-