QUOTE (Ronald Nickel @ Do 22.05.2008, 11:33)Das Loginprinzip ist meines erachtens nicht gerade leicht zu knacken
Das Paswort als Formularwert wird MD5 verschlüsselt und datenbankseitig mit dem MD5 String veglichen welches (sofern vorhanden) zum Namen passt. Alles wird als Formularvariable nicht als Url-Variable übergeben.
Injektons wie "... or where 1=1" werden nicht zugelassen
Das hat derzeit nicht allzuviel zu sagen.
Bsp. kann ein gewöhnliches Suchformular (oder irgendein anderes Eingabeformular) eine Lücke enthalten. Diese kann es ermöglichen, daß man sich per Sql-Injection Daten aus den internen Masken
Nutzername MD5-Passwort
auslesen und anzeigen lassen kann.
Hat man den MD5-Wert, kann man auch rasch einen Code schreiben, der mal wild testet. Als Ergebnis erhält man den Nutzernamen und ein zugehöriges Passwort mit demselben MD5 - Wert - und man ist drin. Eine andere Variante sind Codefehler, die es ermöglichen, per JavaScript Sessionvariablen weiterzuleiten. Da braucht man gar kein Passwort dazu.
Ein anderes grundlegendes Problem besteht darin, daß jemand dasselbe Passwort für verschiedene Seiten verwendet - und eine andere Seite irgendeine Lücke aufweist, so daß das Passwort von dort stammt.
Ich bin bei server-daten inzwischen völlig davon abgekommen, daß sich Nutzer ihre eigenen Passwörter definieren können. Ich hatte zwar mal ursprünglich eine solche Logik entwickelt. Faktisch stellt sich allerdings heraus, daß es auch hervorragend ohne geht.
Schließlich:
Hier hatte ich auf Probleme hingewiesen, die auch bei mySql auftauchen können, da die neueren Versionen Funktionen wie Cast unterstützen. Da reicht ein Zahlenfeld (bsp. Kategorie als Pulldownliste, die als Zahl übergeben wird), das nicht auf einen korrekten Wert überprüft wird. Und schon kann man Code der Form
CODE Declare @t nvarchar(4000) Set @t = Cast(Hexadezimalcodierung) Exec (@t)
einschleusen, der kein einziges ' mehr enthält.
