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

Vorführender

Präsentationsnotizen

Eindeutige Identifikation URI als ID -> Ressource weltweit eindeutig identifizierbar Namensschema ist standardisiert und muss nicht neu erfunden werden Standardmethoden Verben Idempotenz: Im Falle einer Unterbrechung Ressource wieder abfragen und dasselbe Ergebnis bekommen Unterschiedliche Repräsentationen Header: Accept: Standardisiert HTML hat höchste Priorität im Header und wird abgefragt, wenn nichts gesetzt wird Statuslosigkeit Nicht gewollt: serverseitig abgelegter, transierter, clientspezifischer Status Über Dauer eines Requests hinweg Zustand soll auf Client bleiben, Zustand dabei Bestandteil von Repräsentation vom Server Zustand alternativ in Ressource umwandeln Bsp. Warenkorb als Ressource und damit „Linkfähig“ Warum? Skalierbarkeit Koppelung: Mehrere Server möglich Aufeinander folgende Anforderungen müssen nicht von selben Serverinstanz bearbeitet werden

3

Hyper! Media!

Vorführender


Hypertext: Nicht linear verbundene textuelle Informationen Hypermedia: Grafik, Videos, andere Multimediaformate

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

Vorführender


Überführung eines Clients in verschiedene Zustände durch das Entlanghangeln an Links Benutzer wird nicht zugemutet ID zu konstruieren notwendige Metainformationen mit Daten in Repräsentation geliefert Negativbeispiel: Domain Masking Einzelne URI, die sich bei Bearbeitung nicht ändert Schlecht für: Bookmarks, Refresh, Back/Forward, nicht indizierbar

5

I Anchor Elemente

<a href=“http://www.mayflower.de“>Mayflower</a>

I Formulare

<form action=“nextSite.php“ method=“GET/POST“>

Hypermedia – Im Browser

Vorführender


Link Browser kennen das Format, einfache Darstellung. Client folgt HTML Kernprinzip von HTML, mit GET ausgeführt Server teilt Client mit, welchen Links er folgen kann Formular GET oder POST POST: application/x-www-urlencoded GET in query parametern Guter Stil: Redirect after POST

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

Vorführender


Entkoppelung: Client muss nicht an Serveränderungen angepasst werden Transparenz: Client folgt „stumpf“ den Servervorgaben Reduktion von Metadaten: Beschreibung, was mit bestimmter Ressource und deren Repräsentation getan werden kann ist nicht Bestandteil einer EXTERNEN, MENSCHEN- oder MASCHINENLESBAREN Dokumentation Bestandteil der Ressourcenrepräsentation selbst AUSSERDEM: Unterteilung in Browserbasiertes Web und Anwendung-zu-Anwendung-Kommunikation ist sinnlos Browser ist auch Anwendung Jede Serverseitige Aktion sollte auf ein Bedürfnis des Menschen zurückgehen API automatisieren an einem UI sichtbare Aktionen

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“ />



</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

Vorführender


Kein Wissen über spezifische URIs Ausnahme: Einstiegspunkt Alle anderen Links werden „entdeckt“

11

Sicherheit

arREST

Vorführender


Kunden klar machen: Mit Verschlüsselung, Signaturen, und anderen Sicherheitsmechanismen Steigende Kosten für Lizenzen, Zertifikate, zusätzliche Hardware Steigender Entwicklungs- und Administrationsaufwand DAHER: Erster Schritt: Kritische Betrachtung der tatsächlichen Sicherheitsrisiken Konkrete Anforderungen

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

Vorführender


Transportmechanismus

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

Vorführender


Clientzertifikat erfordert hohen Aufwand Verhindert Gedanken der Unabhängigkeit Man in the middle: Abhören der Leitung durch Intermediäre Auch Ändern der Daten möglich

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

Vorführender


authentisieren: rechtgültig machen, glaubwürdig machen authentifizieren: Echtheit bezeugen, beglaubigen

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

Vorführender


Auth Challenge: Client muss richtige Authentisierungsinformationen mitsenden, die zum einen dem Schema entsprechen (z.B. basic) und Geltungsbereich Realm Weitere Auths ClientLogin von Google

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

Vorführender


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

Vorführender


Leicht zu implementieren In meisten Bibliotheken enthalten Schwächen: Passwort quasi im Klartext, weil base64 keine Kodierung ist Ursprünglich Übertragung von Texten über Kanäle mit beschränktem Basiszeichensatz Identität des Servers wird nicht sichergestellt Man-in-the-middle-Attacken möglich, d.h. Modifizierung auf dem Weg zum Server Replay Angriff Beobachtet Angreifer auch nur eine einzige Nachricht, kann er sie ganz oder teilweise noch einmal versenden Konsequenz: Ohne weitere Sicherheitsmaßnahmen ungeeignet

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

Vorführender


nonce: Vom Server generierter Wert Beliebige Zahl oder Zeichenkette, Wird vom Server nur einmal erzeugt Vorteile: Passwort kann nicht mitgelesen werden Nonce und Zeitstempel verhindern Replay-Attacken (Beobachtet Angreifer auch nur eine einzige Nachricht, kann er sie ganz oder teilweise noch einmal versenden) Wenig verbreitet: Nachricht beim Digest immer noch nicht verschlüsselt oder gegen Modifikation geschützt Man-in-the-middle-Attacken möglich Nachricht abfangen, modifizieren weiterleiten, ohne dass es jemand merkt

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

Vorführender


nonce: Vom Server generierter Wert Beliebige Zahl oder Zeichenkette, Wird vom Server nur einmal erzeugt Vorteile: Passwort kann nicht mitgelesen werden Nonce und Zeitstempel verhindern Replay-Attacken (Beobachtet Angreifer auch nur eine einzige Nachricht, kann er sie ganz oder teilweise noch einmal versenden) Wenig verbreitet: Nachricht beim Digest immer noch nicht verschlüsselt oder gegen Modifikation geschützt Man-in-the-middle-Attacken möglich Nachricht abfangen, modifizieren weiterleiten, ohne dass es jemand merkt

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

Vorführender


Beispiel für Auth Server Konfiguration Apache, Einbinden von LDAP NTLM DB Htaccess Eigentlicher REST Server kümmert sich nicht um SSL , sondern nimmt an, dass Benutzer identifiziert wurde Bzw: STATELESS Nutzen: Trennen von Authentifizierung/Autorisierung und Serverlogik

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

Vorführender


Im Hauptspeicher vorgehaltene / benutzerspezifische Datenstruktur zu identifizieren. Hashtabelle Für jeden Benutzer, ob angemeldet oder nicht, gibt es SchlüsselWert Paare��Aber: Skalierbarkeit = mehrere Server: Sitzungsdaten müssen synchronisiert werden Oder sicherstellen, dass Requests eines einzelnen Client von bestimmten Server beantwortet werden, was Skalierung wiederspricht Beim Herunterfahren oder Absturz des Serversprozesses gehen sessionbezogene Daten verloren Auswirkung eines einzelnen Requests nicht mehr nur vom Request selbst, sondern auch von vorherigen Requests abhängig Nicht mehr restful bzw Idempotent Client muss eine Reihe von Schritten als Vorarbeit verrichten um eigentliche Aufgabe zu erledigen

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


WebServer

Auth Server


WebServer

Auth Server

Client

Vorführender


Eigentlicher REST Server kümmert sich nicht um SSL , sondern nimmt an, dass Benutzer identifiziert wurde Bzw: STATELESS Nutzen: Trennen von Authentifizierung/Autorisierung und Serverlogik

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

Vorführender


Probleme: Was ist mit Subressourcen Dekodierung muss im Client stattfinden Was ist, wenn sich Rollen ändern und benutzer die Token für sich speichert

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

Vorführender


Wird eingesetzt bei: Amazon Webservices Google Commit Hooks-API von Google Code

31


32


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

Vorführender


Anmeldung bei OpenID Provider erzeugt eine URL, die den Benutzer beschreibt

36

OpenID

OpenID Provider

User WebService

http://idprovi.der/ids/1848

Vorführender


Neben username / password auch möglich: Clientzertifikat Biometrische verfahren, Etc

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

Vorführender


© 2012 Mayflower GmbH

Dipl.-Inform. (FH) Jens Broos

[email protected]

+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

Vorführender


Checkliste, ob Design hinreichend Hypertext-getrieben ist

rest - hypermedia und sicherheit

Technology