Include
#1
geschrieben 23. Dezember 2010 - 20:47
<? include("./text/$_GET[site].php");?>
Wobei man dann ja immer index.php?site=startseite eingeben muss um auf die startseite zu kommen, was ich bisher immer mit weiterleitungen gelöst habe da wen man index.php so aufruft ja ein include fehler kommt...
Nun habe ich mich gefragt ob es ein Code gibt damit man index.php aufrufen kann und wen ein fehler kommen würde anstelle des fehlers einfach startseite.php anzeigt?
Anzeige
#2
geschrieben 23. Dezember 2010 - 21:19
GET
am Anfang ab und schreib den Wert in eine Variable also
$seite = $_GET['site'];
und falls die Variable $seite dann leer ist, dann schreib "startseite" rein. oder gleich zusammengefasst
if ($_GET['site'] == "") {$seite = "startseite";} else {$seite = $_GET['site'];}
und dort wo du bei deinem include mit $_GET['site'] gearbeitet hast, schreibst du einfach $seite rein.
Eleganter ist es natürlich, die Variable abzufragen und die Zuordnung dann mit case - switch zu machen. Da kann man dann die Startseite als default festlegen und dann kommt die immer, wenn keine andere Variable stimmt.
Dieser Beitrag wurde von Holger_N bearbeitet: 23. Dezember 2010 - 21:23
#3
geschrieben 23. Dezember 2010 - 21:36
irgendwie geht nix...
<?
$seite ="./text/$_GET['site'].php";
if ($_GET['site'] == "")
{
$seite = "./text/startseite.php";
}
else {$seite = $_GET['site'];}
?>
<? include("./text/$seite");?>
Wo steckt nun der fehler drin? :-S
#4
geschrieben 23. Dezember 2010 - 22:08
<?php if ($_GET['site'] == "") {$seite = "startseite";} else {$seite = $_GET['site'];} include("./text/".$seite.".php"); ?>
Probier mal einfach so, ohne zusätzlich noch was einzufügen.
#5
geschrieben 23. Dezember 2010 - 22:13
Ist übrigens auch sehr "sicher" *hüstel*. So ohne jede Filterung und Sicherung lässt sich somit alles inkludieren. index.php?site=../.htaccess funktioniert da wunderbar... Weitere Möglichkeiten kann sich jeder selbst ausmalen.
#6
geschrieben 23. Dezember 2010 - 22:16
Genau das wollte ich dachte nicht das ich nix einfügen muss...
Bei PHP stehe ich irgendwie immer auf dem Schlauch... Danke für deine Hilfe!
#7
geschrieben 23. Dezember 2010 - 22:20
Also so ähnlich mach ich das:
<?php $seite = $_GET['site']; $sauber = trim(strip_tags($seite)); $sauber = str_ireplace("where", "", $sauber); $sauber = str_ireplace("select", "", $sauber); $sauber = str_ireplace("from", "", $sauber); switch($sauber) { case "startseite" : $link = "./text/startseite.php"; break; case "var2" : $link = "./text/zweite_seite.php"; break; case "var3" : $link = "./text/dritte_seite.php"; break; default : $link = "./text/startseite.php"; break; } require_once($link); ?>
Die Zeilen mit case müssen dann entsprechend angepasst werden. Statt var2 und var3 kommen natürlich die sonstigen variablen rein, die übergeben werden und hinten werden dann die Pfade angepasst. Vor allem stehen Variableninhalt und Dateiname nicht mehr in direktem Zusammenhang und so kann über den Dateinamen der Pfad nicht mehr manipuliert werden. Ich mach das grundsätzlich so, dass sich Variableninhalte und Dateinamen auch unterscheiden. Bei mir hieße die erste case-Zeile:
case "anfang" : $link = "./text/startseite.php"; break;
und es würde dann: index.php?site=anfang heißen und trotzdem wird die startseite.php includiert.
Am Anfang hab ich noch einen Teil drin, der filtert SQL-Befehle raus, die zur Datenbankmanipulation benutzt werden könnten, falls Datenbankabfragen auch so ungesichter per URL übergeben würden.
Macht aber bei komplexeren Seiten mehr Sinn, das als Funktion auszulagern und bei Bedarf "verdächtige" Variablen durchzuschicken. Würde jetzt aber zu weit führen.
Dieser Beitrag wurde von Holger_N bearbeitet: 24. Dezember 2010 - 00:18
#8
geschrieben 26. Dezember 2010 - 04:57
Wieso sollte man SQL-Commands raus filtern, wenn die Variable sowieso nur für das Switch benötigt wird?
$content = ''; @$_GET['site'] = trim(strtolower($_GET['site'])); switch($_GET['site']) { case 'impressum': $content = 'impressum'; break; case 'seite2': $content = 'seite2'; break; case 'seite3': $content = 'seite3'; break; [...] default: $content = 'start'; break; } @unset($_GET['site']); require_once("./sections/{$content}.php");
Dieser Beitrag wurde von [Elite-|-Killer] bearbeitet: 26. Dezember 2010 - 04:58
#9
geschrieben 26. Dezember 2010 - 11:49
Zitat ([Elite-|-Killer]: 26.12.2010, 04:57)
Wieso sollte man SQL-Commands raus filtern, wenn die Variable sowieso nur für das Switch benötigt wird?
Weil es nicht nur bei SQL Sicherheitsprobleme geben kann, wenn man nicht ordentlich filtert. Im o.g. Beispiel wurde die Variable blindlings dafür genutzt eine Datei einzubinden und auszugeben. Das klappt natürlich mit den Dateien, die eingebunden werden sollen - ganz genau so gut klappt das aber auch mit .htaccess-Dateien, config-Dateien (mit Nutzerdaten...) oder sonstigen eigentlich (hoffentlich) geschützten Daten.
#10
geschrieben 26. Dezember 2010 - 12:58
Zitat ([Elite-|-Killer]: 26.12.2010, 04:57)
Wieso sollte man SQL-Commands raus filtern, wenn die Variable sowieso nur für das Switch benötigt wird?
An der Stelle macht es natürlich keinen Sinn aber es gibt ja auch Variablen, die mit einem Datenbankeintrag in Zusammenhang stehen, Gästebuch etc. oder wenn es kein statisches Menü ist, sondern Menü-Inhalte aus einer Datenbank ausgelesen. Klar dürfte auch da von vornherein keine Variable in direktem Zusammenhang mit der SQL-Abfrage stehen aber an einer winzigen Stelle nicht aufgepasst ist ein Lücke da und es tut ja keinem weh, potentielle Gefahren vorher rauszufiltern.
Ich schrieb ja auch, dass es mehr Sinn macht, diese Filterung als Funktion auszulagern und dann immer nur die Variablen durchzuschicken, die es betrifft.
Dieser Beitrag wurde von Holger_N bearbeitet: 26. Dezember 2010 - 13:00
#11
geschrieben 27. Dezember 2010 - 04:06
Zitat (LostSoul: 26.12.2010, 12:49)
Weil es nicht nur bei SQL Sicherheitsprobleme geben kann, wenn man nicht ordentlich filtert. Im o.g. Beispiel wurde die Variable blindlings dafür genutzt eine Datei einzubinden und auszugeben. Das klappt natürlich mit den Dateien, die eingebunden werden sollen - ganz genau so gut klappt das aber auch mit .htaccess-Dateien, config-Dateien (mit Nutzerdaten...) oder sonstigen eigentlich (hoffentlich) geschützten Daten.
Es bringt aber dennoch nichts SQL-Injections auszufiltern, wenn man mit URIs arbeitet.
Zitat (Holger_N: 26.12.2010, 13:58)
Ich schrieb ja auch, dass es mehr Sinn macht, diese Filterung als Funktion auszulagern und dann immer nur die Variablen durchzuschicken, die es betrifft.
Hier sollte man sicher aber auch der eingebauten Funktionen Bedienen um SQL-Injections zu vermeiden, da die 3 Replacements zwar den Angriffsvekor etwas verkleinern, letztendlich ist das Ding aber immer noch offen wie ein Scheunentor.
#12
geschrieben 10. Januar 2011 - 15:30
Zitat ([Elite-|-Killer]: 27.12.2010, 04:06)
Hier sollte man sicher aber auch der eingebauten Funktionen Bedienen um SQL-Injections zu vermeiden, da die 3 Replacements zwar den Angriffsvekor etwas verkleinern, letztendlich ist das Ding aber immer noch offen wie ein Scheunentor.
Ja aber das doch dann wo man sich speziell um die Datenbank kümmert und nicht bei der "allgemeinen Vorfilterung". Ich hab gern eine lesbare Struktur, die ich auch noch nach einem Jahr nachvollziehen kann, ohne jede Zeile kommentieren zu müssen.
#13
geschrieben 11. Januar 2011 - 16:51
#14
geschrieben 11. Januar 2011 - 20:39
Ich realisiere das bei mir ja auch noch ganz anders und ich arbeite nunmal mit einer Art Blacklist als Vorfilter. Wenn man dann mehr als einen Schutzmechanismus drin hat, dann gibts immer Punkte, wo die sich doppeln und wo dann genau an der Stelle ein Mechanismus überflüssig ist. An anderer Stelle ist der aber wieder wichtig und einer zuviel ist ja nicht falsch, einer zu wenig ist gefährlich.
Und ganz weglassen kann man ihn nicht, als er noch nicht dabeistand hast du ja auch schon geweint.