Ist deine Webseite wirklich…

…. sicher ?

Nach einer wahren Begebenheit

Martin Wolfert | https://wp-loft.de | WordPress Meetup KA #13

Was macht eine WordPress Seite sicher ?

WordPress Core, Theme und Plugin Updates ?

Sichere Passwörter ?

Kein „admin“ User ?

Uniquer Datenbankprefix ?

Salts in der wp-config ?

Backend-Login via SSL ?

HTTPS und ein A-Ranking bei SSL-Labs ?

Really?

Ein Ausblick ….

… Observatory von Mozilla

The new kid in town

Fangen wir vorne an

Schon seit Monaten hatte ich mit meinem Blog ein A+ Rating bei SSL Labs. WordPress Core, Theme und Plugins waren gepflegt, der NGinx getweakt, das Linux auf dem Server zugenagelt.

Fein :), alles OK !

Really?

WTF! Ein „Grade F“ bei Observatory

Ursachen für das „F - Rating“

Keine Content Security Policy (CSP) Header

Kein HSTS bei der SSL Konfiguration

Keine Response Header „X-Header“

X-Content-Type-Options

X-Frame-Options

X-XSS-Protection

Erklärung der „X-Header“

X-Frame-Options: [ SAMEORIGIN / ALLOW-FROM / DENY] Wird benutzt um dem Browser zu signalisieren, ob eine Webseite in einem Frame, iFrame oder Objekt gerendert werden soll.

Damit kann man Clickjacking Attacken verhindern, indem der Inhalt einer Webseite nicht in einer anderen Webseite eingebettet werden kann.

Erklärung der „X-Header“

X-Content-Type-Options: nosniff

Wird benutzt um dem Browser zu signalisieren, der Mitgelieferte MIME-Type auf jeden Fall respektiert werden soll. Damit wird JavaScript-Code in Bildern vom Browser ignoriert.

Dieser Header vervollständigt den Schutz vor Cross-Site-Scripting mit Bilder der Contend Security Policy (CSP)

Erklärung der „X-Header“

X-XSS-Protection: 1; mode=block

Dieser Header wurde geschaffen, um den Cross Site Scripting (XSS) Filter einzuschalten, der in jedem modernen Browser enthalten ist.Normalerweise ist dieser Filter bereits per default im Browser aktiviert. Das Setzen des Headers erzwingt jedoch das Einschalten des Filters.

Content Security Header (CSP)

Die CSP HTTP-Header bilden einen zusätzlichen Sicherheits-Layer. Dieser Layer hilft Cross Site Scripting (XSS) und andere Code Injections zu verhindern, indem nur definierte Content Quellen vom Browser geladen werden.

Quelle: https://www.keycdn.com/blog/http-security-headers/

Content Security Header (CSP)

Jeder der großen Browserhersteller unterstützt CSP HTTP-Header komplett oder zumindest teilweise.

Quelle: https://www.keycdn.com/blog/http-security-headers/

Mehr Informationen dazu erhält man bei caniuse.com: http://caniuse.com/#search=content%20security%20policy

Content Security Header (CSP)

CSP-Header in eine WordPress-Installation einzubinden ist nicht schwer, aber bedarf großer Sorgfalt. Für meinen Fotoblog (https://blog.lichttraeumer.de) sieht das wie folgt aus:

Content Security Header (CSP)content-security-policy:default-src 'self' 'unsafe-inline'; script-src 'self' 'unsafe-inline' 'unsafe-eval' https://www.google-analytics.com https://www.google.com https://maps.google.com https://maps.googleapis.com https://piwik.martin-wolfert.de; img-src 'self' data: https://www.google-analytics.com https://secure.gravatar.com https://csi.gstatic.com https://stats.g.doubleclick.net https://ps.w.org https://piwik.martin-wolfert.de https://ajax.googleapis.com https://www.bloggerei.de; font-src 'self' data: https://fonts.gstatic.com; child-src 'self' https://piwik.martin-wolfert.de; style-src 'self' 'unsafe-inline' https://ajax.googleapis.com https://www.google.com https://fonts.googleapis.com; report-uri https://lichttraeumerblog.report-uri.io/r/default/csp/enforce

„unsafe-inline“ = inline Sourcen wie style attribute, onclick … „unsafe-eval“ = unsichere dynamische Funktionen, z.B. JS eval()

HTTP Strict Transport Security (HSTS)

HSTS ist eine opt-in Security Maßnahme, und wird durch einen speziellen HTTP Response-Header gesetzt. Diesen Header zu setzen macht nur Sinn, wenn die Webseite via HTTPS zu erreichen ist. In diesem Falle erkennt der Browser den HSTS-Header, und lädt die aufgerufenen Webseite in der Zukunft (für eine definierte Zeit) nur noch über HTTPS.

Beispiel: Strict-Transport-Security: max-age=31536000; includeSubDomains

Mehr Informationen: https://www.owasp.org/index.phpHTTP_Strict_Transport_Security_Cheat_Sheet

Ist es sinnvoll all den Kram umzusetzen?

Meiner Meinung nach Ja, weil Sicherheit im Netz von Größen wie Google, Mozilla, Akamai, Cisco etc. stark gepusht wird:

Google rankt HTTPS besser als HTTP

Die Internet Security Research Group (ISRG) hat Letsencrypt eingeführt

Google’s Chrome Browser wird ab Januar HTTP Seiten als unsicher anzeigen

Conclusio

Ich denke, dass „sichere Webseiten“ zukünftig bei Google und Co ein besseres Ranking erfahren werden.

Mit Tools wie Observatory, oder Securityheaders.io, wird es Webseitenbetreibern, Freelancer, Agenturen und Admins leicht gemacht, Schwachstellen aufzuzeigen und zu fixen.

Dadurch wird es einfacher, Kunden den Mehraufwand in Bezug auf Sicherheit seiner Webpräsenz näherzubringen und dafür auch entlohnt zu werden.

Links und Quellen

Observatory: https://observatory.mozilla.org/

Security Headers: https://securityheaders.io

Chrome und HTTP/HTTPS: https://security.googleblog.com/2016/09/moving-towards-more-secure-web.html

Mozilla Security Guidlines: https://wiki.mozilla.org/Security/Guidelines/Web_Security

QWASP https://www.owasp.org/

CSP Header: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy

Bildquellen:

unsplash.com, panosozi (via Deviant Art), Free stock photos