Standard-Sicherheit?

[Azador]

Ich würde gerne mal Eure Meinung zum Thema Sicherheit bei Login-Skripten bzw. Websites mit Loginbereichen hören.

Ich mach PHP Hobby-mäßig in Selbstversuchen und beginne jetzt auch mit diversen "gesicherten Breichen" auf einer Homepage.
Könnte mal jemand bewerten wie sicher meine Maßnahmen sind und wie sie vielleicht sein sollten?

Es gibt eine automatische Registrierung, mit generiertem Passwort, das per Mail an den User geschickt wird und nach Anmeldung geändert werden kann. Bevor der Benutzer sich erfolgreich anmelden kann muss er von mir direkt in der Datenbank aktiviert werden (ein Feld auf true gesetzt werden).
Die Anmeldung erfolgt über ein Formular auf der Page. Nach dem Klick auf "Login" werden eingebene Daten mit der MySQL DB abgeglichen (das Passwort ist md5 verschlüsselt gespeichert) und im Erfolgsfall ein Cookie mit Namen und (verschlüsseltem) Passwort gesetzt, der nach einer Stunde abläuft. Bei jedem neuen Seitenaufruf, wird dann getestet, ob der Cookie noch vorhanden ist und ob die Passwörter (verschlüsselt) übereinstimmen. Wenn ja, wird der Cookie neu gesetzt, wenn nicht, gelöscht.

Das alles geschieht in einer zentralen PHP-Datei, die dann wenn alles erfolgreich war eine zentrale Variable (Bsp: $test) gleich true setzt oder eben false. Diese Datei "includiert" dann alles andere, die menue.php für das Menü links, die content.php für den Inhalt in der Mitte usw.

Ich arbeite überall mit $_COOKIE[...] und $_REQUEST[...] Variablen, allerdings sind die globals noch nicht entsprechend angepasst (also "on" gestellt, für maximale Sicherheit, oder?). Kann ich das selber machen oder muss das mein Provider machen?

Die SQL Zugangsdaten liegen in einem htaccess geschützten Ordner.


Die einzige Sicherheitslücke, die mir jetzt einfallen würden, ist ein absichtliches Setzen der $test-Variable (deren Name jedoch erstmal rausgefunden werden müsste) mittels zum beispiel dem Aufruf der Seite in der Browserzeile: www.mypage.de/zentral.php?test=1
Dafür muss ich die globals noch umstellen (lassen?).



Was fehlt da noch zu einem vernünftigen Sicherheitskonzept, ist das alles Blödsinn wie ich das gemacht habe? Hackt sich der Durchschnittshacker da in 5 Minuten rein? Wie seht Ihr das? Wie macht Ihr das? Was für generelle Möglichkeiten kann man noch ergänzend anwenden?

 

[ABC]

Kann dir noch ein Badlogin empfehlen.

Das heist, der Hacker wird versuchen deine Seite mit bekannten Passwortlisten zu attackieren. Frage also nicht mit jedem Seitenabruf nach dem Cookie. Und wenn das Passwort sagen wir 15 mal die Stunde falsch abgegeben wird, sperrst du den account eine Stunde lang. Informierst dann per Mail den Eigentümer. "Ihr Account ist 60 Minuten lang gesperrt, da ihr Passwort 15 mal falsch angegeben wurde." per Mail.

Dem Hacker sagst du aber Passwort falsch.

Ausserdem speicher in das Cookie eintimestamp. Und zwar genau den, an dem das Cookie angelegt wurde. Der Hacker muss dann nicht nur das PW den Nick sondern auch noch den Zeitstempel (genaue Zeit) an dem das Cookie angelegt wurde haben, um einen Angriff zu starten. Das kann nicht mal der wissen, der das Passwort kennt, nur der der das echte Cookie hat. Alle Timestamps zu kontrollieren ist schwachsinn. Ebenfalss als letzte Maßnahme legst du einen per zufall per md5 verschlüsseltes 32Bit Code key, welches ebenfalss das Cookie authentifizieren soll.

Nun muss der Hacker Nick, PW, 32Bitkey, und Timestamp erkennen. Da bringt ihm nur eins, das Cookie zu klauen.

Im Login richtest du dir ein schönes SSL ein. Zum Beispiel Thwate und öffnest die Otpion Tarn und Hackserfer ausschliessen. Dann muss der Hacker schon einen unbekannten Boot nutzen, und kann nicht Anonym per Tool steuern. Hab mich schon in meiner Hackeraktivität dessen überzeugt. Das Sicherheitszwetifikat erkennt die ganzen Zugriffe an Hand der Hilfs oder Bootserver sehr zuverlässig, und schliesst jegeliche Anfrage dessen aus.

und des weiteren kontrolliere jedes Request, und las immer nur da zu was gebraucht wird. Damit schliesst du einen Angriff auf eine Interfaceschnittstelle vollkommen aus. Bleibt nur noch der DDOS angriff oder die durch die Schleicher, die bekannte Sicherheitslücken nutzen.

 

[ABC]

Nachtragend zum Thema

Es gibt noch phising und hundert andere Möglichkeiten. Das sind alles Dinge die du nicht verhindern kannst. Aber wie du es einem Hacker schwerer machst:

Übermittel nie was fakt ist. Schreib nicht Fehlermeldungen wie "Das Passwort ist falsch oder Nickname existiert nicht". Damit gibst du dem Hacker zu erkennen, was er falsch macht. Schreib lieber: "Zugangsdaten sind nicht korrekt"

Schreib nicht "Ihr Browser übergibt ein falsches Cookie". Sonder eher "Es ist ein Fehler aufgetreten".

Wichtig ist ein sauberes Protokoll. Jede Anfrage zu speichern! Dem Hacker Fallen stellen, geht auch ganz gut. Das heist, der Hacker soll nicht mercken, dass dein System ihm auf die Schliche gekommen ist.

Du kannst ein Hack nie verhindern. Aber du kannst einen Hacker gegenhacken. Aufspühren nennt sich das. Zumbeipiel legst du ihm ein Cookie zu, welches er als Login Cookie oder Werbecookie versteht. Liest du das später auf deiner Seite bei einem User aus, weist du was der böse Bubbi getan hatte.

Es gibt viele Möglichkeiten. Über Bilder und htaccess zum Beispiel zu ürpfen ob es sich um eine Normale oder nicht erlaubte Anfrage handelt. Die meisten sind einfach nur Fehler. Die anderen eben irgend welche Versuche aus langeweile. Fakt ist, ein Hacker wird deine Seite nicht mit einem Versuch hacken, sondern er wird auf ihr Lücken intensiv suchen. Das erledigen schon zahlreiche Tools. Schau dir die Tools einfach mal an, dann weist du wie diese vorgehen. Und wenn du selbiges oder verblüffend ähnliches Verhalten protokollierst, kannst du dir sehr sicher gehen.

Nun ist es nicht gefragt, den Hacker zu informieren "Hallo hab die entdeckt", sondern alles mögliche Finden, um den Hacker auffindig zu machen. Das erste wäre eine E-Mail an den Server, über den der Hacker unerlaubt stöbert. Schon hast du die größere Waffe die echten IP Daten des Hackers zu bekommen. Und weiteres Material auf dem Server zu finden.

Nja bei mir hat es sich schon für 2 ausgehackt. Aber das ist nur eine Nadel im Heuhaufen. Hab dir ganz gemein per Cookie überführt. Darüber habe ich den Bot Server (Anfrage IP) aussindig gemacht. Geschaut welche Domains drüber laufen. Mich mit dem Admin des Servers in Verbindung gesetzt. Der war forh, und hat die Infizierung endeckt, und dann bin ich mit meinem und dessen Protokoll ab zu den grünis.

Die wichtigste Sache!! -> Erlaube auf deiner Webseite nie, die E-Mailadresse zu ändern, oder behalte alle prtotkolliert die geändert wurden. Das sollte klar sein!

 

[glowhand]

Ich arbeite überall mit $_COOKIE[...] und $_REQUEST[...] Variablen, allerdings sind die globals noch nicht entsprechend angepasst (also "on" gestellt, für maximale Sicherheit, oder?). Kann ich das selber machen oder muss das mein Provider machen?

du kannst auch $_COOKIE und $_REQUEST nutzen, wenn register globals nicht on ist. und es sollte "off" sein. außerdem ist es ratsam, $_POST und $_GET noch einmal zu unterscheiden.

Die einzige Sicherheitslücke, die mir jetzt einfallen würden, ist ein absichtliches Setzen der $test-Variable (deren Name jedoch erstmal rausgefunden werden müsste) mittels zum beispiel dem Aufruf der Seite in der Browserzeile: www.mypage.de/zentral.php?test=1
Dafür muss ich die globals noch umstellen (lassen?).

das wäre mir schon wieder zu unsicher.
es kann ja nur 3 möglichkeiten geben:
a) die variable $test wird im quelltext definiert, sodass sie die $_GET['test'] überschreiben würde -> kein Problem
b) die variable $test wird mit $_POST und $_GET an die seite übertragen > sie ist einsehbar, darf nicht sein -> zu unsicher
c) die datei zentral.php wird normalerweise von einer anderen datei eingelesen. wird die zentral.php allein geöffnet, wird die variable $test nicht noch einmal definiert und wir haben den salat. um an so etwas überhaupt nicht denken zu müssen, definiere ich in der datei, die eine andere einliest eine konstante. in den eingelesenen dateien wird dann erst überprüft ob die konstante existiert.

Was fehlt da noch zu einem vernünftigen Sicherheitskonzept, ist das alles Blödsinn wie ich das gemacht habe? Hackt sich der Durchschnittshacker da in 5 Minuten rein? Wie seht Ihr das? Wie macht Ihr das? Was für generelle Möglichkeiten kann man noch ergänzend anwenden?

ist kein blödsinn. würde ein durchschnitthacker sich da in 5 minuten einhacken können, wären 90 % aller internetseiten futsch.

ich würde beim login noch ein captcha oder eine loginsperre nach x falschen versuchen für x minuten einbauen.

 

[ABC]

Nö brauchst den Provider doch nicht dazu. Lass doch den Server listen was so in $_REQUEST $_GET $_POST mitgelifert wird.

ne foreach Schleife reicht dir aus. Nun kannst du sortieren was normal oder gefährlich ist. Cookies beispielweise die auf der HP nichts zu suchen haben oder GET Parameter ausser PHPSID bzw. deren die du brauchst. Alles andere findet sich im schredder unset() wieder.

 

[glowhand]

das passwort würde ich allerdings nicht im cookie speichern, egal ob verschlüsselt oder nicht.

 

[ABC]

das passwort würde ich allerdings nicht im cookie speichern, egal ob verschlüsselt oder nicht.

Doch, denn wie willste festellen, ob es sich um den User handelt? Daher würde ich das verschlüsselte PW (md5()) aus der Datenbank in das Cookie legen.

 

[theHacker]

Doch, denn wie willste festellen, ob es sich um den User handelt? Daher würde ich das verschlüsselte PW (md5()) aus der Datenbank in das Cookie legen.

Ich würde auch das PW im Keks ablegen, is einfacher.

Alternativ kannst du einen zweiten Wert erzeugen und diesen im Keks ablegen, sozusagen ein zweites PW, was nur deine Datenbank und der Keks kennen.

 

[tleilax]

Öhrm, mal als Anregung:

setcookie('id', md5($userid.$nickname.$password));

Und das Query:

SELECT COUNT(*)
FROM user
WHERE MD5(CONCAT(userid, nickname, password)) = $_COOKIE['id']

So wenig Daten wie möglich im Cookie, aber dennoch alles Nötige da.

 

[Teilzeitelf]

Die Variante mit dem Dummy Passwort was dann nur im Cookie abgespeichert wird hat aber noch einen Vorteil, man kann es über einen Cronjob z.B. einmal die Stunde ändern wenn der Benutzer in der Zeit nicht aktiv war.
Also speichern wann der User zum letzten mal aktiv auf der Seite war, wenn der Cronjob aufgerufen wird prüfen ob der User in den letzten X Minuten aktiv war (um zu verhindern das wir ihn kicken). ISt dies nicht der Fall wird das Dummy Passwort rotiert.
Da wäre der Vorteil das das aus dem Cookie geklautes Passwort nur bis zur nächste auto Änderung gültigkeit hat, will er später nochmal rein, geht die Arbeit wieder von vorne los.

 

[ABC]

Ich würde auch das PW im Keks ablegen, is einfacher.

Alternativ kannst du einen zweiten Wert erzeugen und diesen im Keks ablegen, sozusagen ein zweites PW, was nur deine Datenbank und der Keks kennen.

Das ist mal eine sehr gut Idee!

 

[MrToiz]

Ich hab letztens folgendes Session-System entwickelt:

if(isset($_REQUEST['sessionid']))	{
	// Aufbau der Session-ID: md5($id.$timestamp.md5($passwort)).$timestamp.str_pad($id, 5, 0, STR_PAD_LEFT)
	if(preg_match('#^([0-9a-f]{32})(\\d+)(\\d{5})$#U', $_REQUEST['sessionid'], $matches)) {
		list(, $hash, $timestamp, $id)	= $matches;
		// Maximale Session-Gültigkeit: 1 Stunde = 3600 Sekunden
		$timestamp	= intval($timestamp);
		$time		= time();
		if($timestamp >= $time-3600 AND $timestamp <= $time) {
			$result	= mysql_query('SELECT id, passwort FROM benutzer WHERE id='.intval($id));
			if(mysql_num_rows($result)) {
				$data		= mysql_fetch_assoc($result);
				$sessionid	= md5($data['id'].$timestamp.$data['passwort']).$timestamp.str_pad($data['id'], 5, '0', STR_PAD_LEFT);
				if($sessionid == $_REQUEST['sessionid']) {
					define('USER_ID', intval($data['id']));
					define('SESSION_ID', $sessionid);
				}
			}
		}
	}
}
elseif(isset($_POST['benutzername']) AND isset($_POST['passwort'])) {
	$result	= mysql_query('SELECT id, passwort FROM benutzer WHERE benutzername = "'.addslashes($_POST['benutzername']).'" AND passwort = "'.md5($_POST['passwort']).'"');
	if(mysql_num_rows($result)) {
		$data	= mysql_fetch_assoc($result);
		define('USER_ID', intval($data['id']));
		$timestamp	= time();
		define('SESSION_ID', md5($data['id'].$timestamp.$data['passwort']).$timestamp.str_pad($data['id'], 5, '0', STR_PAD_LEFT));
	}
}

if(defined('USER_ID')) {
	echo 'Eingeloggt!';
}
else {
	echo 'Nicht eingeloggt!';
}

Eine Typische Session-ID sieht dabei so aus:
3462f3a0434960953dc634de5352e5c8114750423400002
Session-Hash, bestehend aus Userid (2), Timestamp (1147504234) und Passwort-Hash (PW=test): md5('2'.'1147504234'.md5('test'));
Timestamp des Logins
User-ID (zur Verifizierung)

Vorteile

• Nur der MD5-Hash des Passwortes wird in der DB gespeichert
• Selbst nach erfolgreichem Ausspähen des Cookies (bzw. Abfangen der Session-ID) hat ein Angreifer nicht den MD5-Hash des Passwortes, sondern nur eine maximal eine Stunde gültige Session-ID
• Die Session-IDs müssen nicht in einer Datenbank gepspeichert werden

Nachteile

• Sessions können nicht vorzeitig beendet werden und haben eine fest eingestellte Gültigkeitsdauer (hier eine Stunde)
• Die maximale Userzahl ist fest eingestellt (in diesem Beispiel darf die ID höchstens 5 Stellen haben, folglich dürfen sich nicht mehr als 99.999 Nutzer registrieren), lässt sich aber beliebig erhöhen

Gruß,
Xgame

 

[theHacker]

Nachteile

• Die maximale Userzahl ist fest eingestellt (in diesem Beispiel darf die ID höchstens 5 Stellen haben, folglich dürfen sich nicht mehr als 99.999 Nutzer registrieren), lässt sich aber beliebig erhöhen

Da könntest du z.B. Abhilfe schaffen, indem du die Form der Session-ID etwas änderst:
3462f3a0434960953dc634de5352e5c81147504234012

01 = Länge der nachfolgenden UserID (wird immer zweistellig angegeben, damit auch 10stellige IDs eine Chance haben - alternativ: 0-9a-z-Schema und einstellig)
2 = UserID

 

[MrToiz]

Da könntest du z.B. Abhilfe schaffen, indem du die Form der Session-ID etwas änderst:
3462f3a0434960953dc634de5352e5c81147504234012

01 = Länge der nachfolgenden UserID (wird immer zweistellig angegeben, damit auch 10stellige IDs eine Chance haben - alternativ: 0-9a-z-Schema und einstellig)
2 = UserID

Geht leider nicht, weil der Timestamp ja irgendwann nicht mehr 10 sonder 11 Stellen hat...höchstens $hash.$timestamp.$userid.strlen($userid) also in obigem Beispiel 3462f3a0434960953dc634de5352e5c81147504234201
Dann wird aber das Parsen ein klitzekleines bisschen umständlicher.

Alternativ ginge natürlich auch ein einfaches Trennzeichen, aber das ist ja langweilig
3462f3a0434960953dc634de5352e5c81147504234x2

 

[PatrickB]

Das ist schon ein interessantes Thema.
Da gibts doch auch diese Seiten wo man sich einhacken muss.
Wie z.B. das Passwort rausfinden oder so.

Weiß jemand was ich mein? Da gibts auch verschiedene "Level".

Hat vll jemand den Link.

 

[White]

Das ist schon ein interessantes Thema.
Da gibts doch auch diese Seiten wo man sich einhacken muss.
Wie z.B. das Passwort rausfinden oder so.

Weiß jemand was ich mein? Da gibts auch verschiedene "Level".

Hat vll jemand den Link.

www.hacktheweb.org oder so glaube ich. musste mal googeln

 

[ABC]

if(isset($_REQUEST['sessionid']))	{
	// Aufbau der Session-ID: md5($id.$timestamp.md5($passwort)).$timestamp.str_pad($id, 5, 0, STR_PAD_LEFT)
	if(preg_match('#^([0-9a-f]{32})(\\d+)(\\d{5})$#U', $_REQUEST['sessionid'], $matches)) {
		list(, $hash, $timestamp, $id)	= $matches;
		// Maximale Session-Gültigkeit: 1 Stunde = 3600 Sekunden
		$timestamp	= intval($timestamp);
		$time		= time();
		if($timestamp >= $time-3600 AND $timestamp <= $time) {
			$result	= mysql_query('SELECT id, passwort FROM benutzer WHERE id='.intval($id));
			if(mysql_num_rows($result)) {
				$data		= mysql_fetch_assoc($result);
				$sessionid	= md5($data['id'].$timestamp.$data['passwort']).$timestamp.str_pad($data['id'], 5, '0', STR_PAD_LEFT);
				if($sessionid == $_REQUEST['sessionid']) {
					define('USER_ID', intval($data['id']));
					define('SESSION_ID', $sessionid);
				}
			}
		}
	}
}
elseif(isset($_POST['benutzername']) AND isset($_POST['passwort'])) {
	$result	= mysql_query('SELECT id, passwort FROM benutzer WHERE benutzername = "'.addslashes($_POST['benutzername']).'" AND passwort = "'.md5($_POST['passwort']).'"');
	if(mysql_num_rows($result)) {
		$data	= mysql_fetch_assoc($result);
		define('USER_ID', intval($data['id']));
		$timestamp	= time();
		define('SESSION_ID', md5($data['id'].$timestamp.$data['passwort']).$timestamp.str_pad($data['id'], 5, '0', STR_PAD_LEFT));
	}
}

if(defined('USER_ID')) {
	echo 'Eingeloggt!';
}
else {
	echo 'Nicht eingeloggt!';
}

Hallo

Habe folgende Sicherheitslücken gefunden:

1.) SQL Abfrage wird nicht mir einem @ (Fehlermedlung unterdrückung) quittiert. Im SQL Error kann das Parameter ausgegeben werden.

2.) Die Sessionsid wird leider geloggt und du kannst das nicht verhindern. Beispielweise wenn ein Counter oder Statistiktoolläuft. Die Sessionsid sollte daher durch die eigene IP oder Cookie Identifikation verschlüsselt werden.

Du kennst das bestimmt. Wo kommen ihre Besucher her?
1. https://www.***
2. https://www.***
3. https://www.***?PHPSID=*** (da möchte ich gerne draufklicken)

                if($sessionid == $_REQUEST['sessionid']) { 
                    define('USER_ID', intval($data['id'])); 
                    define('SESSION_ID', $sessionid); 
                }

Game Over!

Sollte anderst sein! Eher so:

                if($sessionid == $_REQUEST['sessionid']) { 
unset($_REQUEST['sessionid']) );
                }

wobei schon vor Session Strat, bzw. damit du Sie übergeben kannst, solltest du prüfen ob das Cookie zu SID passt.

 

[ABC]

Möchte es nochmal für alle herausheben, wie man eine Session sicher verarbeitet.


1. Empfang der Daten:
Dazu gehören unter anderem
- Sessions ID
- Cookies / Sessions und Authentifizierungs Cookies
- bereits laufende Session
- Request (POST und GET)

2. Prüfung der Daten:
Dazu prüft man die Daten auf ihre Gültigkeit, jedoch nocht nicht auf ihre Überinstimmung.
- Stimmt die Syntax der übergebenen Daten?
- Sind die Daten durch ihre Form Gültig?
- Stimmen die Daten mit dem Sessionsmangement über ein?
- Sollten die Daten überhaupt angenommen werden? Läuft nicht eventuell schon eine Seission?

3. Auswertung der Daten.
Hierbei ist es wichtig die Daten per Übereinstimmung zu prüfen.
- Stimmt das Passwort?
- Stimmt der Nickname?
- Ist das Cookie verifiziert?
- Kann die Sessionsid an Hand der Daten übereinstimmen?
- Ist der User eventuell gesperrt oder hat er seinen Account noch nicht bestätig? etc.

4. Enstscheidung und Protokoll
Dazu gehört unter anderem.
- Session Zugriff oder aber Ablehnung!
- Schreiben von Cookies (so darf die ´Session erst beim Seitenwechsel gestartet werden)!
- Eventuell Protokollieren der IP etc. (Keines Falls das Passwort)

5. Vernichtung der Daten
Die Sicherheit zum Schluss!
- Ein Sessionscookie mit PW etc. hat im unset() zu landen!
- POST GET oder REQUEST Passwort soll nach der abarbeitung im unset() landen.
- Noch notwendige Maßnahmen!

 

[Johnson]

Sollte anderst sein! Eher so:

                if($sessionid == $_REQUEST['sessionid']) { 
unset($_REQUEST['sessionid']) );
                }

Geb mir einen vernünftigen Grund, warum ich das Element unsetten sollte, wenn es nur zur Wiedererkennung dient und sonst nicht gebraucht wird (abgesehen vom Coding-Stil)

 

[ABC]

Weil du keine Überprüfung durchführst. Deshalb eben. Du stellst nur einen Vergleich an, der sich böse rechen kann. Das heisst jeder der die SID hat, hat Zugriff auf den Account.

Ich weis ist in PHP auch so Standard, nur frage ich mich dann nach dem Sinn des Vergleichs. Warum du also dann die Sessions ID überhaupt veränderst?

Oder glaubst du dich sicherer, wenn du eine Eigenständig kreierte Sessions ID hast. Wenn es dich beruhigt gebe ich dir da auch Recht!

Nur eben erkenne ich da keinen Sinn drin.

Also mal anders gesagt, sieht man sich so die ganzen Webseiten an. Da kommen zahlreiche Komponenten zusammen. Beispiel weise:
- Template system
- Funktionsbibliothek
- Passwort Dateien

etc. etc.

Wenn du mal mehr oder weniger auf Wirtschaftlichkeit gehen wirst, wirst du dir auch wie jeder großer Coder eine eigene Script Bibliothek ansammeln. Gehe davon aus du hast eine.

Wenn du jetzt eine Website zusammen mischen möchtest, und das ganze soll ziemlich schnell gehen, dann muss jeder Script seinen Sinn erfüllen.

Und ich meine das nicht schlecht, sondern als Verbesserungsvorschlag. Das du Code kannst, sieht man ja, dem lege ich nichts in den Weg. Also bitte net falsch verstehen.

Jedenfalls sagst du dir ich möchte eine Kleine HP bauen. Oder dein Kunde oder sonst wer. Auch wenn Privat ist. Nun hast du ja auf deiner HDD dein Template system oder Sessionssystem liegen. Nun wir kannst du diese Komponenten zusammenwerfen, wenn diese nicht ganz ihren Sinn erfüllen?

Genau das ist mir ins Auge gefallen. Stell dir vor ich wäre ein Kunde der von PHP keine Ahnung hätte. Nun würde ich dich bitten, bau mir doch bitte ein kleinen Login Bereich ein. Wir einigen uns auf einen Preis.

Du beginnst mit deiner Arbeit. Nun baust du dein Sessionmanagement ein, und passt es ggf an. Spätestens jetzt merkst du *shit* der Kunde kann aus anderen technischen Gründen die Sessions ID nicht verändern, da diese von einer anderen Komponente der Website benötigt wird. Nun was macht man dann? Man fängt seinen eigenen Code an um zuschreiben, und anzupassen.

Was ich dir eigentlich sagen wollte. Und das als Hilfe und Rat. Sehe jede Komponente dazu, wozu sie dienen Soll. Wenn du da jetzt Puncto Sicherheit ansprichst, was bei einer solchen Komponente wichtig ist, kannst du net einfach hergehen, und gedanklich auslegen, die Session sid sei sicherer.

Was wäre wenn sich ein Konflikt zwischen anderen Komponenten ergibt, und deine Sessionsbiliotehk daran scheitert.

Deshalb eben, stell dir vor deine Sessionsbiblitohek müsste in jedes System integrierbar sein. Ist natürlich etwas Schwachsinn. Aber man weis nie. Und wenn du jetzt sicher gehen willst, dass deine Session sicher ist, dann musst du jeden möglichen Fall bedenken.

Kleines Beispiel. Du baust mir ein Session ein. Mein Templatesystem schert sich nun aber nicht um die Ersetzung der Variablen die dun nicht durch den unset() gejagt hast.

Was ich damit ausdrücken will. Die Sessionsbibliothek ist in gewisser Hinsicht das A und O bzw. das Herz einer Seite. Wenn du es richtig verstehen möchtest, hat sie nicht anderes zu tun, wie die Session zu verarbeiten. Alle Daten die an diese herausgehen, haben wo anders nichts verloren.

Als Gegenleistung produziert sie Sessionsvariablen. Mehr nicht.

Deshalb. Ein mysql_error oder jeglicher Art ist außerhalb der Programmierphase einfach unsicher. Eine SessionsID die zwar Verglichen wird, nicht aber überprüft ist die Session nicht wert. Usw. Übrigens deine Konstanten sind auch nicht unbedingt notwendig. Den Konstant ist nun mal Konstant, und bleibt Konstant. Die hat so seine vor und Nachteile.


Das was ich hier jetzt geschrieben habe ist nur ein Vorschlag, keines Falls eine Fehlermeldung. Denn deine Session funktioniert einwandfrei. Jedoch meine ich es echt nur gut!

Schau halt allein mal auf dein Code. Welche Variablen / Konstanten mit solch wichtigen Daten produziert werden. U.a. auch das MD5() Passwort und Passwort selbst. Jetzt gehe doch einfach mal den Code neutraler Sicht durch, und frage dich einfach mal, was nach Ablauf dieser Zeilen noch (definiert ist) und ggf. auch wieder ausgegeben werden kann. Fällt dir da was auf.


Wo du jetzt mal nichts für kannst, aber ich kläre mal auf wie Hacker Sessionen knacken:

Eigentlich kann man nicht sagen, dass Sessionen geknackt werden. Den Sie werden nicht wirklich geknackt! Es gibt 2 Arten wie Hacker schnell Zugriff auf eine Session erlangen. Die eine ist die etwas Aufwängiere.

Methode A suchen nach Sicherheitslöchen:
Hierzu wird der Hacker an Hand des Scriptes und er Daten versuchen eine Sicherheitsloch in der Sessionsverwaltung zu finden. Dies geschieht über moderene Tools, die schon etliche leichtsinnige aber weit verbreitete Probleme kennen, und diese schlicht und einfach ausprobieren. Diese Methode ist jedoch kaum praktiziert, da die andere viel schneller und einfacher Funktioniert.

Jedenfalls meldet sich der Hacker bei dir an. Und nun wird er erforschen auf welche Manipulationen dein System reagiert, und auf welche nicht. Jedoch ist die Methode sehr unrentabel.

Methode B fishing.
Das ist die gefählriche Methode gegen deine Bibliothekt keine Chanche hat. Nun wie Funktioniert ein Sessionsfishing? Ganz einfach. Ich poste hier ins Forum ein Link auf meine Webseite. Dort schreibe ich den HTTP REFERER in eine DB. Jetzt muss ich nur noch warten, etwas Geduld haben. Dnach klcike ich den Referer Link an, und schon habe ich Zugriff auf den Account. Das wars. Mehr wie warten und einmal klicken reicht.

Ich zeig dir mal wie leicht Sessionsids protokolliert werden:
Schu dir mal hier auf dem Google Resultat die unterste URL an (ist Grün) https://www.google.de/search?hl=de&q="www.geldproanruf.de"&meta=

So natürlich gehörte die Session einst Google, und ist dagegen harmlos. Aber das macht nichts. Wenn ein User deine Seite über einen Link verlässt kann diese protokolliert werden. Zahlreiche Toolbars tun das.

Was glaubst du wie leicht es ist hier accounts auf VMS zu hacken? Einfach bei webmasterlose anmelden. /* Editiert bevor schlimmes passiert */

Hoffe bist aufgeklärt!

P.s. Noch zum Abschluss.
Man kann ein fishing einer Session nicht verhindern. Es sei denn, man verschlüsselt die Sessionsid durch ein Merkmal. Beispielweise eine 2te Komponente. Der Grund ist, PHP wird die übergebene Session schon vorher annehmen und verarbeiten. Mit session_start() machst du sie nur gültig! Deshalb ist das unset() so wichitig. Ich würde sogar bei nichtberechtigtem Zugriff die Session volsständig terminieren.

Du findest das Problem überall. Fast überall kannst du deine Lose versenden (auch auf klamm) ohne das Passwort angeben zu müssen. Auch auf Paypal ist der Versand von Geld ohne Passwort möglich.

Da braucht man sich eben nicht wundern, dass Accounts gehackt werden. Denn es wird nie irgendwas gehackt. Hacker sind keine Genies, wie man sie gerne ansieht. Sondern sie sind nur schlau! Mehr nicht.

Alles andere und wie deine Webseite sich vor diesen Gefahren schützen soll, liegt in der Hand des Programmierers. Ich würde es granicht versuchen zu verhindern. Statt dessen beite ich auch nicht die Möglichkeit sich deine E-Mail adresse abändern zu dürfen. Denn sonst ändert sie der HAcker, und lästt sich das PW doch bequem über das !Passwort vergessen! Problem zusenden.

Daher sollten auch solche Sachen bedacht werden. Auch wenn es jetzt den Rahmen sprängt. Aber eins sollte verstanden werden. Diese Einladungen sollte man nichtso stehen lassen. Wenn einer ein Passwort vergessen hat, sollte man ein neues generieren, und es ihm an seine Addy übermitteln. Und ja das wechseln einer Addy sollte nur vom Administrator möglich sein, bzw. sollte man bei Profiländerungen das Passwort abverlangen.

Das ist schon alles um eine Webseite Sessionstechnisch sicher zu machen. Wenn man den Zusammenhang verteht, weis man ihn auch zu verhindern. Im Web gibt es eben eine Lücke und die nächste.

Genauso sehe ich wie MYSQL Daten, nach dem connect nicht zurückgesetzt werden. Tja wer sich dann wundert, dass seine Datenbank gehackt wurde, der ist selbst schuld. Wie einfach sowas geht, ersparr ich mir, weil ich will keine Kriminellen züchten.

Gott sein Dank erweist sich -> unset() doch sehr nützlich!