23-mal heruntergeladen
Hochgeladen vonMayflower GmbH
REST - Hypermedia und Sicherheit
Das Dokument erläutert die Grundprinzipien von REST und Hypermedia, einschließlich der eindeutigen Identifikation von Ressourcen, der Verwendung standardisierter Methoden wie GET und POST sowie der Hypermedia-Struktur, die eine lose Kopplung zwischen Client und Server ermöglicht. Es werden verschiedene Sicherheitsmechanismen beschrieben, darunter transportbasierte Sicherheit wie SSL/HTTPS sowie Authentifizierungsmethoden wie Basic und Digest Authentication. Zusätzlich wird auf die Verwendung von Technologien wie OpenID und OAuth eingegangen, um Benutzeridentitäten und Zugriffsrechte in Webanwendungen zu verwalten.
REST - Hypermedia und Sicherheit
- 1. REST Hypermedia und Sicherheit JensBroos I 15.12.2011 © 2012 Mayflower GmbH
- 2. Rückbesinnung: Grundprinzipien vonREST 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.
- 4. HATEOAS - Hypermediaas 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 – ImBrowser 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 – Ressourcenverknüpfen Ressource: http://example.com/orders/1848 Subressource: http://example.com/orders/1848/shipping-address 7
- 8. Hypermedia – Listenressource http://example.com <?xmlversion=“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“?> <ordershref=“/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.
- 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 derSicherheit 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.1401 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 Challengebei 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.
- 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 – StatefullPoison 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 – Auswirkungenbegrenzen 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 viaSSL 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.
- 30. HMAC Keyed-Hashing forMessage 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 forMessage Authentication 31
- 32. HMAC Keyed-Hashing forMessage 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.
- 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.
- 39. Vielen Dank fürIhre 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