Benutzung

Ist die Konfiguration durch das Neuladen der Apache-Konfiguration oder den schlichten Neustart des Dienstes aktiviert, kann das Modul bereits benutzt werden. Listing 2 zeigt ein Beispiel in PHP. Der Interpreter prüft auch hier die hypothetische Bedingung »$bedingung« . Erfreulicherweise muss die Größe der Datei nicht mehr ermittelt werden, da Mod-Xsendfile dies selbst übernimmt. Die zwei zusätzlichen Header stellen einen forcierten Download sicher und verhindern eine eventuelle Browser-interne Darstellung der Datei.

Listing 2

Header setzen

<?php
if ($bedingung == true) {
        header('X-Sendfile: '.$datei);
        header ('Content-Type: application/octet-stream');
        header ('Content-Disposition: attachment; filename='.$dateiname );
        exit;
}
?>

Wichtig ist bei der Arbeit mit Headern, dass vor dem Senden des Headers nicht bereits eine Auslieferung normaler Daten (HTML/CSS und so weiter) an den Browser erfolgt, da dieser dann weitere Header nicht mehr akzeptieren würde beziehungsweise der Interpreter mit einer Warnung im Stile "Headers already sent" das Senden der Header verweigert.

Benutzer von Rails haben es auf Wunsch durch das optionale Rails-Plugin XsendFile [4] noch einfacher als PHP-Entwickler. XSendFile wird in einem bestehenden Rails-Projekt installiert über »ruby script/plugin install http://john.guen.in/svn/plugins/x_send_file« . Mit dem Plugin kann über die Rails-typische Syntax die Auslieferung per Mod-Xsendfile mit nur einer Zeile initiiert werden. Im Listing 4 ist ein einfacher und ein erweiterter Aufruf mit optionaler Parameter-Übergabe gegenübergestellt. Letzterer erzwingt die Auslieferung eines Bildes und dessen Darstellung im Browser. Auf diese Weise ist zum Beispiel die Umsetzung einer Bilder-Galerie möglich. Natürlich ist es nicht möglich, wie im Listing dargestellt, zwei Dateien nacheinander in einem Script auszuliefern.

x_send_file('/pfad/zur/datei')
x_send_file('/pfad/zu/bild.jpg', :type => ↩
'image/jpeg', :disposition => 'inline')

Es ist zu erkennen, dass Rails-XSendFile letztlich nur die Syntax verkürzt. Eine eigene Methode kann diese Aufgabe ebenso gut übernehmen – in jeder Skriptsprache – und so für eine praktische, einzeilige Handhabung von X-Sendfile ermöglichen.

Sicherheit

Ob Mod-Xsendfile ein Risiko für die Sicherheit des Webservers darstellt, liegt ganz im Auge des Betrachters. Da es bei unzureichender Konfiguration theoretisch möglich ist, alle vom Apache lesbaren Dateien über das Modul auszuliefern, kann der Gebrauch durchaus als riskant verstanden werden. So ist es theoretisch möglich, Dateien mit Datenbank-Kennwörtern und ähnliches ausliefern zu lassen. Voraussetzung dafür allerdings ist, dass der Angreifer per Skriptsprache auf dem Server Header setzen kann. Auf einem Webserver mit einer nicht überschaubaren Nutzerzahl sollte man also auf den Einsatz des Moduls besser verzichten oder das Modul extrem restriktiv konfigurieren.

Auf einem abgesicherten Projekt- oder Unternehmensserver sieht die Situation anders aus: Solange man nicht der Fehler begeht, Mod-Xsendfile einen POST- oder GET-Parameter mehr oder weniger direkt als Dateinamen unterzuschieben, ist es für einen Angreifer nicht mehr trivial, die Auslieferung einer bestimmten Datei zu forcierten. Chroot-Umgebungen für Apache und die weiteren üblichen Maßnahmen wie mod_security können den Einsatz des Moduls kalkulierbar machen. Es gilt die Faustregel: Mod-Xsendfile nur in kontrollierten Umgebungen mit ausreichender Syntax-Prüfung einsetzen.

Ähnliche Artikel

comments powered by Disqus
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Ausgabe /2023