Download - REST - Hypermedia und Sicherheit
© 2012 Mayflower GmbH
REST Hypermedia und Sicherheit
Jens Broos I 15.12.2011
2
I Ressourcen mit eindeutiger Identifikation
I Standardmethoden (Verbs)
• GET, HEAD, POST, PUT, DELETE…
I Unterschiedliche Repräsentationen
• XML, JSON, HTML, Image, Video, PDF, uvm.
I Statuslose Kommunikation
I Verknüpfungen / Hypermedia
Rückbesinnung: Grundprinzipien von REST
3
Hyper! Media!
4
I Links bestimmen Möglichkeiten des Clients
I Link wird in Repräsentation eingebettet
I Keine externe Beschreibung notwendig
I Server verwendet Format, das Client versteht
I Anwendungsstatus bestehend aus
• Ressourcenrepräsentation im Client
• serverseitigen Ressourcenstatus
• NICHT aus Sitzungsinformationen
HATEOAS - Hypermedia as the engine of application state
5
I Anchor Elemente
<a href=“http://www.mayflower.de“>Mayflower</a>
I Formulare
<form action=“nextSite.php“ method=“GET/POST“>
Hypermedia – Im Browser
6
Hypermedia – Anwendung-zu-Anwendung
I Entkoppelung von Client und Server
I Transparenz bei Änderungen an Ressourcen
I Serverseitig steuerbarer Anwendungsfluss
I Reduktion von separaten Metadaten
7
Ressource: http://example.com/orders/1848 Subressource: http://example.com/orders/1848/shipping-address
Hypermedia – Ressourcen verknüpfen
8
http://example.com <?xml version=“1.0“ encoding=“UTF-8“?> <serviceDescription xml:base=“http://example.com“>
<link rel=“orders“ href=“/orders/“ />
<link rel=“customers“ href=“/customers/“ />
<link rel=“products“ href=“/products/“ />
</serviceDescription>
Hypermedia – Listenressource
9
<?xml version=“1.0“ encoding=“UTF-8“?> <orders href=“/orders/“ xml:base=“http://example.com“>
<link rel=“1848“ href=“/orders/1848“ />
<link rel=“4711“ href=“/orders/4711“ />
<link rel=“1701“ href=“/orders/1701“ />
</orders>
Hypermedia
10
<order href=“/orders/1848“ xml:base=“http://example.com“
xmlns=“http://example.com/schemas/order“ > ….
<shippingAddress>
http://example.com/order/1848/shipping-address
</shippingAddress> …
<shippingAddress>
<city>Bochum</city>
<link>http://example.com/ord…</link> </shippingAddress> …
Hypermedia
11
Sicherheit
arREST
12
I Warum brauchen wir Sicherheit?
– Geschütze Ressourcen
• Bestellsystem
• Pay Content, z.B. Maxdome
• Nachrichten abrufen
• Kreditkarteninformationen
• Etc.
REST und Sicherheit
13
I Nachrichtenorientierte Sicherheit
• Ist Nachricht / Inhalt geeignet geschützt?
• Verschlüsselung, Signatur
• Übertragung über ungesicherten Transportmechanismus
I Transportbasierte Sicherheit
• Ungesicherte Nachricht über gesicherten Kanal
• Vorrangige Nutzung in der Praxis
Sicherheitsmechanismen unterscheiden
14
Transportbasierte Sicherheit
15
I HTTP über SSL / TSL
I Server beweist Identität gegenüber Client mit Zertifikat
I Zertifikat von vertrauenswürdiger Zertifizierungsstelle
I Clientseitig
• Benutzername / Passwort
• Clientzertifikat
I Keine „Man-in-the-middle Attacken“
I Ignorieren von Proxy-Caches
SSL und HTTPS
16
I Der Unterschied liegt im Detail …
• Identifizierung mit einem Benutzernamen
• Authentisierung mit einem Passwort
• Authentifizierung beider Eingaben via Server
• Autorisierung gewährt Recht zum Aufruf einer Ressource
I Im englischen nur: Authentication and Authorization
Begrifflichkeiten in der Sicherheit
17
I Ressource für anonymen Zugriff gesperrt
• Rückgabe HTTP Statuscode: 401 Unauthorized
I „Authentication Challenge“
I WWW-Authenticate im Header legt Schema fest
• Basic
• Digest
I Header: „Realm“ - Geltungsbereich der Authentifizierung
I REST Spielregeln: Keine Session aufbauen!
HTTP-Authentifizierung
18
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Basic realm=“Private Area“
Content-Type: text/html; charset=iso-8859-1
<html>
<head>
<title>Authorization Required</title>
</head>
<body>
You are not allowed to do this.
….
Beispiel Authentication Challenge
19
I base64enc(‘admin‘ + ‘:‘ + ‘secret‘)
• RtaW46c2VjcmV0Cg==
I Im Header GET / HTTP 1.0 Accept: text/html Authorization: RtaW46c2VjcmV0Cg==
I Nicht verschlüsselt: Basic ohne weitere Anstrengungen sinnlos
HTTP Basic Authentication
20
I Passwort nicht im Klartext übertragen
I Berechnung von Hashwert mit kryptografischer Funktion
• Vorteil: Passwort bleibt geheim
• Ergebnis der Berechnung nennt man „Digest“
I Server informiert Client über Schema, Geltungsbereich und „nonce“
I Gleicher Berechnungsalgorithmus auf Server und Client
HTTP Digest Authentication
21
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Digest
realm=“Private Area“
nonce=“890fds09d908gf890gd890fd“ Authorization: Digest
username=“user“
realm=“Private Area“
nonce=“890fds09d908gf890gd890fd“
uri=“/orders“ response=“265uuid32fdsd8989jkkjl899“
MD5(MD5(Benutzername . “:“ . Realm . “:“ Passwort) . “:“ .
nonce . “:“ . MD5(HTTP-Methode . “:“ . URI))
Beispiel Authentication Challenge bei Digest
22
Kurzes Resümee
23
I Beide Sicherheitsprinzipien ergänzen sich
• SSL tunnelt von Client bis Server
• Authentifizierung durch Basic Authentication
Die 80% Lösung: HTTPS + Basic Authentication
Client WebServer Application
Auth Server
SSL SSL REST
24
I Cookies sind üblicher Weg, Authentifizierungs- bzw. Benutzerinformationen zu übermitteln
I Umgehen den statuslosen Charakter von HTTP
I Server erstellt Schlüssel/Wert-Paare
I Lieferung des Paare per „Set-cookie“ Header
I Client schickt diese Werte bei jeder Anfrage an gleichen Server und Pfad in einem Cookie-Header
I Wenn man Cookies nicht verhindern kann, dann zumindest Auswirkungen begrenzen
Cookies – Statefull Poison
25
1.) Server berechnet geheimen Wert
2.) Client schickt Logindaten per SSL an Server
3.) Server authentifiziert
4.) Wenn erfolgreich: Server erstellt „Ticket“ oder „Token“ Ticket = hash(Benutzername . “:“ . Secret . “:“ Gültigkeitsdauer)
5.) Server setzt Cookies für Benutzername, Ticket und
Gültigkeitsdauer
6.) Nächster Request: Browser überliefert diese drei Werte
in Form von Cookies als Teil der Anfrage
7.) Browser berechnet Ticket und prüft gegen
Cookies – Auswirkungen begrenzen
26
Zwei verschiedene Ansätze von Sicherheit
27
I Daten werden je nach Berechtigung im Webserver gefiltert
I Nicht mehr stateless
I Aushebeln von Caching-Mechanismen
Webserver als „Filter“
Application SSL REST
WebServer
Auth Server
Application SSL REST
WebServer
Auth Server
Application SSL REST
WebServer
Auth Server
Client
28
I Daten für jeden zugänglich
I Daten liegen permanent in verschlüsselter Form vor
I Berechtigungen werden hierarchisch via SSL an den Client verschickt
Nur Berechtigungen via SSL verschickt
Client Application SSL
WebServer
Auth Server
unverschlüsselt
29
Nachrichtenorientierte Sicherheit
30
I Anforderung: Verhinderung von unerlaubter Modifikation
I Nachricht mit Signatur anreichern
I Basis =geheimer Schlüssel, Client und Server bekannt
I Vorteile:
• Stellt sicher, dass Nachricht von vertrauenswürdiger Stelle stammt
• Ausschluss von Man-in-the-middle-Attacken
I Nachteil:
• Nachricht kann immer mitgelesen werden
HMAC Keyed-Hashing for Message Authentication
31
HMAC Keyed-Hashing for Message Authentication
32
HMAC Keyed-Hashing for Message Authentication
iPad?!
33
I Kein generischer, standardisierter Mechanismus
I Verwendung bestehender Mechanismen auf Repräsentationsbasis
• Verschlüsseltes PDF
• Generische PGP-Verschlüsselung und –Signatur
• XML Encryption
• XML Digital Signature (XML DSIG)
I Letztendlich bleibt die Frage: Ist SSL-Übertragung nicht sicher genug?
Nachrichtenverschlüsselung und Signatur
34
OpenID und OAuth
35
I Problem: Viele Webseiten, viele Logins
I OpenID: Kooperierende Dienste nutzen einen Authentifizierungsservice
I Zentrale einmalige Registrierung
I Konzept: URL-basierte Identität
I Parteien
• Browser des Endanwenders
• OpenID Provider
• Webanwendung
OpenID
36
OpenID
OpenID Provider
User WebService
http://idprovi.der/ids/1848
37
I Anforderung: „Übertragung“ der Rechte an andere Anwendung
I Notwendig: Spezifische, eingeschränkte Autorisierung
I Parteien
• Service prodiver
• Consumer
• User
OAuth
38
OAuth Übersicht
© 2012 Mayflower GmbH
Dipl.-Inform. (FH) Jens Broos
+49 89 242054 1129
Mayflower GmbH
Mannhardtstraße 6
80538 München
Referent
Vielen Dank für Ihre Aufmerksamkeit!
40
I Buch: Stefan Tilkov – REST und HTTP, dpunkt.verlag
I Wikipedia, Artikel HMAC
I Bild zu OAuth: http://www.ubelly.com/2010/02/building-a-simple-oauth-twitter-application
I Foto „Sicherheit“: © Didi01 / pixelio.de
I Foto „Hypermedia“: Wikimedia User: Radiat-r
Quellen
41
I Keine Abhängigkeiten von spezifischen Kommunikationsprotokollen
I Bestehende Methoden dürfen durch API nicht geändert werden (PUT bleibt PUT, etc.)
I Keine fixen Ressourcennamen oder Hierarchien
I Ressourcen sind nicht getypt, nur deren Repräsentation
I Kein Wissen über spezifische URIs
• Ausnahme: Einstiegspunkt
• Alle anderen Links werden „entdeckt“
Hypermedia – Checkliste