php include und Dateiendung

Sven · 09.07.2006, 16:29

Moinsen,

wenn ich Teile des Quellcodes in eine HTML Seite mittels

PHP-Code:


			
<?php require_once('dateiname.html'); ?>

einbinde, muss ich die HTML-Datei dann zwingend mit der Endung .php abspeichern oder geht auch eine andere Dateiendung?

Inwieweit würden sich diese Endungen denn auf Suchmaschinen auswirken?

Bin für jede Antwort dankbar

Gruß
Sven

manuelito · 09.07.2006, 16:35

Nope, jede Endung funktioniert. Für die Sumas ist das auch nicht relevant, denn sie sehen nur die Seite von der aus du diese Datei includierst, denn sie wird schon vor dem Ausliefern an den Client integriert ( also serverseitig ).

cu

edit: nochmal zur Verdeutlichung:

PHP-Code:


			
// Hauptseite.php

<html><head> ..etc

<?php include("ismiarwurschwieichhaiss.foo"); ?>

</html>



// ismiarwurschwieichhaiss.foo : inhalt

<b>ich bin content in ismiarwurschwieichhaiss.foo </b>



// suma sieht Hauptseite.php mit Inhalt



<html><head> ..etc

<b>ich bin content in ismiarwurschwieichhaiss.foo </b>

</html>

Sven · 09.07.2006, 16:47

danke für die Antwort aber anscheinend habe ich mich schlecht ausgedrückt.

Ich meinte die Datei, bei der ich den PHP-Befehl eintrage und nicht die Datei, die ich einbinden möchte.

Aber wenn ich dein Beispiel richtig verstehe mit "Hauptseite.php" geht es wohl nur mit dieser Dateiendung.

Gruß
Sven

manuelito · 09.07.2006, 19:02

Achso! Ja PHP kannst du natürlich nur in PHP Seiten ausführen, normalerweise geht das nur mit der Endung .php

Es gibt da allerdings einen kleinen Trick, mit dem man PHP für alle möglichen Dateitypen aktivieren kann. Und zwar kannst du folgendes in eine .htaccess Datei schreiben:

AddType application/x-httpd-php php php4 php3 html htm gaga tpd xyz abc

Sollte für die Sumas kein Problem darstellen, solange du die Seiten als text/html oder wie auch immer lesbar auslieferst.

cu

PS: dein Server muss natürlich dieses .htaccess Zeug unterstützen... geht nicht überall gleich.

Sven · 09.07.2006, 19:36

OK, nochmals danke.

Dann hatte ich das ja doch richtig in Erinnerung gehabt, dass so etwas möglich ist.

Gruß
Sven

marc22 · 10.07.2006, 13:36

Wenn man solche htaccess-Tricks benutzt kann das aber auch nach hinten los gehen, wenn man den Auftritt mal portieren möchte...

Adromir · 10.07.2006, 13:42

Wobei es nicht unbedingt zu empfehlen ist, dateien zu includieren, die bei einem direktaufruf selbst nicht geparst werden. Denn dadurch kommt man schnell an den Quelltext eines Scriptes (naja in Teilen).

Ist nicht unbedingt schlimm, es kann einem Hacker aber helfen ggf. Schwachstellen schneller zu identifizieren. Und wenn man es ganz dumm macht, schreibt man in diese andere Datei noch die Datenbankzugangsdaten oder FTP- Passwörter rein.. Deswegen ist es eher üblich zu inkludierende Dateien nach dem schema "dateiname.inc.php" zu bennen.. Einmal um mit dem inc anzuziegen, daß die Datei includiert wird und zum zweiten einen Zugriff auf den Quelltext zu verhindern..

Torsten · 10.07.2006, 14:43

Zitat:

Zitat von Poloatze

Moinsen,

wenn ich Teile des Quellcodes in eine HTML Seite mittels

PHP-Code:


			
<?php require_once('dateiname.html'); ?>

einbinde, muss ich die HTML-Datei dann zwingend mit der Endung .php abspeichern oder geht auch eine andere Dateiendung?

Inwieweit würden sich diese Endungen denn auf Suchmaschinen auswirken?

Bin für jede Antwort dankbar

Gruß
Sven

Probier doch mal ob dein Server *.shtml Dateien unterstützt.
Falls ja kannst Du mit SSI (Server Side Includes ) arbeiten.

Alle Dateien heißen dann anstelle von *.htm oder *.html eben *.shtml
Ein Server Side Include wird wie folgt eingebunden:

HTML-Code:

<!--#include file="popup.html" -->

Grüße Torsten

GodfatherDeluxe · 10.07.2006, 14:46

Zitat:

Zitat von Adromir

Wobei es nicht unbedingt zu empfehlen ist, dateien zu includieren, die bei einem direktaufruf selbst nicht geparst werden. Denn dadurch kommt man schnell an den Quelltext eines Scriptes (naja in Teilen)

deshalb in jedem fall auf produktiv servern "display_errors" deaktivieren und
"log_errors" aktivieren

außerdem, falls man doch eine "nicht-php"-endung verwenden will, direkte aufrufe folgendermaßen in der .htaccess unterbinden

Zitat:

allerdings, wenn der webserver ein shared host ist, ist man nie 100% sicher, wie mans auch dreht oder wendet (da machts dann auch keinen unterschied ob die endung jetzt php oder inc oder was auch immer ist):

Zitat:

In addition to being able to read arbitrary files on a shared host, an attacker can also create a script that browses the filesystem. This type of script can be used to discover the location of your source code because your most sensitive files are not likely to be stored within document root. An example of such a script follows:

Code:

    <?php

    if (isset($_GET['dir']))
    {
      ls($_GET['dir']);
    }
    elseif (isset($_GET['file']))
    {
      cat($_GET['file']);
    }
    else
    {
      ls('/');
    }

    function cat($file)
    {
      echo htmlentities(file_get_contents($file), ENT_QUOTES, 'UTF-8'));
    }

    function ls($dir)
    {
      $handle = dir($dir);

      while ($filename = $handle->read())
      {
        $size = filesize("$dir$filename");

        if (is_dir("$dir$filename"))
        {
          $type = 'dir';
          $filename .= '/';
        }
        else
        {
          $type = 'file';
        }

        if (is_readable("$dir$filename"))
        {
          $line = str_pad($size, 15);
          $line .= "<a href=\"{$_SERVER['PHP_SELF']}";
          $line .= "?$type=$dir$filename\">$filename</a>";
        }
        else
        {
          $line = str_pad($size, 15);
          $line .= $filename;
        }

        echo "$line\n";
      }

      $handle->close();
    }

    ?>

An attacker might first view /etc/passwd or a directory listing of /home to get a list of usernames on the server. It is then trivial to browse a user's source code within the user's document root; the location of source code stored outside of the user's document root is revealed by language constructs such as include and require. For example, consider discovering the following script at /home/victim/public_html/admin.php:

Code:

    <?php

    include '../inc/db.inc';

    /* ... */

    ?>

If an attacker manages to view the source of this file, the exact loction of db.inc is discovered, and the attacker can use readfile( ) to expose the contents, revealing the database access credentials. Thus, the fact that db.inc is stored outside of document root offers subpar protection in this environment.

This particular attack illustrates why you should consider all source code on a shared server to be public, opting to store all sensitive data in a database.

Shiflett, Chris: Essential PHP Security, O'Reilly 2005

glowy · 10.07.2006, 17:27

Zitat:

PHP-Code:


			
// Hauptseite.php
<html><head> ..etc
<?php include("ismiarwurschwieichhaiss.foo"); ?>
</html>

// ismiarwurschwieichhaiss.foo : inhalt
<b>ich bin content in ismiarwurschwieichhaiss.foo </b>

// suma sieht Hauptseite.php mit Inhalt

<html><head> ..etc
<b>ich bin content in ismiarwurschwieichhaiss.foo </b>
</html>

Zu beachten ist aber noch, dass man das in der datei.inc.php, sprich in der includierten Datei nicht nochmal mit den einzelnen HTML-Elementen, falls vorhanden, bestückt, denn dann könnte es vorkommen, dass die Seite nicht mehr valid ist. Zum Beispiel darf nicht in der haupseite.php UND der include.php "<html>" stehen, da dann das aus "include.php" auch in der hauptseite.php steht.
Ein kleiner Trick zur Dateiendung: Die includeten Dateien können heißen wie sie wollen in PHP, könnte man auch include.mp3 nennen, das hat den Vorteil, dass der Browser beim Öffnen ohne Include, kann ja sein das man die Datei nach langem Suchen als Externer auf dem Server findet, den Media Player startet und dann versucht das includete wiederzugeben, was natürlich nicht geht.

Viele Grüße

rewboss · 10.07.2006, 17:54

Zitat:

Zitat von Adromir

Wobei es nicht unbedingt zu empfehlen ist, dateien zu includieren, die bei einem direktaufruf selbst nicht geparst werden. Denn dadurch kommt man schnell an den Quelltext eines Scriptes (naja in Teilen).

Wobei es schon dann zu Problemen kommen kann, weil der Code ausgeführt wird, wenn er geparst wird. Wenn ein Fremder z.B. weiß, dass datenbank-zugriff.inc.php Zugriff auf die Datenbank erlaubt, kann er eben diese Datei selbst includen -- und es ist ihm egal, ob er den Quellcode sehen kann oder nicht. Wenn er überhaupt weiß, wie solche Dateien heißen und in welchem Ordner sie sich befinden, ist es u.U. bereits zu spät, wenn der Code von der Sicherheit her schlampig geschrieben ist.

Deshalb: direkten Zugriff von anderen Servern unterbinden, Verzeichnisse mit sicherheitsrelevanten Dateien schützen (u.a. auch die Auflistung der dort befindlichen Dateien deaktivieren), usw.

Sven · 11.07.2006, 11:12

huch, die Diskussion geht ja noch weiter

Zitat:

Zitat von Adrmoir

Wobei es nicht unbedingt zu empfehlen ist, dateien zu includieren, die bei einem direktaufruf selbst nicht geparst werden. Denn dadurch kommt man schnell an den Quelltext eines Scriptes (naja in Teilen).

Das macht überhaupt nichts wenn der Quelltext lesbar ist. Mir geht es nur darum, dass ich nicht immer alles von Hand ändern muss. Vorher habe ich das alles noch mit der Vorlagenfunktion von DW bearbeitet; allerdings spinnt DW manchmal bei der Siteverwaltung bei einem Neuaufspielen des Systems. Außerdem spare ich beim Einbinden mittels .include Funktion ein bisschen Webspace.

Zitat:

Zitat von Torsten

Probier doch mal ob dein Server *.shtml Dateien unterstützt.
Falls ja kannst Du mit SSI (Server Side Includes ) arbeiten.

Habe ich schon probiert gehabt. Es funktioniert jedoch nicht.

Gruß
Sven

Torsten · 11.07.2006, 11:37

Falls Du noch anderen Webspace zur Verfügung hast bei dem Du evtl. ein wenig mehr Features inkl. hast, dann könntest Du ja eine Umleitung einrichten und somit trotzdem mit Include-Variablen arbeiten.

Ansonsten müsste es doch auch eine Möglichkeit via Java/JavaScript geben, denn es gibt ja sogar kleinere Shopsysteme die auf dieser Basis aufgebaut sind.

Apropos Dreamweaver-Synchronisation:
Mit welcher Version arbeitest Du und was funktioniert da nicht, ist eigentlcih ab Version MX 6.0 recht zuverlässig

Sven · 11.07.2006, 13:12

Zitat:

Ansonsten müsste es doch auch eine Möglichkeit via Java/JavaScript geben, denn es gibt ja sogar kleinere Shopsysteme die auf dieser Basis aufgebaut sind.

Java Script wollte ich nicht verwenden.

Zitat:

Mit welcher Version arbeitest Du und was funktioniert da nicht, ist eigentlcih ab Version MX 6.0 recht zuverlässig

DW8. Die Dateien werden zwar alle schön in dieser Dateienliste angezeigt aber wenn er dann aktualisieren soll funktioniert das nicht immer 100 %ig. Manche Dateien lässt er außen vor bei der Aktualisierung. Das liegt aber an irgend einem Programm das ich installiert habe. Wenn ich DW gleich am Anfang nach dem Aufspielen von Windows installiere funktioniert es einwandfrei. Mit der Zeit ist es aber auch nervig, dass man ständig diese Nachfrage bekommt, ob man nun alle Dateien aktualisieren möchte oder nur einen Teil.

Zitat:

Falls Du noch anderen Webspace zur Verfügung hast bei dem Du evtl. ein wenig mehr Features inkl. hast, dann könntest Du ja eine Umleitung einrichten und somit trotzdem mit Include-Variablen arbeiten.

Ich hab' gerade mal in meine Webspacebeschreibung geschaut und da ist SSI doch angegeben. Naja, dann weiß ich nicht was ich falsch gemacht habe. Es spielt doch keine Rolle, wenn die include-Dateien in einem Extraordner gespeichert sind, oder? Die Einbindung habe ich jedoch mit "virtual" versucht anstelle von "file". Beim Server handelt es sich um einen Apache. Ich probier das die Tage noch einmal.

Gruß
Sven