REST nutzt mit Hypermedia eines der grundlegendsten Konzepte des www: die Verknüpfung zwischen Ressourcen und die damit verbundene Steuerung der Applikation. Doch dieses Konzept gilt nicht nur für uns, die wir mit dem Browser interagieren, sondern auch für die Kommunikation von Anwendung-zu-Anwendung. Doch erfolgt REST immer vom Server bis direkt zum Client? Ab wann ist eine Anwendung vielleicht doch nicht mehr so RESTful, wie sie gegenüber dem Product Owner versprochen wurde? Spätestens mit der Implementierung von Sicherheitskonzepten muss man sich dieser Frage zwingend stellen. Denn wenn man Authentifizierungsinformationen überträgt, kippt ein weiteres Hauptkonzept von REST: die statuslose Kommunikation. Jens Broos, Developer bei Mayflower, vermittelt Beispiele und Grundgedanken zum Thema Hypermedia und gibt einen Einstieg in die Sicherheitsmechanismen von RESTful WebServices. Die Präsentation erweitert den Vortrag „RESTful WebServices“ von Paul Seiffert, der am 20.10.2011 gehalten wurde. Den Foliensatz findet man unter: http://www.slideshare.net/mayflowergmbh/restful-webservices-10103497

1. REST
Hypermedia und Sicherheit
Jens Broos I 15.12.2011
© 2012 Mayflower GmbH

2. Rückbesinnung: Grundprinzipien von REST
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
2

3. Hyper!
Media!
3

4. HATEOAS - Hypermedia as the engine of application state
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
4

5. Hypermedia – Im Browser
I Anchor Elemente
<a href=“http://www.mayflower.de“>Mayflower</a>
I Formulare
<form action=“nextSite.php“ method=“GET/POST“>
5

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
6

7. Hypermedia – Ressourcen verknüpfen
Ressource:
http://example.com/orders/1848
Subressource:
http://example.com/orders/1848/shipping-address
7

8. Hypermedia – Listenressource
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>
8

9. Hypermedia
<?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/471 />
1“
<link rel=“1701“ href=“/orders/1701“ />
</orders>
9

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

11. arREST
Sicherheit 11

12. REST und Sicherheit
I Warum brauchen wir Sicherheit?
– Geschütze Ressourcen
• Bestellsystem
• Pay Content, z.B. Maxdome
• Nachrichten abrufen
• Kreditkarteninformationen
• Etc.
12

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

14. Transportbasierte Sicherheit
14

15. SSL und HTTPS
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
15

16. Begrifflichkeiten in der Sicherheit
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
16

17. HTTP-Authentifizierung
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!
17

18. Beispiel Authentication Challenge
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.
….
18

19. HTTP Basic Authentication
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
19

20. HTTP Digest Authentication
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
20

21. Beispiel Authentication Challenge bei Digest
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))
21

22. Kurzes Resümee
22

23. Die 80% Lösung: HTTPS + Basic Authentication
I Beide Sicherheitsprinzipien ergänzen sich
• SSL tunnelt von Client bis Server
• Authentifizierung durch Basic Authentication
SSL SSL REST
Client WebServer Application
Auth Server
23

24. Cookies – Statefull Poison
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
24

25. Cookies – Auswirkungen begrenzen
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
25

26. Zwei verschiedene Ansätze
von Sicherheit
26

27. Webserver als „Filter“
I Daten werden je nach Berechtigung im Webserver gefiltert
I Nicht mehr stateless
I Aushebeln von Caching-Mechanismen
SSL REST
Client WebServer Application
Auth Server
27

28. Nur Berechtigungen via SSL verschickt
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
unverschlüsselt
Client WebServer Application
SSL
Auth Server
28

29. Nachrichtenorientierte Sicherheit
29

30. HMAC Keyed-Hashing for Message Authentication
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
30

31. HMAC Keyed-Hashing for Message Authentication
31

32. HMAC Keyed-Hashing for Message Authentication
iPad?!
32

33. Nachrichtenverschlüsselung und Signatur
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?
33

34. OpenID und OAuth
34

35. OpenID
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
35

36. OpenID
OpenID
Provider
User WebService
http://idprovi.der/ids/1848
36

37. OAuth
I Anforderung: „Übertragung“ der Rechte an andere Anwendung
I Notwendig: Spezifische, eingeschränkte Autorisierung
I Parteien
• Service prodiver
• Consumer
• User
37

38. OAuth Übersicht
38

39. Vielen Dank für Ihre Aufmerksamkeit!
Referent Dipl.-Inform. (FH) Jens Broos
jens.broos@mayflower.de
+49 89 242054 1 129
Mayflower GmbH
Mannhardtstraße 6
80538 München
© 2012 Mayflower GmbH

40. Quellen
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
40

41. Hypermedia – Checkliste
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“
41