So, kleiner Nachtrag da gerade die Nachfrage per PN kam, nachfolgend die PN erstmal:
Hallo Sir Robin
Im Thread: "Include überprüfen"
meinst du das ich Tür und Tor öffne weil $link direkt von $_GET übernommen wird. Ich frage mich jetzt wie ich es sicherer machen soll, bzw warum reicht is_readable() nicht aus ?
Auf was sollte ich denn $_GET['go'] überprüfen ?
Danke für dein Verständnis.
Auf was sollst du $_GET['go'] überprüfen? Ganz einfach, wie ich vorher schon schrieb, ist in solchen Fällen sehr wichtig das du überprüfst ob der übergebene Wert gültig ist. Du machst dir also eine Liste, in dem gültige Werte drin stehen und machst daraufhin die Gegenprüfung. Diesen Ansatz nennt man Whitelist. Eine beispielhafte Implementierung ist die folgende:
PHP:
<?php
// das Array mit den erlaubten Seiten
$erlaubteSeiten = array('blog', 'news', 'links', 'kontakt');
if( in_array($_GET['go'], $erlaubteSeiten) ) {
// ... Zugriff erlaubt, include Seiten
include('...');
} else {
// ... nicht erlaubt, 404
include('404.php');
}
?>
ist natürlich super simpel jetzt, man kann das auch noch anpassen, sodass das Array vielleicht nicht hardcodiert ist, sondern bei dir aus der Datenbank kommt. Oder oder oder, aber es geht ja um den Ansatz.
Der Blacklist-Ansatz wäre der, dass man versucht "böse Zeichen" etc. zu unterbinden, soll heißen: Man sucht nach speziellen Zeichen, und wenn die vorkommen versucht man im schlimmsten Fall diese zu bereinigen (was in solchen Fällen dann gleich 2 Fehler auf einmal wären) oder bricht dann mit einem Fehler ab. Dieses Verfahren hat aber ziemliche Nachteile:
- sehr hoher Wartungsaufwand, es kommen schließlich immer wieder neue Sachen dazu
- man übersieht sehr gerne bestimmte Zeichen
- man vergisst gewisse Sonderbarkeiten, etwa spezielle Kodierungen (UTF8 etc.)
- wenn man den Bereinigen Weg wählt: Oft Fehler beim Bereinigen die, die Lücken erst aufklaffen lassen
kurzum: Im Vergleich zu einer Blacklist ist das sehr unsicher in diesem Fall. Es gibt wirklich ungemein viel zu beachten um eine sichere Anwendung zu programmieren, aber man erreicht schon eine nicht zu verachtende Grundsicherheit wenn man darauf achtet sinnvoll mit Usereingaben umzugehen.
Es gibt auch viele Servermodule/PHP-Module die die Sicherheit erhöhen, etwa Hardened PHP (zu empfehlen, auch die Bücher von denen), mod_security oder auch eine chroot-PHP-FCGI Umgebung im Apache ... aber all das greift später, man kann sich Sicherheit wie eine Art "Zwiebelschalen"-Modell vorstellen, jede Komponente ist eine Art Schale. Manch eine ist anfälliger als die andere und viele Komponenten spielen mit rein, etwa der Webserver, der Datenbankserver, das Betriebsystem etc., aber einer der wichtigsten Schichten, gerade weil sie die Schnittstelle zwischen Außenwelt in Innenwelt bietet, ist die Applikation als solches und diese sollte man so gut wie möglich absichern, zumal es oftmals gar nicht mal so schwer ist. Um die Kurve zu kriegen: Die letzten Lücken im Bekannten Joomla/Mambo basierten alle darauf, das include-Dateien direkt aufgerufen wurden und es keine ausreichende Überprüfung gab ob es ein direkter Aufruf war oder nicht, was dann zusammen mit register_globals zur Lücke führte. Die haben übrigens mittlerweile auch überall eine Variable drin, die angibt ob die Datei includet ist oder nicht. Eine Konstante eignet sich in dem Fall trotzdem besser.
Puh, ganz schön ausgeholt, hoffe es wurde ausreichend dargelegt was ich meinte, wenn nicht frag nochmal nach.
