Tipps und Tricks für sicherere Programmierung
>Ein beliebter Fehler ist, einen Reload einer Webseite nicht im Workflow einzuplanen. Am besten pflegeleicht wird es, wenn man Aktion und Reaktion auf verschiedene URLs und Dateien verteilt. Als Beispiel mal ein Kontaktformular:
kontakt.php
kontakt_do.php
kontakt_done.php
kontakt_err.php
Hier wird die Aufgabeverteilung wie folgt gestreut:
Darstellen des Formulars ohne Interaktion mit einem Backend wie Mailer oder Datenbank,
Empfang der Formulardaten via POST im [...]
Immer die Konstante links der Komparators halten, falls man mal aus Versehen eine Zuweisung draus macht.
if 13 == Pech then
Wenn möglich alle extern gelieferten Parameter via Prepared Statements einbinden. SQL Injection wird so unwarscheinlicher.
Der Datenbankbenutzer mit dem das Backend an eine DB sich anmeldet braucht nur minimale Rechte wie INSERT, UPDATE, SELECT und ggf. DELETE zu besitzen. Er braucht keine CREATE, FILE oder DROP Rechte!
Wenn man neue Speicherbereiche nicht vollständig mit eigenen Nutzdaten füllt und diese Blöcke überträgt, kann sich fremder Inhalt mit schützenswerten daten dort einschleichen. Also immer alle Puffer und Strukturen explizit füllen mit Blanks oder 0. Ein einfaches setzen von leeren Strings in Puffern langt nicht, da dies nur eine NULL in das erste byte schreibt [...]
Wenn mal wieder Backups auf Bändern oder CDs oder wasauchimmer verlorengehen, sollte man vorher an eine Verschlüsselung der Daten gedacht haben. Jedes bessere Backup Programm kann sowas und man sollte das auch nutzen.
Die von Benutzer gewählten Passwörter auf ihre Eignung hin prüfen und dem Anwender die schlechte Wahl zeigen und ggf. nicht akzeptieren.
Am zeitlichen Verhalten kann man ggf. auch Informationen erfahren. Eine schnelle negative Antwort kann so z.B. auf das fehlen eines Users hinweisen, wogegen eine längere Bearbeitung und anschließende negative Antwort wohl eher auf ein falsches Passwort zeigt (vereinfacht darhestellt).
Wer es also besonders sicher mag, der fügt ein zeitliches Rauschen ein, welches alle Varianten der Entscheidungspfade [...]
Entgegen den meisten Kundenwünschen sollten Passwörter nicht im Klartext in der Datenbank vorliegen, sondern in einem nicht reversiblen hash abgelegt werden.
Eine Passwort Variable sofort nach dem letzen Gebrauch löschen und überschreiben. Die Variable am besten auch non-swappable markieren.
