Soweit scheint dieses Stück Code genau das zu machen was es soll. Eine Datei wird generiert und landet immer frisch auf dem Tisch:
    header(‘Content-Type: image/png’);
header(‘Content-Disposition: attachment; filename=”flyer.png”‘);
header(‘Content-Transfer-Encoding: binary’);
header(‘Content-Length: ‘ . filesize($tmpfile));
header(‘Cache-Control: no-store, no-cache, must-revalidate, proxy-revalidate, private’); // HTTP/1.1
header(‘Cache-Control: pre-check=0, post-check=0, max-age=0′, false);
header(‘Last-Modified: ‘.gmdate(‘D, d M Y H:i:s’) . ‘ GMT’);
header(‘Expires: ‘ . gmdate(‘D, d M [...]

continue reading.....

Kleine Ursache, große Wirkung:
Ein kleines Script auf dem Server soll einmalig an die User eine eMail schreiben. Man ruft es im Browser auf, es versendet, schreibt noch brav ein wenig Logging auf den Schirm und ist fertig. Toll!
Leider: Im Browser war ein Alexa-Plugin installiert (die google Toolbar wäre wohl der gleiche Fall), dadurch lernt eine [...]

continue reading.....

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 [...]

continue reading.....

Böse Dinger sowas. Immer jeden erwarteten Wert auf eine Positivliste hin über einen Regulären Ausdruck hin prüfen. IDs dürfen also nur 0-9 enthalten usw.

continue reading.....

Daten einer Sitzung gehören auf den Server und niemals in hidden Fields im HTML. Dort gehört höchstens die SitzungsID hinein, falls keine Cookies gehen oder so.

continue reading.....

Die Ziel eMail niemals im Formular mitgeben. Sonst kann Spam verschickt werden. Der Empfänger muß erst im Server generiert werden.

continue reading.....

Am besten niemals JavaScript in Nutzereingaben zulassen. CrossSideScripting ist sonst fast unvermeidbar. Also kein HTML in Textblöcken, sondern eine eigene Formatierung wie BBCode oder Wiki einführen.

continue reading.....

Wenn der Nutzer was eingeben darf, dann nur angemeldet, oder nach einer CAPCHA (Bild mit Anweisung).

continue reading.....

Keine Unterscheidung erlauben zwischen falschem User und falschem Passwort. Das kann intern gelogged werden, darf aber dem potentiellen Angreifer nicht sichtbar gemacht werden.

continue reading.....

Eine Anmeldung sollte via eMail und link darin innerhalb einer kurzen Zeit bestätigt werden müssen. Erst danach gilt der User als registriert. -> Botanmeldungen vermeiden/behindern.

continue reading.....