Content Security Policy: Schutz vor Cross-Site-Scripting

Mithilfe von Cross-Site-Scripting (XSS) lässt sich Böses mit einer Website anstellen. Eine ganze Menge Massnahmen helfen, XSS auf der eigenen Website zu verhindern. Eine dieser Möglichkeiten nennt sich Content Security Policy (CSP). Wir zeigen heute, was CSP ist, wie Sie für Ihre Website eine Policy definieren können und welche Stolperfallen lauern.

Helm auf! Eine Content Security Policy schützt vor Cross-Site-Scripting

Helm auf! Eine Content Security Policy schützt vor Cross-Site-Scripting

Wie es zur Content Security Policy kam

Content Security Policy (CSP) ist ein Konzept, um das Einschleusen von fremden Daten auf einer Website zu verhindern. Damals noch unter dem Namen «Content Restrictions» wurde das Konzept im Jahr 2004 erstmals von Robert Hansen vorgeschlagen. Als erster Browser unterstützte Firefox 4 die Content Security Policy, andere Browserhersteller zogen bald nach. Im Jahr 2012 wurde dann die erste Version, Content Security Policy 1.0 genannt, als «Candidate Recommendation» vom W3C publiziert. Mittlerweile wird bereits an der dritten Version, der Content Security Policy Level 3, gearbeitet.

So give it another year or so and we should have a workable defense against XSS on pages that must allow user submitted HTML and JavaScript – think eBay, MySpace, and so on.

— Quelle: ha.ckers.org via archive.org

War zu den Anfägen von CSP das Problem Cross-Site-Scripting noch ein Ding von Anbietern wie eBay oder MySpace, ist heutzutage praktisch jede Website potentiell anfällig auf Cross-Site-Scripting. Mit einer Content Security Policy lässt sich sehr genau definieren, aus welchen Quellen Inhalte geladen werden dürfen. Das schafft Sicherheit, führt früher oder später aber in eine Zwickmühle, wie sich gleich zeigen wird.

Wie definiere ich eine Content Security Policy?

Die CSP einer Website wird vorzugsweise im HTTP-Header definiert, kann aber auch als Meta-Tag direkt im Markup hinterlegt sein. Die Meta-Tag-Methode eignet sich vor allem für einzelne Seiten, für die spezielle Regeln gelten sollen. In unseren Beispielen wählen wir die HTTP-Header-Methode, die sich dank mod_headers bequem über die .htaccess-Datei steuern lässt. Alternativ können HTTP-Header auch direkt mithilfe von PHP-Code definiert werden.

Eine simple Content Security Policy liesse sich zum Beispiel mit folgender Anweisung in der .htaccess-Datei definieren:

Header set Content-Security-Policy "default-src 'self';"

Mit dieser CSP sind auf der entsprechenden Website nur noch Inhalte erlaubt, die auch über die aufgerufene Domain geladen werden. Externe und Inline-Scripts werden so verboten. Nutzen Sie auf Ihrer Website Scripts wie Google Analytics oder haben mit <script> im HTML-Markup Funktionen definiert, würden diese mit der gesetzten Policy nicht mehr funktionieren. Eine Lockerung der Regeln muss also her.

Mit

Header set Content-Security-Policy "default-src 'self' www.google-analytics.com;"

erlauben Sie zusätzlich zur eigenen Domain Inhalte, die über den Hostnamen www.google-analytics.com eingebunden sind.

Google Analytics generiert selbst Inline-Scripts. Erweitern wir die Regel noch mit 'unsafe-inline' sind auch Inline-Inhalte wieder erlaubt:

Header set Content-Security-Policy "default-src 'self' 'unsafe-inline' cdn.example.com;"

Aber Achtung: Der Befehl 'unsafe-inline' hebelt den Hauptnutzen einer Content Security Policy aus. Damit ist nämlich das Einschleusen von Code, also Cross-Site-Scripting, wieder möglich. Und hier beginnt die oben erwähnte Zwickmühle, denn Tools wie Google Analytics funktionieren nur, wenn Inline-Scripts erlaubt sind. In vielen Fällen kann man damit das Thema CSP bereits abhaken.

Doch nicht nur Inline-Scripts machen in Verbindung mit einer Content Security Policy Probleme. Viele Scripts wie z.B. Widgets von Facebook oder Twitter sind darauf angewiesen, dass Code aus Drittquellen geladen werden darf. Die Adressen dieser Quellen müssen wiederum in der eigenen Policy freigeschaltet sein, damit der Browser den angeforderten Code zulässt. Da sich diese Hostnamen aber immer wieder einmal ändern und die Anbieter nur selten alle eingesetzten Adressen kommunizieren, wird eine strikte Content Security Policy früher oder später dazu führen, dass eingebundene Scripts nicht mehr wie gewünscht funktionieren. Im schlimmsten Fall wird eine Website damit unbenutzbar.

Zwischenschritt Reporting

Sie sehen, eine sinnvolle Content Security Policy benötigt etwas Arbeit. Es empfiehlt sich, die geplanten Regeln ausführlich zu testen, bevor sie im Livebetrieb eingesetzt werden. Zum Glück liefert CSP eine dazu passende Funktion mit. Mit Content-Security-Policy-Report-Only ahndet der Browser allfällige Policy-Verstösse nicht, sondern gibt entsprechende Fehlermeldungen in der Browserkonsole aus. So liesse sich also mit der Regel

Header set Content-Security-Policy-Report-Only "default-src 'self' 'unsafe-inline' cdn.example.com;"

die geplante Policy zuerst einmal auf Herz und Nieren prüfen.

CSP-Verstosse werden in der Browserkonsole angezeigt.

CSP-Verstosse werden in der Browserkonsole angezeigt.

Content-Security-Policy-Report-Only kann nicht nur Meldungen im Browser ausgeben, sondern auch Policy-Verstösse im JSON-Format an einen Endpunkt melden. Wer sich nicht die Mühe machen will, einen eigenen Endpunkt zu programmieren, findet unter report-uri.io einen tollen, kostenlosen Service, der nebst anderen praktischen Tools zum Thema CSP einen solchen Reporting-Endpunkt zur Verfügung stellt.

Einmal Upgrade bitte

Seit verschlüsselte Verbindungen zunehmend zum Standard werden, rückt eine CSP-Direktive ins Scheinwerferlicht. Mit upgrade-insecure-requests lassen sich unsichere, über HTTP eingebundene Quellen automatisch auf die sichere Variante HTTPS upgraden. Wird mit Header set Content-Security-Policy "upgrade-insecure-requests;" die Direktive gesetzt, lädt der Browser sämtliche Inhalte über HTTPS, selbst wenn diese «nur» über HTTP eingebunden sind. Zurzeit unterstützen Chrome, Firefox und Opera diese Funktion. IE-, Edge- und Safari-Nutzer bleiben vorerst aussen vor.

Browserunterstützung von upgrade-insecure-requests

Browserunterstützung von «upgrade-insecure-requests». Quelle: caniuse.com

Sicherheit für Besucher

Eine ausgeklügelte Content Security Policy bietet umfassende Möglichkeiten, Besucher Ihrer Website vor bösen Angriffen zu schützen. Sie schützt jedoch nicht, wenn Angreifer Zugriff auf Ihr Webhosting erlangen. Die CSP ersetzt also nicht die Pflege des eingesetzten Content-Management-Systems und das Schliessen von allfälligen Sicherheitslücken.

Möchten Sie eine Content Security Policy für Ihre Website implementieren? Im Netz finden Sie viel interessante Lektüre dazu. Als Startpunkt empfehlen wir die Website content-security-policy.com, das Mozilla Developer Network (MDN), html5rocks.com oder diesen Blogbeitrag von Diogo Mónica.

Static Site Generators: Schnelle und sichere Websites

Über Flat-File-CMSe haben wir an dieser Stelle bereits mehrmals geschrieben. Sie sind eine gute Alternative zu den bekannten Content-Management-Systemen, die auf eine Datenbank angewiesen sind. Einen Schritt weiter als Flat-File-Systeme gehen Static Site Generators.

Static Site Generators: Schnelle und sichere Websites

Static Site Generators: Schnelle und sichere Websites

Wie funktionieren Static Site Generators?

Im Gegensatz zu einem datenbankbasierten CMS, bei dem Inhalte in der Datenbank gespeichert sind und mittels einer Scriptsprache (wie z.B. PHP) als HTML aufbereitet werden, findet die «Herstellung» einer Website bei Static Site Generators in der Regel auf dem eigenen Computer statt. Alle nötigen Teile der Website sind in einem lokalen Verzeichnis gespeichert und werden vom Static Site Generator aufbereitet. Als Produkt spuckt der Generator dann fixfertige HTML-Dateien aus, die nur noch auf einen passenden Webhosting-Account kopiert werden müssen. Damit entfällt die Rechenarbeit für den Webserver, was sich sehr positiv auf die Ladezeiten einer Website auswirkt.

Static Site Generators werden auf der Kommandozeile bedient und Inhalte in der Regel in Markdown geschrieben. Anhand von Meta-Daten am Anfang einer Datei, «Front Matter» genannt, baut der Generator die Website auf.

Wann macht der Einsatz eines Static Site Generators Sinn?

Der Einsatz eines Static Site Generators bietet sich in vielen Fällen an. Allen voran fürs Bloggen. Die meisten der erhältlichen Generatoren sind denn auch für den Aufbau eines Blogs entwickelt worden und bieten entsprechend umfassende Optionen an. Nicht nur Blogs, auch Websites für KMU lassen sich mit Static Site Generators problemlos umsetzen. Nicht zuletzt eignen sich Dokumentationen und Hilfetexte ebenfalls sehr dafür, mit einem Generator gepflegt zu werden. Schliesslich ändert sich der Inhalt solcher Texte nicht allzu oft und auch für Hilfesuchende ist ein schneller Seitenaufbau ein wichtiger Faktor.

Wann macht ein Content-Management-System Sinn?

Genauso, wie ein mächtiges Content-Management-System nicht für jeden Einsatzzweck geeignet ist, sind auch Static Site Generators nicht immer die richtige Wahl. Publizieren Sie mehrmals täglich neue Beiträge auf Ihrem Blog, sammeln sich mit der Zeit eine Menge Inhalte an. Ein Site Generator muss so mehrmals am Tag die Webdateien neu generieren. Aufgrund der grossen Anzahl an Beiträgen dauert dieser Vorgang zudem immer länger. In vielen Fällen ist dann die Wahl eines Systems wie WordPress empfehlenswert. Wird Ihr Blog ausserdem von technisch weniger versierten Personen mit Inhalten gefüllt, macht der Griff zu einem System mit grafischer Oberfläche meistens mehr Sinn.

Sind die Inhalte Ihrer Website in einer komplexen Struktur organisiert, müssen verschiedene Benutzerrollen definiert sein oder viele verschiedene Sprachen abgedeckt werden, empfiehlt sich fast immer ein Content-Management-System. Für solche Aufgaben sind Static Site Generators schlichtweg nicht vorgesehen. Was aber natürlich nicht heisst, dass mit Site Generators keine komplexen Websites machbar sind.

Static Site Generator oder CMS?

Schlussendlich lässt sich mit ein paar wenigen Fragen schnell eruieren, ob es für das nächste Projekt ein Generator oder doch ein umfangreicheres CMS sein soll:

  • Wird die Website mehrmals täglich aktualisiert?
  • Werden Funktionen benötigt, die nicht durch einen Drittanbieter zur Verfügung gestellt werden (Kommentare, Formulare, Suche) oder ist der Einsatz von Drittanbietern z.B. aus Datenschutzgründen ausgeschlossen?
  • Wird die Website von technisch weniger versierten Benutzern verwaltet oder sind verschiedene Benutzerrollen und Workflows vorgesehen?

Lautet die Antwort auf eine dieser Fragen «Ja», ist ein Content-Management-System die bessere Wahl. In allen anderen Fällen lohnt sich der Blick auf einen der zahlreichen Static Site Generators.

Für jeden Einsatzzweck der passende Generator

Die Auswahl an Static Site Generators ist unglaublich gross. Die Website StaticGen bietet einen Überblick über die bei GitHub erhältlichen Open-Source-Generatoren. Wir stellen hier einige Vertreter kurz vor:

  • Jekyll
    Der vom GitHub-Gründer ins Leben gerufene Generator ist in Ruby geschrieben und setzt auf die Template-Engine Liquid. Jekyll ist das WordPress unter den Static Site Generators, was die Verbreitung angeht.
  • Exposé
    Das Bash-Script Exposé verwandelt Fotos und Videos in wunderschöne Foto- bzw. Videoessays.
  • Middleman
    Middleman ist äusserst vielseitig einsetzbar, bietet zahlreiche Plugins und ist ebenfalls in Ruby geschrieben. Der E-Mail-Marketing-Anbieter MailChimp verwendet Middleman für seine Website.
  • Metalsmith
    Metalsmith ist in JavaScript geschrieben und eigentlich viel mehr als «nur» ein Static Site Generator. Bei Metalsmith sind alle Funktionen als Plugins konzipiert, die sich dann auf ein Verzeichnis und die darin enthaltenen Inhalte anwenden lassen. Die Möglichkeiten sind damit fast unbegrenzt.
  • Hugo
    Hugo, in der von Google entwickelten Sprache Go geschrieben, ist auch auf Windows-Computern sehr einfach zu installieren und generiert Websites, Blogs, Dokumentationen oder Portfolios in Windeseile.
  • Sculpin
    Sculpin ist in PHP geschrieben und eignet sich damit vor allem für PHP-Entwickler, die Sculpin in der beliebten Skriptsprache erweitern möchten.
  • Pelican
    Der Vertreter für alle Python-Liebhaber setzt auf die Template-Engine Jinja2 und kann Inhalte aus WordPress oder RSS-Feeds importieren.

Accelerated Mobile Pages: Weg mit dem Speck

Im vergangenen Oktober hat Google das Projekt Accelerated Mobile Pages (AMP) vorgestellt, das die Performance im mobilen Web dramatisch verbessern soll. Plattformen wie Twitter, LinkedIn oder Pinterest haben zur gleichen Zeit ihre Unterstützung angekündigt. AMP-Inhalte sollen ab Februar 2016 in den mobilen Suchresultaten von Google auftauchen. Wir erklären was AMP ist und für wen die Technik interessant ist.

Accelerated Mobile Pages (AMP)

Was ist AMP?

Das AMP-Projekt wurde von Google ins Leben gerufen, um Webinhalte schneller an Benutzer liefern zu können. Das Projekt macht sich dabei eine Light-Version von HTML zu Nutze, dem sogenannten «AMP HTML». AMP soll für statische Inhalte wie News-Artikel oder Blogbeiträge zum Einsatz kommen und gilt damit als Antwort auf Facebook Instant Articles. Im Gegensatz zu Facebook Instant Articles ist AMP open-source und wird von weiteren Plattformen wie Twitter, Pinterest oder LinkedIn unterstützt.

Facebook hat gestern angekündigt, dass das Instant Articles-Programm ab 12. April 2016 für alle Facebook-Seiten geöffnet wird.

Wo kommt AMP zum Einsatz?

Google will AMP nutzen, um Inhalte direkt in den Suchresultaten der eigenen Suchmaschine einzubinden. Die Vorschau von AMP-Inhalten wird dabei vor allen anderen Resultaten in Form eines Karussells angezeigt. Ähnlich werden sich Plattformen wie Twitter verhalten. AMP-Inhalte können damit ohne Weiterleitung direkt in der entsprechenden App angezeigt werden. Ein Segen für das Nutzererlebnis.

Zusätzlich betreibt Google das AMP CDN, ein Content-Delivery-Network, das AMP-Inhalte weltweit verteilt und bereithält, um die Ladezeiten für Besucher weiter zu optimieren. Im Gegensatz zum restlichen Projekt ist AMP CDN nicht open-sourced und Informationen zum System sind noch spärlich gesät. Ob Twitter und Co. eigene CDNs für AMP-Inhalte bereitstellen werden, ist noch offen.

Strikte Diät, mehr Performance

Um die Performance von AMP-Inhalten hoch zu halten, sind die Möglichkeiten von AMP HTML und der zentralen JavaScript-Bibliothek AMP JS begrenzt. So sind in AMP-Dokumenten neben AMP JS externe Scripts nur erlaubt, wenn diese asynchron geladen werden. Zudem sind nicht alle CSS-Anweisungen erlaubt, müssen inline eingebunden sein und dürfen eine Gesamtgrösse von 50 kB nicht überschreiten. AMP-Inhalte unterliegen also einer strikten Diät.

Soll ich meine Inhalte als AMP anbieten?

Der zunehmenden Konzentration von Inhalten auf Plattformen wie Facebook, Twitter oder Google stehen vor allem jene Unternehmen kritisch gegenüber, die mit Online-Werbung ihr Geld verdienen. Die Möglichkeit, eigene Inhalte zu monetarisieren, ist sowohl bei Facebook Instant Articles als auch bei Accelerated Mobile Pages ein zentraler Bestandteil.

AMP macht für Websites Sinn, die Inhalte wie News-Artikel oder Blogposts anbieten. Wer jetzt schon AMP-Versionen seiner Inhalte bereitstellt, erhält die Chance, zuoberst in den Google-Suchresultaten aufzutauchen und schafft sich (zumindest vorerst) einen Vorteil gegenüber der Konkurrenz.

Die populärsten Content-Management-Systeme sind daran, AMP zu integrieren. Für WordPress sind bereits einige Plugins erhältlich, die die eigenen Blogpost in einer AMP-Version verfügbar machen. Das von Automattic mitentwickelte Plugin AMP kommt auch auf unserem Blog zum Einsatz. Und so sieht dieser Beitrag im AMP-Format aus.

Tutorial und weiterführende Lektüre

In der Dokumentation des Projektes finden Sie ein Tutorial, das Sie durch die Erstellung Ihrer ersten AMP-Seite führt. Weiterführende Informationen zu AMP finden Sie ausserdem auf der offiziellen Projekt-Website, dem GitHub-Repo und in der offiziellen Dokumentation.

Die 10 beliebtesten Domainendungen unserer Kunden

Mit mittlerweile über 300 verfügbaren verschiedenen Domainendungen kann wirklich jeder den perfekten Domainnamen für sein Projekt finden. Doch welche Domainendungen sind die beliebtesten? Wir haben einen Blick auf unsere Statistiken geworfen und stellen heute die Top-10 der Domainendungen unserer Kunden vor.

Die beliebtesten Domainendungen der cyon-Kunden.

Die Rangliste

Sie können sich denken, welche Domainendung die absolute Nummer eins bei unseren Kunden ist. Richtig: .ch macht den Löwenanteil der bei uns registrierten Domainnamen aus. Mit satten 82.43% ist die Schweizer Länderdomain absoluter Spitzenreiter. Mit 7.34% folgt .com weit abgeschlagen auf Platz zwei unserer Domain-Charts. Auf Platz drei sitzt mit .de die Länderdomain unserer nördlichen Nachbarn und macht gerade noch 1.93% am Gesamtkuchen aus. Und so präsentieren sich die Top 10 in der Übersicht:

Rang Domainendung Anteil
1. .ch 82.43%
2. .com 7.34%
3. .de 1.93%
4. .net 1.15%
5. .li 1.03%
6. .org 0.91%
7. .eu 0.83%
8. .at 0.79%
9. .info 0.50%
10. .me 0.36%

Restliche Domainendungen: 2.73%

Die beliebtesten ngTLDs

Im April 2014 wurden die ersten neuen Domainendungen, die sogenannten ngTLDs (New Generic Top-Level Domains), eingeführt. Seit dann sind monatlich neue Domainendungen dazugekommen und haben unser Angebot auf über 300 Stück anschwellen lassen. Aber längst nicht jede Domainendung schafft es denn auch in unser Portfolio. Immer wieder machen spezielle Restriktionen die Aufnahme ins Angebot zunichte.

Auch bei den ngTLDs liegt eine Schweizer Endung an erster Stelle. Und das, obwohl .swiss erst seit Kurzem verfügbar ist. Die Top-10 aller bei uns verfügbaren ngTLDs präsentieren sich aktuell folgendermassen:

Rang Domainendung Verfügbar seit
1. .swiss 11.01.2016
2. .email 26.03.2014
3. .zone 30.04.2014
4. .photo 15.04.2014
5. .agency 30.04.2014
6. .academy 10.04.2014
7. .club 07.05.2014
8. .schule 27.08.2014
9. .solutions 26.03.2014
10. .world 14.01.2015

Das Angebot wächst weiterhin

Zwar sind in den vergangenen Monaten nicht mehr ganz so viele neue Domainendungen delegiert worden, wie das vor einem Jahr noch der Fall war. Doch noch immer kommen neue TLDs hinzu. Auch im Februar ist das nicht anders.

Am kommenden Dienstag, 16. Februar, startet mit .cloud eine der spannenderen neuen Domainendung der letzten Zeit. Eine Woche danach, am 23. Februar, geht mit .pet dann die zweite neue Domainendung im aktuellen Monat an den Start.

Sind Sie noch auf der Suche nach der perfekten Domain? Schauen Sie sich einfach einmal auf unserer Domainseite um.

SSH-Keys jetzt auch per my.cyon hinterlegen

Wir sind grosse Kommandozeilenliebhaber und der Meinung, dass viele Aktionen einfach einfacher von der Hand gehen, wenn sie im Terminal ausgeführt werden. Mit einem SSH-Zugang, der übrigens bei allen unseren Angeboten inklusive ist, verwalten Sie die Daten auf Ihrem Webhosting ebenfalls über die Kommandozeile.

Einsteigertipp: Ist SSH für Sie ein Fremdwort? Mit unserem Blogbeitrag zum Thema gelingt Ihnen der Einstieg in die Welt der Kommandozeile.

Mit Hilfe von SSH-Keys vereinfachen Sie den Zugriff auf Ihr Webhosting per SSH bzw. SFTP markant. Denn: Mit SSH-Keys müssen Sie sich nicht mehr unzählige Passwörter merken, wenn Sie gleich mehrere Webhostings verwalten. Wie Sie SSH-Keys auf Ihrem Computer erzeugen, erfahren Sie in unserem Supportcenter-Artikel «Wie erstelle ich SSH-Keys?».

Public-Key hinterlegen

Um sich ohne Eingabe eines Passworts einem Webhosting zu verbinden, muss der eigene Public-Key auf dem gewünschten Webhosting vorhanden sein. In der Datei ~/.ssh/authorized_keys genauer gesagt. Dies lässt sich auf verschiedenen Wegen erreichen.

Zum einen wäre da das Kommandozeilenprogramm ssh-copy-id, dass auf einem Mac zum Beispiel mit Hilfe der Paketverwaltung Homebrew installiert werden kann. Ist ssh-copy-id einmal installiert, genügt der folgende Befehl um den eigenen Public-Key auf dem gewünschten Webhosting abzulegen:
ssh-copy-id benutzername@ihredomain.ch wobei benutzername Ihrem SSH-Benutzer entspricht und ihredomain.ch jede Domain sein kann, die auf Ihrem Webhosting installiert ist.

Nach der Eingabe des Webhosting-Passworts wird Ihr Public-Key in die Datei ~/.ssh/authorized_keys kopiert und zukünftige SSH-Logins funktionieren automatisch ohne die Eingabe des Passworts.

Neue Funktion im my.cyon

Möchten Sie ssh-copy-id nicht installieren, haben Sie neuerdings eine weitere einfache Möglichkeit, um Ihren Public-Key auf einem Webhosting zu hinterlegen. Per my.cyon-Konto.

Wählen Sie dazu, nachdem Sie sich in Ihr my.cyon-Konto eingeloggt haben, das Menü «Sicherheit» und dort das Untermenü «SSH-Keys». Nun können Sie ganz bequem neue Public-Keys hinzufügen, bereits hinterlegte anzeigen lassen oder wenn nötig auch wieder entfernen.

SSH-Public-Keys lassen sich auch per my.cyon auf einem Webhosting hinterlegen.

SSH-Public-Keys lassen sich auch per my.cyon auf einem Webhosting hinterlegen.

Unbegrenzte Möglichkeiten

Ist der eigene Public-Key erst einmal hinterlegt, vereinfacht sich nicht nur der manuelle Verbindungsaufbau per SSH. Mit ein wenig Programmierkenntnis lassen sich zum Beispiel Aufgaben wie das Erstellen von Backups automatisieren. Oder eine ganze Armada von WordPress- und Drupal-Installationen mit Hilfe von Tools wie WP-CLI und Drush gleichzeitig warten. Die Möglichkeiten sind unbegrenzt.

Seite 5 von 98« Erste...34567...102030...Letzte »