SlideShare ist ein Scribd-Unternehmen logo
REST
Hypermedia und Sicherheit

Jens Broos I 15.12.2011




                            © 2012 Mayflower GmbH
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
Hyper!
Media!


         3
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
Hypermedia – Im Browser



I   Anchor Elemente

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



I   Formulare

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




                                                         5
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
Hypermedia – Ressourcen verknüpfen



Ressource:
http://example.com/orders/1848


Subressource:
http://example.com/orders/1848/shipping-address




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



         Sicherheit   11
REST und Sicherheit



I   Warum brauchen wir Sicherheit?

    – Geschütze Ressourcen
       • Bestellsystem
       • Pay Content, z.B. Maxdome
       • Nachrichten abrufen
       • Kreditkarteninformationen
       • Etc.




                                     12
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
Transportbasierte Sicherheit




                               14
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
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
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
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
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
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
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
Kurzes Resümee




                 22
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
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
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
Zwei verschiedene Ansätze
      von Sicherheit




                            26
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
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
Nachrichtenorientierte Sicherheit




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




                                                31
HMAC Keyed-Hashing for Message Authentication




                             iPad?!


                                                32
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
OpenID und OAuth




                   34
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
OpenID



                OpenID
                Provider




    User                                 WebService
           http://idprovi.der/ids/1848




                                                      36
OAuth



I   Anforderung: „Übertragung“ der Rechte an andere Anwendung

I   Notwendig: Spezifische, eingeschränkte Autorisierung

I   Parteien
    • Service prodiver
    • Consumer
    • User




                                                                37
OAuth Übersicht




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

Weitere ähnliche Inhalte

Ähnlich wie REST - Hypermedia und Sicherheit

Artikel Netzguide: Sicherheit für service- orientierte Architekturen
Artikel Netzguide: Sicherheit für service- orientierte ArchitekturenArtikel Netzguide: Sicherheit für service- orientierte Architekturen
Artikel Netzguide: Sicherheit für service- orientierte Architekturen
Peter Affolter
 
IT-Sicherheit - Themenfokus Website - Netzwerk Elektronischer Geschäftsverkehr
IT-Sicherheit - Themenfokus Website - Netzwerk Elektronischer GeschäftsverkehrIT-Sicherheit - Themenfokus Website - Netzwerk Elektronischer Geschäftsverkehr
IT-Sicherheit - Themenfokus Website - Netzwerk Elektronischer GeschäftsverkehreBusinessLotse-Suedwestfalen-Hagen
 
Trivadis triCast Oracle Centrally Managed Users 18/19c
Trivadis triCast Oracle Centrally Managed Users 18/19cTrivadis triCast Oracle Centrally Managed Users 18/19c
Trivadis triCast Oracle Centrally Managed Users 18/19c
Stefan Oehrli
 
ASP.NET Core Security
ASP.NET Core SecurityASP.NET Core Security
ASP.NET Core Security
Albert Weinert
 
FMK 2016 - Thomas Hirt - FileMaker Server SSL Zertifikate
FMK 2016 - Thomas Hirt - FileMaker Server SSL ZertifikateFMK 2016 - Thomas Hirt - FileMaker Server SSL Zertifikate
FMK 2016 - Thomas Hirt - FileMaker Server SSL Zertifikate
Verein FM Konferenz
 
Security Lab: OIDC in der Praxis
Security Lab: OIDC in der PraxisSecurity Lab: OIDC in der Praxis
Security Lab: OIDC in der Praxis
QAware GmbH
 
SharePoint Claims und FBA
SharePoint Claims und FBASharePoint Claims und FBA
SharePoint Claims und FBA
Thomas Stensitzki
 
Token statt Cookies dank JWT (Java Land 2016)
Token statt Cookies dank JWT (Java Land 2016)Token statt Cookies dank JWT (Java Land 2016)
Token statt Cookies dank JWT (Java Land 2016)
Markus Schlichting
 
Sicherheit in Single-Page-Web-Anwendungen
Sicherheit in Single-Page-Web-AnwendungenSicherheit in Single-Page-Web-Anwendungen
Sicherheit in Single-Page-Web-Anwendungen
Philipp Burgmer
 
Kryptographie für Domino-Administratoren - Verstehen und verwenden!
Kryptographie für Domino-Administratoren - Verstehen und verwenden!Kryptographie für Domino-Administratoren - Verstehen und verwenden!
Kryptographie für Domino-Administratoren - Verstehen und verwenden!
Thomas Bahn
 
Zertifikate für Authetizität, Authentifizierung oder beides?
Zertifikate für Authetizität, Authentifizierung oder beides?Zertifikate für Authetizität, Authentifizierung oder beides?
Zertifikate für Authetizität, Authentifizierung oder beides?
team-WIBU
 
Wozu Portlets – reichen HTML5 und Rest nicht aus für moderne Portale?
Wozu Portlets – reichen HTML5 und Rest nicht aus für moderne Portale?Wozu Portlets – reichen HTML5 und Rest nicht aus für moderne Portale?
Wozu Portlets – reichen HTML5 und Rest nicht aus für moderne Portale?
adesso AG
 
D3 000908 Lotusday Hagen Bcc Id Vault
D3 000908 Lotusday Hagen Bcc Id VaultD3 000908 Lotusday Hagen Bcc Id Vault
D3 000908 Lotusday Hagen Bcc Id Vault
Andreas Schulte
 
Compliance needs transparency
Compliance needs transparencyCompliance needs transparency
Compliance needs transparency
BalaBit
 
Kryptografie und Zertifikate (Cryptoparty)
Kryptografie und Zertifikate (Cryptoparty)Kryptografie und Zertifikate (Cryptoparty)
Kryptografie und Zertifikate (Cryptoparty)
tschikarski
 
Aufbau einer PKI in einer Domino Umgebung
Aufbau einer PKI in einer Domino UmgebungAufbau einer PKI in einer Domino Umgebung
Aufbau einer PKI in einer Domino Umgebung
Alexander Kluge
 
AngularJS mit OAuth 2 und OpenId Connect, w-jax 2015
AngularJS mit OAuth 2 und OpenId Connect, w-jax 2015AngularJS mit OAuth 2 und OpenId Connect, w-jax 2015
AngularJS mit OAuth 2 und OpenId Connect, w-jax 2015
Manfred Steyer
 
SecurityForum April 2015 - Das SSL Dilemma - or One Million Ways to Die in th...
SecurityForum April 2015 - Das SSL Dilemma - or One Million Ways to Die in th...SecurityForum April 2015 - Das SSL Dilemma - or One Million Ways to Die in th...
SecurityForum April 2015 - Das SSL Dilemma - or One Million Ways to Die in th...
Christopher Bleckmann-Dreher
 
Internet Information Services (deutsch)
Internet Information Services (deutsch)Internet Information Services (deutsch)
Internet Information Services (deutsch)
Joerg Krause
 

Ähnlich wie REST - Hypermedia und Sicherheit (20)

Artikel Netzguide: Sicherheit für service- orientierte Architekturen
Artikel Netzguide: Sicherheit für service- orientierte ArchitekturenArtikel Netzguide: Sicherheit für service- orientierte Architekturen
Artikel Netzguide: Sicherheit für service- orientierte Architekturen
 
IT-Sicherheit - Themenfokus Website - Netzwerk Elektronischer Geschäftsverkehr
IT-Sicherheit - Themenfokus Website - Netzwerk Elektronischer GeschäftsverkehrIT-Sicherheit - Themenfokus Website - Netzwerk Elektronischer Geschäftsverkehr
IT-Sicherheit - Themenfokus Website - Netzwerk Elektronischer Geschäftsverkehr
 
Trivadis triCast Oracle Centrally Managed Users 18/19c
Trivadis triCast Oracle Centrally Managed Users 18/19cTrivadis triCast Oracle Centrally Managed Users 18/19c
Trivadis triCast Oracle Centrally Managed Users 18/19c
 
ASP.NET Core Security
ASP.NET Core SecurityASP.NET Core Security
ASP.NET Core Security
 
FMK 2016 - Thomas Hirt - FileMaker Server SSL Zertifikate
FMK 2016 - Thomas Hirt - FileMaker Server SSL ZertifikateFMK 2016 - Thomas Hirt - FileMaker Server SSL Zertifikate
FMK 2016 - Thomas Hirt - FileMaker Server SSL Zertifikate
 
Security Lab: OIDC in der Praxis
Security Lab: OIDC in der PraxisSecurity Lab: OIDC in der Praxis
Security Lab: OIDC in der Praxis
 
SharePoint Claims und FBA
SharePoint Claims und FBASharePoint Claims und FBA
SharePoint Claims und FBA
 
Token statt Cookies dank JWT (Java Land 2016)
Token statt Cookies dank JWT (Java Land 2016)Token statt Cookies dank JWT (Java Land 2016)
Token statt Cookies dank JWT (Java Land 2016)
 
Sicherheit in Single-Page-Web-Anwendungen
Sicherheit in Single-Page-Web-AnwendungenSicherheit in Single-Page-Web-Anwendungen
Sicherheit in Single-Page-Web-Anwendungen
 
Kryptographie für Domino-Administratoren - Verstehen und verwenden!
Kryptographie für Domino-Administratoren - Verstehen und verwenden!Kryptographie für Domino-Administratoren - Verstehen und verwenden!
Kryptographie für Domino-Administratoren - Verstehen und verwenden!
 
Zertifikate für Authetizität, Authentifizierung oder beides?
Zertifikate für Authetizität, Authentifizierung oder beides?Zertifikate für Authetizität, Authentifizierung oder beides?
Zertifikate für Authetizität, Authentifizierung oder beides?
 
Wozu Portlets – reichen HTML5 und Rest nicht aus für moderne Portale?
Wozu Portlets – reichen HTML5 und Rest nicht aus für moderne Portale?Wozu Portlets – reichen HTML5 und Rest nicht aus für moderne Portale?
Wozu Portlets – reichen HTML5 und Rest nicht aus für moderne Portale?
 
D3 000908 Lotusday Hagen Bcc Id Vault
D3 000908 Lotusday Hagen Bcc Id VaultD3 000908 Lotusday Hagen Bcc Id Vault
D3 000908 Lotusday Hagen Bcc Id Vault
 
Compliance needs transparency
Compliance needs transparencyCompliance needs transparency
Compliance needs transparency
 
Kryptografie und Zertifikate (Cryptoparty)
Kryptografie und Zertifikate (Cryptoparty)Kryptografie und Zertifikate (Cryptoparty)
Kryptografie und Zertifikate (Cryptoparty)
 
Beginnr Betakonzept 1
Beginnr Betakonzept 1Beginnr Betakonzept 1
Beginnr Betakonzept 1
 
Aufbau einer PKI in einer Domino Umgebung
Aufbau einer PKI in einer Domino UmgebungAufbau einer PKI in einer Domino Umgebung
Aufbau einer PKI in einer Domino Umgebung
 
AngularJS mit OAuth 2 und OpenId Connect, w-jax 2015
AngularJS mit OAuth 2 und OpenId Connect, w-jax 2015AngularJS mit OAuth 2 und OpenId Connect, w-jax 2015
AngularJS mit OAuth 2 und OpenId Connect, w-jax 2015
 
SecurityForum April 2015 - Das SSL Dilemma - or One Million Ways to Die in th...
SecurityForum April 2015 - Das SSL Dilemma - or One Million Ways to Die in th...SecurityForum April 2015 - Das SSL Dilemma - or One Million Ways to Die in th...
SecurityForum April 2015 - Das SSL Dilemma - or One Million Ways to Die in th...
 
Internet Information Services (deutsch)
Internet Information Services (deutsch)Internet Information Services (deutsch)
Internet Information Services (deutsch)
 

Mehr von Mayflower GmbH

Mit Maintenance umgehen können- Fixt du noch Bugs oder lieferst du schon neue...
Mit Maintenance umgehen können- Fixt du noch Bugs oder lieferst du schon neue...Mit Maintenance umgehen können- Fixt du noch Bugs oder lieferst du schon neue...
Mit Maintenance umgehen können- Fixt du noch Bugs oder lieferst du schon neue...
Mayflower GmbH
 
Why and what is go
Why and what is goWhy and what is go
Why and what is go
Mayflower GmbH
 
Agile Anti-Patterns
Agile Anti-PatternsAgile Anti-Patterns
Agile Anti-Patterns
Mayflower GmbH
 
JavaScript Days 2015: Security
JavaScript Days 2015: SecurityJavaScript Days 2015: Security
JavaScript Days 2015: Security
Mayflower GmbH
 
Vom Entwickler zur Führungskraft
Vom Entwickler zur FührungskraftVom Entwickler zur Führungskraft
Vom Entwickler zur Führungskraft
Mayflower GmbH
 
Produktive teams
Produktive teamsProduktive teams
Produktive teams
Mayflower GmbH
 
Salt and pepper — native code in the browser Browser using Google native Client
Salt and pepper — native code in the browser Browser using Google native ClientSalt and pepper — native code in the browser Browser using Google native Client
Salt and pepper — native code in the browser Browser using Google native Client
Mayflower GmbH
 
Plugging holes — javascript memory leak debugging
Plugging holes — javascript memory leak debuggingPlugging holes — javascript memory leak debugging
Plugging holes — javascript memory leak debugging
Mayflower GmbH
 
Usability im web
Usability im webUsability im web
Usability im web
Mayflower GmbH
 
Rewrites überleben
Rewrites überlebenRewrites überleben
Rewrites überleben
Mayflower GmbH
 
JavaScript Security
JavaScript SecurityJavaScript Security
JavaScript Security
Mayflower GmbH
 
50 mal produktiver - oder warum ich gute Teams brauche und nicht gute Entwick...
50 mal produktiver - oder warum ich gute Teams brauche und nicht gute Entwick...50 mal produktiver - oder warum ich gute Teams brauche und nicht gute Entwick...
50 mal produktiver - oder warum ich gute Teams brauche und nicht gute Entwick...
Mayflower GmbH
 
Responsive Webdesign
Responsive WebdesignResponsive Webdesign
Responsive Webdesign
Mayflower GmbH
 
Native Cross-Platform-Apps mit Titanium Mobile und Alloy
Native Cross-Platform-Apps mit Titanium Mobile und AlloyNative Cross-Platform-Apps mit Titanium Mobile und Alloy
Native Cross-Platform-Apps mit Titanium Mobile und Alloy
Mayflower GmbH
 
Pair Programming Mythbusters
Pair Programming MythbustersPair Programming Mythbusters
Pair Programming Mythbusters
Mayflower GmbH
 
Shoeism - Frau im Glück
Shoeism - Frau im GlückShoeism - Frau im Glück
Shoeism - Frau im Glück
Mayflower GmbH
 
Bessere Software schneller liefern
Bessere Software schneller liefernBessere Software schneller liefern
Bessere Software schneller liefern
Mayflower GmbH
 
Von 0 auf 100 in 2 Sprints
Von 0 auf 100 in 2 SprintsVon 0 auf 100 in 2 Sprints
Von 0 auf 100 in 2 Sprints
Mayflower GmbH
 
Piwik anpassen und skalieren
Piwik anpassen und skalierenPiwik anpassen und skalieren
Piwik anpassen und skalieren
Mayflower GmbH
 
Agilitaet im E-Commerce - E-Commerce Breakfast
Agilitaet im E-Commerce - E-Commerce BreakfastAgilitaet im E-Commerce - E-Commerce Breakfast
Agilitaet im E-Commerce - E-Commerce Breakfast
Mayflower GmbH
 

Mehr von Mayflower GmbH (20)

Mit Maintenance umgehen können- Fixt du noch Bugs oder lieferst du schon neue...
Mit Maintenance umgehen können- Fixt du noch Bugs oder lieferst du schon neue...Mit Maintenance umgehen können- Fixt du noch Bugs oder lieferst du schon neue...
Mit Maintenance umgehen können- Fixt du noch Bugs oder lieferst du schon neue...
 
Why and what is go
Why and what is goWhy and what is go
Why and what is go
 
Agile Anti-Patterns
Agile Anti-PatternsAgile Anti-Patterns
Agile Anti-Patterns
 
JavaScript Days 2015: Security
JavaScript Days 2015: SecurityJavaScript Days 2015: Security
JavaScript Days 2015: Security
 
Vom Entwickler zur Führungskraft
Vom Entwickler zur FührungskraftVom Entwickler zur Führungskraft
Vom Entwickler zur Führungskraft
 
Produktive teams
Produktive teamsProduktive teams
Produktive teams
 
Salt and pepper — native code in the browser Browser using Google native Client
Salt and pepper — native code in the browser Browser using Google native ClientSalt and pepper — native code in the browser Browser using Google native Client
Salt and pepper — native code in the browser Browser using Google native Client
 
Plugging holes — javascript memory leak debugging
Plugging holes — javascript memory leak debuggingPlugging holes — javascript memory leak debugging
Plugging holes — javascript memory leak debugging
 
Usability im web
Usability im webUsability im web
Usability im web
 
Rewrites überleben
Rewrites überlebenRewrites überleben
Rewrites überleben
 
JavaScript Security
JavaScript SecurityJavaScript Security
JavaScript Security
 
50 mal produktiver - oder warum ich gute Teams brauche und nicht gute Entwick...
50 mal produktiver - oder warum ich gute Teams brauche und nicht gute Entwick...50 mal produktiver - oder warum ich gute Teams brauche und nicht gute Entwick...
50 mal produktiver - oder warum ich gute Teams brauche und nicht gute Entwick...
 
Responsive Webdesign
Responsive WebdesignResponsive Webdesign
Responsive Webdesign
 
Native Cross-Platform-Apps mit Titanium Mobile und Alloy
Native Cross-Platform-Apps mit Titanium Mobile und AlloyNative Cross-Platform-Apps mit Titanium Mobile und Alloy
Native Cross-Platform-Apps mit Titanium Mobile und Alloy
 
Pair Programming Mythbusters
Pair Programming MythbustersPair Programming Mythbusters
Pair Programming Mythbusters
 
Shoeism - Frau im Glück
Shoeism - Frau im GlückShoeism - Frau im Glück
Shoeism - Frau im Glück
 
Bessere Software schneller liefern
Bessere Software schneller liefernBessere Software schneller liefern
Bessere Software schneller liefern
 
Von 0 auf 100 in 2 Sprints
Von 0 auf 100 in 2 SprintsVon 0 auf 100 in 2 Sprints
Von 0 auf 100 in 2 Sprints
 
Piwik anpassen und skalieren
Piwik anpassen und skalierenPiwik anpassen und skalieren
Piwik anpassen und skalieren
 
Agilitaet im E-Commerce - E-Commerce Breakfast
Agilitaet im E-Commerce - E-Commerce BreakfastAgilitaet im E-Commerce - E-Commerce Breakfast
Agilitaet im E-Commerce - E-Commerce Breakfast
 

REST - Hypermedia und Sicherheit

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