Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
SlideShare ist ein Scribd-Unternehmen logo

Ist deine Webseite wirklich Sicher?

•
•
M
Martin Wolfert

Wie man mit Observatory Schwächen auf Webseiten prüfen und mit einfachen Mitteln auch beheben kann. Eine Story um X-HTTP-Header, Content-Security-Policy und HSTS

1 von 22
Downloaden Sie, um offline zu lesen
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.
Ist deine Webseite wirklich Sicher?
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

Weitere ähnliche Inhalte

Ist deine Webseite wirklich Sicher?

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