wahsaga: Einstiegsfragen für sicheres Verarbeiten von Formularen

Beitrag lesen

hi,

* Nachdem ich ( zB für ein Weblog ) Daten aus einem Formular übernommen habe, verwende ich, _bevor_ die Daten in die Datenbank geschrieben werden, die php-Funktion mysql_real_escape_string.

Ja.

* Alles andere soll ich zunächst so lassen, wie es der User mir übermittelt hat und die Daten somit nun an die Datenbank senden.

Ja.

* Wenn ich nun bei der Ausgabe der Daten ( ich bleibe beim Beispiel Weblog ) möchte, daß das Schriftbild gleich bleibt, dann muß ich ja verhindern, daß Dinge wie Überschriften oder CSS-Formatierungen nicht in die endgültige Seitenausgabe kommen.

Das "Schriftbild" ist deine geringste Sorge. Wenn ich aber bspw. Javascript-Code einbringen kann, der den Nutzern Cookies stielht o.ä. ...

Daher verwende ich _nach_ dem Auslesen aus der Datenbank und _vor_ der Weitergabe an den Client die php-Funktion htmlspecialchars.

Ja.

Ist das _soweit_ mal richtig verstanden?

Ja.

(Viele "Ja"s bis jetzt ... die natürlich hier kein LMAA bedeuten ;-))

  1. Womit muß ich mich beschäftigen, wenn ich zwar vermeiden will, daß jemand mit <h1> oder <span style="color:red"> das Textlayout verunstaltet ... aber trotzdem dem nicht im Weg stehen will, der zB den Satz "Überschriften werden in html mit <h1> ausgezeichnet." schreibt?

Lass ihn einfach

Überschriften werden in html mit <h1> ausgezeichnet.

eingeben - und gut.

htmlspecialchars macht daraus

Überschriften werden in html mit &lt;h1&gt; ausgezeichnet.

  • und das zeigt dein Browser dann als "... mit <h1> ausgezeichnet" _an_.
  1. Gelegentlich habe ich auch gelesen, daß die Funktionen addslashes() und stripslashes() unverzichtbar sind für eine sichere Verarbeitung. Stimmt das?

Nein.

stripslashes kann ggf. erforderlich werden, wenn die nutzlose Einstellung magic_quotes_gpc aktiviert ist - die stellt den Sonderzeichen ", ', \ und NUL automatisch einen maskierenden Backslash voran in _allen_ Daten, die dein Script per GET/POST/COOKIE bereitgestellt bekommt.
_Wenn_ diese Funktion die Daten bereits "versaut" hat - abzuprüfen mit get_magic_quotes_gpc() - _dann_ ist stripslashes sinnvoll, um erst mal wieder "normal" damit arbeiten zu können.
magic_quotes_gpc ist eine Einstellung, die in aktiviertem Zustand allzu große Noobs, die sich nicht mal ansatzweise die Gedanken bzgl. Sicherheit machen, die du dir schon gemacht hast, vor sich selbst schützen soll. In PHP 6 wird sie entfallen.

addslashes nutzen manche Leute, die mysql_real_escape_string nicht kennen, als Ersatz für dieses - ist natürlich blödsinnig. Sie macht _zufällig_ in etwa das gleiche. Aber wenn sich bspw. die MySQL-Schnittstelle zukünftig mal ändern _sollte_ bzgl. der Sonderzeichen, auf die sie allergisch reagiert - dann wird mysql_real_escape_string höchstvermutlich auch entsprechend angepasst; addslashes aber ziemlich sicher nicht, warum auch.

  1. Womit muß ich mich beschäftigen, wenn ich Sätze wie "Geben Sie dem User nur die Rechte für die Datenbank, die unbediungt nötig sind" lese?

Mit dem Rechtesytem des DBMS :-)

Wer nur Daten Lesen können soll, muss nicht Schreiben dürfen; wer in eine Tabelle Schreiben darf, muss das nicht unbedingt in _allen_ dürfen; ...

GRANT/REVOKE sind Stich-/Schlüsselworte, zu denen das Handbuch Bescheid wissen sollte.

gruß,
wahsaga

--
/voodoo.css:
#GeorgeWBush { position:absolute; bottom:-6ft; }