Hauptmenü

Untermenü

Sicher programmieren - Desinformation

1. Die Abschnitte

2. Content Management Systeme

Hier sollte man tunlichst alle Hinweise entfernen, die auf das eingesetzte CMS hinweisen. Natürlich nur, wenn die Copyright-Bestimmungen das gestatten. Außerdem empfiehlt sich hier mod_rewrite, um die URLs umzuwandeln, denn auch die könnten Hinweise liefern.

3. Stopft eurem Webserver das Maul

Was ich euch nun erzähle, steht im krassen Gegensatz zu dem, was ich euch unter dem Punkt Fehlersuche gesagt habe. Bedenkt aber immer, dass es sich dabei um Tipps für die Entwicklung/Programmierung einer Anwendung handelte. Im Live-Betrieb sollte man das genaue Gegenteil beherzigen.

Da ich mal davon ausgehe, dass die meisten eh nicht direkt am Server (php.ini) herumspielen dürfen, beschränke ich mich auf die Möglichkeiten, die PHP bietet. Das setzt natürlich voraus, dass ihr über die entsprechenden Rechte verfügt. Sollte euer Provider das nicht zulassen, so sucht euch einen neuen.

Meldungen komplett unterdrücken

Man kann nun alle möglichen Ausgaben einfach abklemmen. Das Ergebnis sähe dann so aus: 


error_reporting (E_NONE);
ini_set('display_errors', Off);

Leider habt ihr dann im Live-Betrieb keine Möglichkeit mehr, Fehler zu erfassen. Daher empfiehlt sich folgende Variante, die alles in eine Log-Datei schreibt. 


error_reporting (E_ALL);
ini_set ('display_errors', 'Off');
ini_set ('log_errors', 'On');
ini_set ('error_log','pfad_zur_datei/datei.log');

So werden keinerlei Ausgaben mehr im Browser erzeugt, die bei Fehlern Rückschlüsse ermöglichen. Gleichzeitig könnt ihr die aber immer noch über eure Log-Datei abrufen.

4. robots.txt

Da sich selbst Suchmaschinen-Robots nicht immer an die Anweisungen dieser Datei halten, sollte man bei Ordnern mit hochsensiblen Inhalten immer mit einer .htaccess-Datei arbeiten, die man einfach mit folgendem Inhalt darin ablegt. 


Deny from all

Nicht lachen. In etlichen Firmen werden Webserver gerne als Dateiablage benutzt, damit alle Mitarbeiter darauf zugreifen können. Leider können das dann tatsächlich auch alle und nicht nur die, für die es bestimmt ist. Stichwort Google Hacking. Als Alternative zu dieser rabiaten Lösung kann man noch mit einem Passwort-Schutz arbeiten.

5. Andere Dateien

Dateiendung

Früher hat man besonders bei PHP-Anwendungen sehr gerne mal Fünfe gerade sein lassen. Da hatten dann die Dateien auch schon mal eine Endung wie zum Beispiel bla.inc oder bla.dev. Leider wurden die vom Parser nicht umgewandelt, so dass man bei einem direkten Aufruf den Quellcode zu Gesicht bekam. Und was glaubt ihr, wenn jemand zum Beispiel durch herumprobieren herausfindet, dass die Zugangsdaten zu MySQL in der Datei db.inc liegt? Genau, der ruft sie im Browser auf und sieht dann das: 


$user     = 'user';
$host     = 'host';
$password = 'passwort';
$database = 'datenbank'; 

Was danach passiert, könnt ihr euch wohl denken. Also! Sämtliche PHP-Dateien bekommen die Endung, die der Parser versteht und entsprechend umwandelt. Also bitte nichts mehr mit bla.inc und dergleichen!

phpinfo

Dies ist der "Worst-Case", wenn es um die Beschaffung grundsätzlicher Informationen geht. Die meisten Programmierer legen eine Datei an, in der nur die Funktion phpinfo(); steht, um sich bei deren Aufruf im Browser einen Überblick über die Konfiguration eines Webservers zu verschaffen.

Dagegen ist prinzipiell nichts einzuwenden. Solange man sie zum Beispiel mit einem Passwort schützt (entweder im Code mit $_SERVER['PHP_AUTH_USER'] oder per .htaccess) oder nur mal einen kurzen Blick auf das Ergebnis wirft und anschließend die Datei wieder löscht.

Leider wird das immer wieder vergessen. Und nicht nur das! Diese Datei wird auch noch ins Wurzelverzeichnis gelegt und bekommt den Namen info.php oder phpinfo.php. In vielen Fällen ist es also ein Leichtes, diese Datei zu finden und aufzurufen. Also denkt daran, wenn ihr damit arbeitet.

zurück zum vorherigen Abschnitt weiter zum nächsten Abschnitt