Aktuelle Login Scripte

[Cedric01]

Es sind ja im Web genügend Beispiele an php Login Scripten.
Doch suche ich ein Tut oder Beispiel Script mit aktuell Sicherheitsstandards.
Kann mir eine von euch einen Tipp geben.

Danke Cedric

[mycat]

Die Frage ist doch - was soll man dürfen ...

Hallo Cedric,

Die Frage ist doch erstmal, was du an Sicherheit haben möchtest und wie genau Eingaben geprüft sein sollen.

Im Allgemeinen würde ich mal behaupten, dass du mit htmlentities() schon recht gut fährst. Falls das Skript nicht mit Latin1(ISO-8859) arbeitet, solltest du wegen den Umlauten z.B.

htmlentities($var, Modus, "utf-8") 

die Codierung mitgeben.
PHP: htmlentities - Manual

Genauere Prüfungen würde ich mit RegEx

preg_match(), preg_match_all() 

machen.
PHP: preg_match - Manual

Weitere Möglichkeiten könnten sein:

trim(), strip_tags(), htmlspecialchars() 

und viele weitere ...

Heute ist es ev. auch sinnvoll mit jQuery erstmal zu prüfen, dabei sind auch in jQuery Reguläre Ausdrucksprüfungen möglich. Damit kannst du die "schönen" Formulare machen, in denen das Feld grün wird, sobald die Eingabe akzeptiert wird. Es geht dabei sehr einfach, z.B. den "senden" Button zu sperren, bis ALLE Felder ein OK geben ...

Eine eindeutige Antwort wird bei jedem anders lauten, es gibt hier viele Wege nach Rom.

Hoffe, ein wenig geholfen zu haben

Fredi

[h3ll]

Im Allgemeinen würde ich mal behaupten, dass du mit htmlentities() schon recht gut fährst. Falls das Skript nicht mit Latin1(ISO-8859) arbeitet, solltest du wegen den Umlauten z.B.

htmlentities($var, Modus, "utf-8") 

die Codierung mitgeben.
PHP: htmlentities - Manual

Das ist doppelt falsch.

Umlaute müssen überhaupt nicht kodiert werden, wenn man den korrekten Zeichensatz verwendet.

htmlentities() ist die falsche Funktion um sich gegen XSS-Attacken abzusichern. htmlspecialchars() ist hierfür zu verwenden.

htmlentities() macht nur dann Sinn, wenn man Zeichen in einem Zeichensatz ausgeben möchte, der diese nicht unterstützt. Sowas ist aber sehr selten bis gar nicht der Fall und schon gar nicht auf der eigenen Webseite, auf der man volle Kontrolle über den gewählten Zeichensatz hat.

[wahsaga]

Zeichensatz != Zeichenkodierung </klugscheiss>

[h3ll]

Zeichensatz != Zeichenkodierung </klugscheiss>

Ist das auf mein Beitrag bezogen? Ein Zitat könnte nicht schaden.

[wahsaga]

Na gut, hier hast du eins:

htmlentities() macht nur dann Sinn, wenn man Zeichen in einem Zeichensatz ausgeben möchte, der diese nicht unterstützt. Sowas ist aber sehr selten bis gar nicht der Fall und schon gar nicht auf der eigenen Webseite, auf der man volle Kontrolle über den gewählten Zeichensatz hat.

Du meinst Zeichenkodierung, nicht Zeichensatz.

[h3ll]

IMHO Haarspalterei. Die Zeichenkodierung hängt vom Zeichensatz ab.

[wahsaga]

[...] wenn man Zeichen in einem Zeichensatz ausgeben möchte, der diese nicht unterstützt.

Du kannst kein Zeichen ausgeben, das Unicode nicht unterstützt resp. beinhaltet.

Du kannst aber Zeichen aus dem Zeichensatz Unicode ausgeben, ohne eine Zeichenkodierung zu verwenden, die Unicode abbilden kann – bspw. eben mit htmlentities.

IMHO Haarspalterei. Die Zeichenkodierung hängt vom Zeichensatz ab.

Nein, das kann man so nicht sagen.
Und Haarspalterei ist korrekte Verwendung von Begrifflichkeiten m.E. auch nicht.

[h3ll]

Du kannst kein Zeichen ausgeben, das Unicode nicht unterstützt resp. beinhaltet.

Du kannst aber Zeichen aus dem Zeichensatz Unicode ausgeben, ohne eine Zeichenkodierung zu verwenden, die Unicode abbilden kann – bspw. eben mit htmlentities.

Das hab ich ja gesagt.

Nein, das kann man so nicht sagen.
Und Haarspalterei ist korrekte Verwendung von Begrifflichkeiten m.E. auch nicht.

Wenn man den ISO-8859-1 Zeichensatz verwendet, verwendet man auch die Zeichenkodierung für ISO-8859-1. Wenn man den UTF-8 Zeichensatz verwenden, verwendet man die Zeichenkondierung für UTF-8. Es macht keinen Sinn die beiden Dinge zu trennen. Von daher ist nur nur i-Tüpfchenreiterei. Wenn ich sage, ich verwende den UTF-8 Zeichensatz, dann meine ich natürlich auch die dementsprechende Kodierung. Alles andere macht ja keinen Sinn.

Du gibst ja auch im Content-Type den "charset" an und nicht das "charencoding", obwohl natürlich auch die Kodierung damit gemeint ist.

[wahsaga]

Das hab ich ja gesagt.

Nein, hast du nicht.

Wenn man den ISO-8859-1 Zeichensatz verwendet

Kann man nicht, weil es kein Zeichensatz ist.

Wenn man den UTF-8 Zeichensatz verwenden

Kann man nicht, weil es kein Zeichensatz ist.

Es macht keinen Sinn die beiden Dinge zu trennen.

Doch, weil es zwei vollkommen verschiedene Dinge sind.

Wenn ich sage, ich verwende den UTF-8 Zeichensatz, dann meine ich natürlich auch die dementsprechende Kodierung. Alles andere macht ja keinen Sinn.

Nein, vor allem das „macht keinen Sinn“, weil es schlicht falsch ist.

Du gibst ja auch im Content-Type den "charset" an und nicht das "charencoding", obwohl natürlich auch die Kodierung damit gemeint ist.

Ja, das ist ein historisch gewachsener Fehler im HTTP.
(Ähnlich wie bspw. der Referer.)

[AmicaNoctis]

Kann man nicht, weil es kein Zeichensatz ist.

ISO-8859-1 ist eine Codierung und ein Zeichensatz! UTF-8 dagegen ist eine von vielen möglichen Codierungen des Unicode-Zeichensatzes.

[wahsaga]

ISO-8859-1 ist eine Codierung und ein Zeichensatz!

Gut, in dem Fall mag es da eine begriffliche Überschneidung geben.

Aber an Unicode vs UTF-xy sieht man gut, warum die Unterscheidung doch ihre Berechtigung hat.

[Cedric01]

Mycat Fragt,


was ich sichern möchte und was ich dann erlauben möchte.


Nun zusichern ist eine Firmendatenbank mit Kundendaten, Shop und Formularfeldern. Zurzeit ist die Firma nicht so groß das sich ein Profi-Hacker die Mühe machen würde, doch ich möchte auch nicht, dass es von einem Erstklässler geknackt wird.
Und dann alle sagen, „Das hättest Du doch wissen müssen“.
Der Script sollte einfach solide und dem aktuellen PHP entsprechen.

[AmicaNoctis]

Das Wichtigste ist, dass du Kontextwechsel beachtest und zwar genau dort, wo sie auftreten. Sollen Benutzereingaben in die Datenbank eingetragen werden, benutze Prepared Statements von PDO. Sollen Daten als HTML ausgegeben werden, benutze htmlspecialchars(), um XML- und HTML-Sonderzeichen zu maskieren. Willst du mit Benutzerdaten eine E-Mail verschicken, nimm lieber eine praxiserprobte Mailerklasse, statt selbst etwas mit mail() zusammenzuwurschteln.

Die wichtigsten Stichworte zum Weiterlesen sind XSS, SQL-Injection und E-Mail-Header-Injection.

[wahsaga]

Erweiternd zu Amicas Hinweisen: Artikel:Kontextwechsel ? SELFHTML

Was da drin steht, musst du wissen. Und zwar im Schlaf ;-)