Wie die PDF Sicherheitslücke geschlossen werden kann
3. Januar 2007 | WebDevJede 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.

5. Januar 2007 um 16:20
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.
5. Januar 2007 um 16:30
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.
7. Januar 2007 um 23:56
Adobe’s Acrobat Reader nach sinnloser Reboot-Orgie entfernt…
Gestern bin ich über eine schwere Sicherheitslücke im Acrobat Reader, oder Adobe Reader, wie er nun heißt, gestolpert. Wegen der Lücke habe ich mich dazu entschlossen, ein Update des auf meinem Laptop installierten Acrobat Readers vorzunehmen. Nac…