Wie die PDF Sicherheitslücke geschlossen werden kann

Jede Website, die mindestens ein PDF-Dokument hostet ist anfällig für Cross-Site-Scripting (XSS)! Genauer gesagt kann überall wo ein PDF-File gespeichert ist beliebiger Javascript-Code injected werden.

Der Code um die Sicherheitslücke auszunützen ist simpel. Hier ein Beispiel wie von pds.nasa.gov auf anty.at weitergeleitet wird:

http://pds.nasa.gov/documents/psdd/psdd.pdf#h=javascript:
document.location.href%3D%22http%3A//www.anty.at%22%3B

Wenn man den Link aufruft wird man durch diesen Anhang weitergeleitet:

#h=javascript:document.location.href%3D
%22http%3A//www.anty.at%22%3B

Decodiert:

#h=javascript:document.location.href="http://www.anty.at";

Mit diesem Beispiel ist schnell klar, das von nahezu jeder beliebigen Seite auf eigene Seiten weitergeleitet werden kann. Wenn man sich so eine URL in einer Phishingmail vorstellt, kann man schnell das Ausmaß des Problems erkennen.
Aber dabei muss es leider nicht bleiben: Man könnte auch Logindaten von Cookies auslesen und per Ajax an eine Datenbank übermitteln, während das Opfer das PDF-Dokument ließt! Opfer dieser Attacke würden Nichts davon mitbekommen, solange sie keinen Blick in die Adressleiste werfen – und dann ist es warscheinlich schon zu spät.

Selbst wenn Adobe schnell einen Fix dafür bereit stellt wird diese Schwachstelle wahrscheinlich noch lange ausgenützt werden. Solange es Benuzter gibt, die einen ungepatchten Acrobat Reader verwenden, wird die Sicherheitslücke bestehen bleiben.
(Ich gehe davon aus, dass das Problem beim Client und nicht beim Dokument liegt.)

Wie der PDF Exploit am Server gefixt wird

Update: Sorry, ich war wohl etwas vorschnell, hier eine zweite Version die eigentlich gut funktionieren sollte, aber leider einen großen Aufwand für Webmaster darstellt:

Wenn man alle PDF-Dateien in einem geschützten Verzeichnis speichert, kann man eine Datenbank anlegen, in der mittels eines Queries (z.B.: index.php?pdfid=5) die PDF-Datei ausgewählt wird. Dann muss man folgenden Header senden, der das inline-öffnen im Browserfenster verhindert:

Content-Disposition: attachment; filename="presentation.pdf"

Ein kleines (und diesmal auch getestetes) PHP-Codeschnippsel dazu:

<?php
if ($_REQUEST['pdfid'] == 1) {
header('Content-Type: application/octet-stream');
header('Content-Disposition: attachment; filename="presentation.pdf"');
readfile('hidden-pdf-file.pdf');
} else {
header('HTTP/1.0 404 Not Found');
}
?>

Das sollte sich auch im Apache Config File oder in einem htaccess-File einstellen lassen.

Veröffentlicht am
Kategorisiert in WebDev

3 Kommentare

  1. An Deiner Stelle hätte ich es vielleicht getestet. Oder die Meldungen zum Sicherheitsloch gelesen. 🙂

    Der # ist Sache des Clients. Der Server bekommt das nicht mit. Eine RewriteRule hilft dagegen nicht, weil der Teil der URL nicht an den Server übergeben wird.

    Betroffen ist übrigens nur das Plugin von Adobe. Es gibt andere Methoden PDFs zu lesen, die schneller und sicherer sind. Andere Reader, oder PDFs gleich nur extern öffnen.

    Wie auch immer: Das Problem muss auf der Clientseite gelöst werden.

    Oder man verzichtet in Zukunft auf unnötige PDF. Sicher 95 % aller PDFs im Web sind sinnloser Medienbruch.

  2. Hehe, vielen Dank für’s Kommentar. Jetzt ist mir auch klar, warum bei meinen PHP-Tests alles nach dem #-Symbol verschluckt wurde…
    Peinlich, dass mir das nicht vorher aufgefallen ist… ich wahr wohl zu fixiert von der Idee eine Lösung für das Problem gefunden zu haben :/
    Ich werde einen Hinweis in den Post hinzufügen.

  3. Pingback: Mein Parteibuch

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.