ChrisB

Mach dir bitte augenblicklich - zumindest bevor du weiter programmierst - klar, dass es extrem naiv ist anzunehmen, ein Request an ein PHP-Script müsste überhaupt von so etwas wie einem „Browser“ kommen.

__________________
RGB is totally confusing - I mean, at least #C0FFEE should be brown, right?

Mister Ad

tr0y

@php1704: Deine "client-seitige"-Prüfung ist eigentlich eine server-seitige Prüfung, oder woher soll der Client wissen welche Benutzernamen es gibt, wenn der Server die Eingabe nicht prüft ? ( Ajax-Request fragen hier den Server )

Bei egal welchen Eingaben validiert man die per Request übergebenen Werte und verhindert etwaige Exploits in seiner Anwendung respektiver ihrer Nutzung innerhalb der Anwendung.

Bei Datumseingaben kannst du viele Methoden der vorab-validierung nutzen, sei es drum das du ein Javascript-Callback als Event an die Eingabefelder hängst, oder eine Auswahlmatrix ( in Form von Select-Feldern oder Button-Grids ) bereitstellst, die das ganze DAU-patibel machen. Alles in allem ethablierst du damit aber keinerlei Sicherheit.

Warum ? Nun, ich beschreibe den Grund immer gerne mit dem Wort "DGH-Kaskade".

D - DAU-Level: die erste Stufe birgt keine Sicherheitsfeatures, eher einen Tolleranzbereich für die Eingabe die dort getätigt wird, es wird verhindert das beispielsweise Numerische Werte außerhalb einer sogenannten Range eingegeben werden können.

G - Geek-Level: die zweite Stufe birgt einen Sicherheitsaspekt, es wird hier verhindert das Werte als nicht-erwünschte Typen ans die Verarbeitungs-Methoden des Scripts gelangen. In der Regel passiert das beispielsweise bei Numerischen Eingabe-Werten wie bei Teilen eines Datums in dem die einzelnen Werte jeweils zu Integer "gecastet" werden. ( intval() oder (integer)$var ansehen! ).

H - Hacker-Level: die dritte und letzte Stufe birgt die kritischte Sicherheitsstufe, es soll hier verhindert werden, das bestimmte Sub-Scripts direkt aufgerufen werden, in denen Beispielsweise includierende Scripts vorbereitete Variablen "hineinreichen", wo sie im Endeffekt erst behandelt werden. Verhindert wird in diesem Fall die Möglichkeit diese Sub-Scripte direkt aufzurufen ( Prüfung auf Existenz einer bestimmten Konstante - also eines Datentyps innerhalb des Scripts, der in garkeinem Fall von außen gesetzt werden kann ). Bevor man jetzt mit dem gedanken Spielt, ja und ? Im Normal-Fall werden die Übergebenen Variablen doch in eigenen Variablen oder eigenen Arrays gespeichert, das mag sein das man davon ausgeht, aber viele Denken ebend nicht so und "überschreiben" gern auch mal Werte in Superglobals oder noch schlimmer leiden unter Registrus Superglobulus Variablus, einer Anfänger-Pandemie die die größten Sicherheitslücken der PHP-Menschheit aufreißt. ( Read @google: "PHP Register Globals" ).

Kaskade steht in diesem Fall für die Eskalationslinie die sich durch das Problem zieht ( von Kleines Problem zu großes Haufen Kacka ). Wo die DAU-Klamotten geradezu noch eher Bequemlichkeits-Features und mit unter kosmetische Features sind, steigt das Risiko der Unsicherheit immer mehr, je weiter man in der oben geschilderten Kaskade hinabfällt.

__________________
Lasse mir ohne Anwendung von Gewalt Dinge schenken, Amazon weiß darüber bald mehr.