Post on 22-Jan-2018
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 ?
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.
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