Your SlideShare is downloading. ×
0
REST - Hypermedia und Sicherheit
REST - Hypermedia und Sicherheit
REST - Hypermedia und Sicherheit
REST - Hypermedia und Sicherheit
REST - Hypermedia und Sicherheit
REST - Hypermedia und Sicherheit
REST - Hypermedia und Sicherheit
REST - Hypermedia und Sicherheit
REST - Hypermedia und Sicherheit
REST - Hypermedia und Sicherheit
REST - Hypermedia und Sicherheit
REST - Hypermedia und Sicherheit
REST - Hypermedia und Sicherheit
REST - Hypermedia und Sicherheit
REST - Hypermedia und Sicherheit
REST - Hypermedia und Sicherheit
REST - Hypermedia und Sicherheit
REST - Hypermedia und Sicherheit
REST - Hypermedia und Sicherheit
REST - Hypermedia und Sicherheit
REST - Hypermedia und Sicherheit
REST - Hypermedia und Sicherheit
REST - Hypermedia und Sicherheit
REST - Hypermedia und Sicherheit
REST - Hypermedia und Sicherheit
REST - Hypermedia und Sicherheit
REST - Hypermedia und Sicherheit
REST - Hypermedia und Sicherheit
REST - Hypermedia und Sicherheit
REST - Hypermedia und Sicherheit
REST - Hypermedia und Sicherheit
REST - Hypermedia und Sicherheit
REST - Hypermedia und Sicherheit
REST - Hypermedia und Sicherheit
REST - Hypermedia und Sicherheit
REST - Hypermedia und Sicherheit
REST - Hypermedia und Sicherheit
REST - Hypermedia und Sicherheit
REST - Hypermedia und Sicherheit
REST - Hypermedia und Sicherheit
REST - Hypermedia und Sicherheit
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

REST - Hypermedia und Sicherheit

2,074

Published on

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 …

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

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
2,074
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
17
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. RESTHypermedia und SicherheitJens Broos I 15.12.2011 © 2012 Mayflower GmbH
  • 2. Rückbesinnung: Grundprinzipien von RESTI Ressourcen mit eindeutiger IdentifikationI Standardmethoden (Verbs) • GET, HEAD, POST, PUT, DELETE…I Unterschiedliche Repräsentationen • XML, JSON, HTML, Image, Video, PDF, uvm.I Statuslose KommunikationI Verknüpfungen / Hypermedia 2
  • 3. Hyper!Media! 3
  • 4. HATEOAS - Hypermedia as the engine of application stateI Links bestimmen Möglichkeiten des ClientsI Link wird in Repräsentation eingebettetI Keine externe Beschreibung notwendigI Server verwendet Format, das Client verstehtI Anwendungsstatus bestehend aus • Ressourcenrepräsentation im Client • serverseitigen Ressourcenstatus • NICHT aus Sitzungsinformationen 4
  • 5. Hypermedia – Im BrowserI Anchor Elemente <a href=“http://www.mayflower.de“>Mayflower</a>I Formulare <form action=“nextSite.php“ method=“GET/POST“> 5
  • 6. Hypermedia – Anwendung-zu-AnwendungI Entkoppelung von Client und ServerI Transparenz bei Änderungen an RessourcenI Serverseitig steuerbarer AnwendungsflussI Reduktion von separaten Metadaten 6
  • 7. Hypermedia – Ressourcen verknüpfenRessource:http://example.com/orders/1848Subressource:http://example.com/orders/1848/shipping-address 7
  • 8. Hypermedia – Listenressourcehttp://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 SicherheitI Warum brauchen wir Sicherheit? – Geschütze Ressourcen • Bestellsystem • Pay Content, z.B. Maxdome • Nachrichten abrufen • Kreditkarteninformationen • Etc. 12
  • 13. Sicherheitsmechanismen unterscheidenI Nachrichtenorientierte Sicherheit • Ist Nachricht / Inhalt geeignet geschützt? • Verschlüsselung, Signatur • Übertragung über ungesicherten TransportmechanismusI Transportbasierte Sicherheit • Ungesicherte Nachricht über gesicherten Kanal • Vorrangige Nutzung in der Praxis 13
  • 14. Transportbasierte Sicherheit 14
  • 15. SSL und HTTPSI HTTP über SSL / TSLI Server beweist Identität gegenüber Client mit ZertifikatI Zertifikat von vertrauenswürdiger ZertifizierungsstelleI Clientseitig • Benutzername / Passwort • ClientzertifikatI Keine „Man-in-the-middle Attacken“I Ignorieren von Proxy-Caches 15
  • 16. Begrifflichkeiten in der SicherheitI 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 RessourceI Im englischen nur: Authentication and Authorization 16
  • 17. HTTP-AuthentifizierungI Ressource für anonymen Zugriff gesperrt • Rückgabe HTTP Statuscode: 401 UnauthorizedI „Authentication Challenge“I WWW-Authenticate im Header legt Schema fest • Basic • DigestI Header: „Realm“ - Geltungsbereich der AuthentifizierungI REST Spielregeln: Keine Session aufbauen! 17
  • 18. Beispiel Authentication ChallengeHTTP/1.1 401 UnauthorizedWWW-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 AuthenticationI 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 AuthenticationI Passwort nicht im Klartext übertragenI 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 DigestHTTP/1.1 401 UnauthorizedWWW-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 AuthenticationI 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 PoisonI Cookies sind üblicher Weg, Authentifizierungs- bzw. Benutzerinformationen zu übermittelnI Umgehen den statuslosen Charakter von HTTPI Server erstellt Schlüssel/Wert-PaareI Lieferung des Paare per „Set-cookie“ HeaderI Client schickt diese Werte bei jeder Anfrage an gleichen Server und Pfad in einem Cookie-HeaderI Wenn man Cookies nicht verhindern kann, dann zumindest Auswirkungen begrenzen 24
  • 25. Cookies – Auswirkungen begrenzen1.) Server berechnet geheimen Wert2.) Client schickt Logindaten per SSL an Server3.) Server authentifiziert4.) Wenn erfolgreich: Server erstellt „Ticket“ oder „Token“ Ticket = hash(Benutzername . “:“ . Secret . “:“ Gültigkeitsdauer)5.) Server setzt Cookies für Benutzername, Ticket und Gültigkeitsdauer6.) Nächster Request: Browser überliefert diese drei Werte in Form von Cookies als Teil der Anfrage7.) 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 gefiltertI Nicht mehr statelessI Aushebeln von Caching-Mechanismen SSL REST Client WebServer Application Auth Server 27
  • 28. Nur Berechtigungen via SSL verschicktI Daten für jeden zugänglichI Daten liegen permanent in verschlüsselter Form vorI 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 AuthenticationI Anforderung: Verhinderung von unerlaubter ModifikationI Nachricht mit Signatur anreichernI Basis =geheimer Schlüssel, Client und Server bekanntI Vorteile: • Stellt sicher, dass Nachricht von vertrauenswürdiger Stelle stammt • Ausschluss von Man-in-the-middle-AttackenI 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 SignaturI Kein generischer, standardisierter MechanismusI 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. OpenIDI Problem: Viele Webseiten, viele LoginsI OpenID: Kooperierende Dienste nutzen einen AuthentifizierungsserviceI Zentrale einmalige RegistrierungI Konzept: URL-basierte IdentitätI Parteien • Browser des Endanwenders • OpenID Provider • Webanwendung 35
  • 36. OpenID OpenID Provider User WebService http://idprovi.der/ids/1848 36
  • 37. OAuthI Anforderung: „Übertragung“ der Rechte an andere AnwendungI Notwendig: Spezifische, eingeschränkte AutorisierungI 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. QuellenI Buch: Stefan Tilkov – REST und HTTP, dpunkt.verlagI Wikipedia, Artikel HMACI Bild zu OAuth: http://www.ubelly.com/2010/02/building-a-simple-oauth-twitter-applicationI Foto „Sicherheit“: © Didi01 / pixelio.deI Foto „Hypermedia“: Wikimedia User: Radiat-r 40
  • 41. Hypermedia – ChecklisteI Keine Abhängigkeiten von spezifischen KommunikationsprotokollenI Bestehende Methoden dürfen durch API nicht geändert werden (PUT bleibt PUT, etc.)I Keine fixen Ressourcennamen oder HierarchienI Ressourcen sind nicht getypt, nur deren RepräsentationI Kein Wissen über spezifische URIs • Ausnahme: Einstiegspunkt • Alle anderen Links werden „entdeckt“ 41

×