Das Dokument behandelt die Sicherheitsaspekte von WordPress-Webseiten und kritisiert die gängigen Sicherheitsmaßnahmen, die oft nicht ausreichen. Es werden spezifische Header wie Content Security Policy (CSP) und HTTP Strict Transport Security (HSTS) diskutiert, die zur Verbesserung der Sicherheit implementiert werden sollten. Zudem wird darauf hingewiesen, dass erhöhte Sicherheit zu besseren Rankings bei Suchmaschinen führen kann.

1. Ist deine Webseite wirklich…
…. sicher ?
Nach einer wahren Begebenheit
Martin Wolfert | https://wp-loft.de | WordPress Meetup KA #13

2. 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 ?

3. Really?

4. Ein Ausblick ….

5. … Observatory von Mozilla
The new kid in town

6. 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.

7. Fein :), alles OK !

8. Really?

9. WTF! Ein „Grade F“ bei Observatory

10. 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

11. 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.

12. 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)

13. 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.

14. 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/

15. 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

16. 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:

17. 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()

18. 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

19. 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

20. 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.

22. 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