Im ersten Teil habe ich den Taint mode vorgestellt und gezeigt, wie gefährlich unbekannte Daten sein können. Jetzt geht es um die nicht minder wichtige Frage, wie man sich diese Daten trotzdem nutzbar machen kann. Das Ziel einer jeden (Web-)Anwendung sollte es sein, mit legitimen Eingaben problemlos und effizient umzugehen ohne dabei die Sicherheit gegenüber Betrugsversuchen leiden zu lassen.
Suchergebnisse mit Tag „security“
(SQL) Injection ist immer wieder für Bugs gut, vor allem bei Webanwendungen, aber auch andere Stellen können ganz leicht sehr gefährlich werden. PHP hat das lange Zeit in eindrucksvoller Weise demonstriert - dazu reichte schon ein sehr simples index.php:
DKIM may be called as PGP successor: PGP has been used by many people for signing their emails at a time when mostly technical related people had been using the internet. Today, few people still use PGP to sign their emails, but email servers took over this part using a technology called DKIM.
Not all files on a webspace should be accessible by anybody on the Internet. There are many tutorials for protecting directories or files with a password using a .htaccess file, but some files need to be on a webspace, which shouldn't ever be served by the webserver. This is a simple how-to-protect them tutorial.
It happend to PerlMonks, Sony and many others: A plain text password table was stolen from the database. Read this carefully to not become the next one on that list.