Hm, ich versteh es nicht.
Kann man mit den ID Veränderungen auch Daten anderer Nutzer ändern bzw. wichtige interne Daten sehen oder was?

Den Tipp verstehe ich nicht. Warum denn zusätzlich in einem Hidden-Feld?
Ich lese bei jedem Seitenaufruf die Session des Users aus und frage diese ab. Reicht das oder gibt es einen Grund für das Hidden-feld?
z.B.

Ansonsten sehr interessante Zusammenfassung! Habe ich noch nicht alles gekannt.

Sicherheit ist leider nicht einfach wie diese Sätze zeigen. Addslashes oder magic_quotes gelten ja nicht gerade als die sicherste Lösung!

addslashes() halte ich für nicht so toll.
ich benutze htmlentities ( string string,ENT_QUOTES)
und bei numerischen angaben einfach vorher testen ob is_numeric() true ist.

Nehmen wir an, das E-Mail-Adressen-Änderungs-Formular sieht so aus:

Nun erstellt der Angreifer eine Seite, die so aussieht (stark gekürzt etc.):

Diese Seite schickt er dem Opfer zu (gleiches Vorgehen wie bei XSS).
Nun wird die Adresse in Unwissenheit der Users geändert und der Angreifer kann die "Passwort vergessen"-Funktion des Dienstes verwenden, um Zugriff zu bekommen.
Klar?

Danke.

Kommt drauf an. Wenn man die Abfragen entsprechend formuliert (immer Anführungszeichen verwenden), ist es, so weit ich weiss, 100% sicher. Ansonsten freue ich mich über ein Gegenbeispiel, ich lerne auch immer wieder gerne dazu.

Aufgepasst damit. 5*10E2 ist, soweit ich weiss, auch ein numerischer Wert. Je nach dem gibts da evtl. noch eine Angriffsmöglichkeit, die Chance ist zwar extrem klein, aber man sollte sich dessen bewusst sein.

HTML-Entities in der Datenbank halte ich für zweckentfremdend. Die HTML-Entities sollte man meiner Meinung nach so spät wie möglich generieren, damit sie wirklich nur im HTML-Code stehen. In die Datenbank gehört die möglichst ursprüngliche Version.
Sonst gibt es ein Durcheinander (Textareas, URLs etc. müssen dann wieder zurückgewandelt werden).

htmlentities(,ENT_QUOTES): Genau das habe ich vergessen! Die Konstante ENT_QUOTES habe ich bei meinem obigen Post noch ergänzt.

Das ist ein schönes Beispiel für konzeptionelle Fehler, die nicht durch die obige Liste abgefangen werden.

Die Änderung der Mailadresse muß zwingend die Eingabe des Passwortes erfordern.

Diese Liste stopft deshalb - vielleicht - 5% der potentiellen Sicherheitslücken, nicht 99%.

Und bei einem Nutzer, der Daten in ein per Mail zugesandtes Formular eingibt und es absendet, bei dem ist ohnehin alles vergeblich.

Ein Beispiel wie addslashes versagen kann:
http://shiflett.org/archive/184

Leider gibt es halt auch Methoden um mysql_real_escape_string zu umgehen.

Jo, solche Dinge skizzieren einige der Probleme. Die eigentliche Schlußfolgerung steht gleich im ersten Kommentar:

Aber dies ist das, was die meisten PHP/mySql - Nutzer leider nicht so gerne hören möchten, da dann nämlich der Entwicklungsaufwand dramatisch ansteigt:

Alle Datenänderungen über gespeicherte Prozeduren abwickeln und nur ein Backend nutzen, das dies unterstützt.

Und spätestens dann ist nichts mehr mit 'StudiVZ in einer Woche entwickeln'.

Dass MD5-Hashes mit Rainbow-Tables gehackt werden, kann man jedoch ganz einfach mit Salts verhindern.

Somit hat jeder User ein eigenes Salt, was natürlich Rainbow-Tables unnütz macht. Der einzige Weg die Passwörter dann noch zu knacken ist bruite force, was sehr lange dauern kann...

???
Ich hab ja die entsprechende Lösung in der Liste genannt.

Für die andere Methode habe ich jedoch keine Konzeptlösung parat. Allerdings steckt hier der Fehler meiner Meinung nach eher bei PHP, da addslashes() seinen Dienst nicht zu 100% korrekt verrichtet. Ich habe mir bereits überlegt, dass entsprechende Zeichen existieren müssen (Sonderzeichen bestehen ja immer aus 2 Zeichen, wie man es immer an den Umlauten sieht, die falsch interpretiert werden). Hier könnte man allerdings auch alle "bösen" Sonderzeichen vorher rausfiltern.

Die von madox genannte und sehr sinnvolle Variante ist genau so eine von mir genannte Weiterverarbeitung des MD5-Hashs.
Man kann beispielsweise auch ganz einfach den MD5-Hash nochmals hashen, und schon bringen die ganzen Rainbowtables nichts mehr.

EDIT: Aaah das ewige Character Encoding... Kennt da jemand ein gutes allgemeines Tutorial? Ich blick da kaum durch.

Lasst uns doch mal eine Funktion entwickeln, die man dann auf alle DB einträge anwenden kann. Das wäre sicherlich für viele praktisch.
z.B.
function mysql_insert_format($text,$feldtyp,$feldgroesse){

}

Aufruf zb mit $_POST['Username'] = mysql_insert_format($_POST['Username'],"varchar","15");


Oder gibt es sowas schon?