Security Alert: Verwaiste Domains als Sicherheitsrisiko

Hanno Böck weist in seinem Aufsatz »Verwaiste Domains als Sicherheitsrisiko« auf etwas hin, das auch für Betreiber statischer Seiten eine Gefahr ist: Stellt Euch vor, Ihr habt per JavaScript einen Dienst eingebunden, der von einem entfernten Server geliefert wird, wie zum Beispiel der gerade bei statischen Seiten beliebte Kommentardienst Disqus, und dieser Dienst wird aus welchen Gründen auch immer eingestellt. Die zum Dienst gehörende URL wird von jemanden anderen gekauft und auf dem Server wird ein gleichnamiges JavaScript installiert, das statt Disqus Euch irgendetwas Bösartiges unterschiebt.

Gerade bei statischen Seiten ist man dann der Gelackmeierte. Denn während es bei Seiten, die über ein CMS dynamisch ausgeliefert werden, in der Regel ausreicht, die Templates anzupassen und schon wird Disqus nicht mehr mit ausgeliefert, muß man bei statischen Seiten unter Umständen tausende von Seiten manuell ändern (gut, man kann sich mit einem Skript behelfen, aber dennoch ist der Aufwand bedeutend größer).

Diese Gefahr ist übrigens einer der Gründe, warum icn vor Jahren Disqus den Rücken gekehrt habe und meine Kommentare nun ganz altmodisch aber hoffentlich sicher per Email an mich geschickt werden müssen, denn ich hatte schon einmal den Kollaps eines Kommentardienstanbieters er- und überlebt. (Der andere Grund war, daß ich die Kontrolle über meine Kommentare nicht einem Dienstleister überlassen wollte.)

Aber das ist ja nur die Spitze des Eisbergs: Facebook- oder Flattr-Knöpfe, Googles Karten und so vieles mehr wird über JavaScript in Seiten eingebunden und was die vielen iFrames von Amazon und Co. anstellen, weiß auch niemand wirklich. Man sollte sich wirklich genau überlegen, welche Dienste man in seine Seiten einbaut.

---

4 (Email-) Kommentare

---

»Denn während es bei Seiten, die über ein CMS dynamisch ausgeliefert werden, in der Regel ausreicht, die Templates anzupassen und schon wird Disqus nicht mehr mit ausgeliefert, muß man bei statischen Seiten unter Umständen tausende von Seiten manuell ändern (gut, man kann sich mit einem Skript behelfen, aber dennoch ist der Aufwand bedeutend größer)«.
Den Satz verstehe ich nicht. Man ändert einfach die Templates entsprechend (schmeisst die Werbung raus, macht die Buttons und den ganzen web2.0er-Blink- und Glitzerkrempel weg), löscht die erzeugten HTML-Dateien und lässt das ganze neu generieren, dabei werden die alten Inhalte mit den alten Metadaten (beides in den Markdown-Dateien abgespeichert) in das in den geänderten Templates definierte neue "Passepartout" gesetzt und fertig sind die alten Inhalte in neuem Rahmen - genau deswegen trennt man ja Inhalt und Darstellung!
Mit hugo geht das in Rekordzeit, jedes andere Framework bringt das wohl hoffentlich mindestens über Nacht fertig.
Was lästig ist beim migrieren deiner alten Seiten zu Hugo oder einem anderen Framework, dass Du erst mal die alten Inhalte aus dem div#blogpost holen und in Markdown mit korrekten shortcodes konvertieren musst.
(Oder hast du alle deine Inhalte als Markdown zur Hand, dann geht es schneller)
»Man sollte sich wirklich genau überlegen, welche Dienste man in seine Seiten einbaut.«
Möglichst wenig, sonst wird man irgendwann von den Google Webmaster Tools wegen inputs in der HTML-Seite angepupt… ;)
Mein persönlicher Held als Webminimalist ist Matthias Wandel (woodgears.ca), schon immer statisch gewesen.

– Peter F. (Kommentieren) (#)

---

Hier ist noch ein Einzeiler: curl -s http://blog.schockwellenreiter.de/2017/09/2017090703.html | pup 'div.blogpost' | pandoc -s -r html -t markdown -o 2017090703.md – https://github.com/ericchiang/pup – http://pandoc.org/
Auch da ist noch manuelle Nacharbeit nötig, denn du hast Navigationselemente (<=, =>) in das div.blogpost eingebaut anstatt darunter ins Template. Da der Kommentarlink zum Posting gehört, ist er dort richtig, der Rest nicht.
Also machbar wäre es auf jeden Fall. Nur muss man halt einmal anfangen damit ;)

– Peter F. (Kommentieren) (#)

---

Ganz so einfach ist es leider nicht. Bei mir haben 18 Jahre Schockwellenreiter zehntausende von Seiten hinterlassen, die teilweise mit Programmen herausgeschrieben wurden, die heute gar nicht mehr existieren (Frontier, RadioUserland) und auf deren (OPML-) Quellen ich auch nicht mehr zugreifen kann (sie sind schlicht und einfach mit den Programmen verschwunden). Die letzten fünf Jahre Schockwellenreiter wurden mit RubyFrontier herausgeschrieben, da habe ich alle Original-Markdown-Dateien noch. Allerdings sind auch das ca. 6.000 Postings und RubyFrontier ist nicht besonders schnell, da wird das Herausschreiben schon mehr als eine Nacht in Anspruch nehmen (vom Hochladen auf den Server will ich gar nicht erst reden). Das Besondere an RubyFrontier ist ja (und war es auch schon bei Frontier und RadioUserland), daß man einzelne Postings und Folder rendern kann und wenn man die Navigation geschickt wählt, muß man auch immer nur einzelne Dateien und nicht den ganzen Wust statisch herausrendern.
Ich habe auch andere (dienstliche) Projekte, wo es gar um hunderttausende statische Seiten geht.
Bei Hugo habe ich leider bisher nicht herausgefunden, ob man das Teil ebenfalls dazu überreden kann, nur einzelne Seiten oder Directories herauszurendern. Hugo ist schnell, ich weiß, aber wenn es jedes Mal alle Dateien herausschreibt, muß ich jedes Mal auch alle tasuende Dateien auf den Server hochladen – und das dürfte dauern.

– Jörg Kantel (Kommentieren) (#)

---

Man kann auch externe Scripte auf Prüfsummen prüfen lassen: https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity

– Martin D (Kommentieren) (#)

---

(Kommentieren)