te one schrieb:
Die Antwort auf die obere Frage würde mich interessieren. Gibt es nun komplexere Möglichkeiten?? Denn ohne Hochkommata kommt man einfach nicht weit und ich denke nicht, dass die zu faul für eine Funktion zur Prüfung sind...
Nix was ich kennen würde. Prepared Statements sollten eigentlich narrensicher sein, und auch real_escape... ist ziemlich sicher.
In deinen Beispielen womöglich durchaus unnöttig. Jedoch sollte die ID in manchen Bereichen schon passen (Login, Geldtransfer, ...)
Nä, der Username bei einem Login ist gar nicht so geheim. Bei Online-Banking ist es z.B. oftmals ne Kontonummer. OK, die trägt man jetzt nicht in die Welt hinaus, sie ist aber auch nicht geheim. Bei Foren etc. ist es derselbe Username, der auch dann für die Posts verwendet wird. Auch bei nem CMS ist der administrative Username oftmals irgendwo im öffentlichen Teil sichtbar. Bei anderen Sachen wie Shops ist es ne Mailadresse, auch nicht gerade hochgeheim. Die meisten User haben wohl nur eine oder 2, die wenigsten Leute sind so paranoid, für jeden Shop ne separate Adresse anzulegen. Ok, in dem Falle kann man aber sagen: Paranoid zu sein heißt nicht, dass nicht wirklich jemand hinter dir her ist.
Was an Logins wirklich kritisch ist, ist das Passwort bzw. die Art, wie damit umgegangen wird.
1.) keine Klartext-Passwörter in der Datenbank lagern, sondern MINDESTENS gesalzene MD5-Hashes. Dagegen hat z.B. der Shop von Mr. Spex verstoßen (zusammen mit SQL Injection Verwundbarkeit).
2.) Lass dich nicht mit ner Injection erwischen wie (where username=ABC and (password=xyz OR 1=1).... Nummer 1 schließt sowas aber schon fast aus.
Wie soll auch eine Gültigkeitsprüfung für Passwörter aussehen? Bei einem guten Passwort ist ALLES erlaubt. Im Idealfall nutzt man kein Passwort sondern eine Passphrase. Das Passwort "Swordfish 2001 Travolta" ist hinsichtlich Brute Force Algorithmen locker genau so sicher wie "50cv9zB.*c", aber im Gegensatz zum 2. wird man das erste nicht auf einen Zettel schreiben und an den Schreibtisch pinnen.
Eine Gültigkeitsprüfung macht nur beim Anlegen von Daten Sinn. Ist die Mailadresse eine Mailadresse? Ist das Passwort sicher genug? Beim Abruf isses Wurst.
Jesterfox schrieb:
Komplexer vielleicht nicht, aber SQL-Injection ist bei weitem nicht das einzige Thema. Jeder User-Input kann potentiell gefährlich werden wenn man nicht richtig damit umgeht (Cross-Site-Scripting, Buffer-Overflow, usw.)
Jo, aber leider Gottes sind es immer noch verdammt oft Injections, ohne komplexere Angriffsvektoren.
