Sicherheit auf API-Ebene

8 Nov

Als ich dabei war, ein paar bekannte REST-APIs zu analysieren, ist mir aufgefallen, dass ich mir erst noch einen Überblick über Sicherheitsaspekte auf API-Ebene machen sollte.

Was muss beachtet werden?

  • Nur authentifizierte Nutzer haben Zugriff auf authentifizierungspflichtige  Ressourcen.
  • Nur autorisierte Nutzer haben Zugriff auf autorisierungspflichtige  Ressourcen.
  • Vertraulichkeit und Integrität von sensitiven Daten ist  gewährleistet.
  • Kein Nutzer kann die Schnittstelle gewollt oder ungewollt übermäßig beanspruchen.

Im Rahmen der Authentifizierung und Autorisierung muss beachtet werden, dass serverseitig keine Benutzersession angelegt werden darf. Cookies oder eine Art JSessionid verhindern, dass jede Anfrage gegen die Schnittstelle alle zu ihrer Verarbeitung benötigten Informationen enthält. Sonst kann nur derjenige Server, der die Sessiondaten kennt, antworten (schlecht für Skalierbarkeit und nicht RESTful).

Vertraulichkeit und Integrität der übertragenen Daten kann im Endeffekt nur über eine Verschlüsselung der gesamten Kommunikation erfolgen (TLS!).

Mögliche Verfahren

  „Dienst“ ist hier die die Schnittstelle.

API-Schlüssel:

Ein API-Schlüssel ist eine eindeutige Zeichenketten, die vom Dienst bereitgestellt und vom Nutzer bei jeder Anfrage mitgesendet werden muss. Der Hauptanwendungsfall dieser Schlüssel ist die Identifizierung von Schnittstellennutzern zwecks Protokollierung und Überwachung der Dienstnutzung. Beispiel: Google Maps API

HTTP-Authentifizierung:

HTTP sieht vor, dass beim Zugriff auf eine authentifizierungspflichtige Ressource als Antwort der Statuscode 401 inklusive dem WWW-Authenticate-Header gesendet wird. Der Server erwartet nun von dem Client, dass er beim erneuten Zugriff auf die Ressource Authentifizierungsinformationen mitsendet.

Im Fall der Basic Authentication bestehen diese Informationen aus der Verkettung von Benutzername und Passwort sowie darauffolgender Base64-Kodierung. Da dieses Verfahren keine Verschlüsselung beinhaltet, sollte es auf jeden Fall nur über eine bestehende TLS-Verbindung eingesetzt werden.

Die Digest Authentication beseitigt durch Anwendung kryptografischer Verfahren einige Schwächen der Basic Authentication, dennoch muss wegen immer noch möglichen Man-in-the-middle-Angriffen eine Authentifizierung ebenfalls über eine bestehende TLS-Verbindung erfolgen.

OpenID/OAuth

OpenID und OAuth sind standardisierte Verfahren, die Lösungen für typische Anforderungen im Web2.0 bieten. OpenID ermöglicht die Authentifizierung eines Nutzers über einen eindeutigen Identifikator, normalerweise eine URL, während OAuth einen Autorisierungs- und Datenaustausch-Mechanismus zwischen zwei Diensten zur Verfügung stellt. Beiden Protokollen ist gemein, dass die Zugangdaten eines Nutzers immer nur an einer zentralen Stelle gespeichert sind.

Mit OpenID kann die Authentifizierung eines Nutzers an einen Identitäts-Provider ausgelagert werden.  Bei diesem registriert sich ein Nutzer einmalig und nutzt seine dortigen Zugangsdaten zur Authentifizierung bei beliebig vielen Diensten.

Obwohl ursprünglich nicht dafür entwickelt, bietet auch OAuth implizit eine Authentifizierungsmöglichkeit für Schnittstellenutzer. Grungedanke ist aber, dass ein Nutzer einem Dienst (=Consumer) die Berechtigung erteilt, in dessen Namen auf bestimmte Ressourcen eines sogenannten Service-Providers zuzugreifen. Desweiteren spielen verschiedene Arten sogenannter Tokens eine wichtige Rolle. Ein solches ist eine Zeichenkette, die an Stelle von Nutzername und Passwort verwendet wird, um Zugriff auf eine Ressource zu gewähren.

Relevanz für ginkgo

Ginkgo-Nutzer können sich sowohl über einen OAuth-Service-Provider (aktuell nur Twitter) als auch über Nutzername/Passwort bei ginkgo anmelden.

Für die OAuth(2)-Authentifizierung wird folgendes Sequenzdiagramm durchlaufen (vgl. auch hier):

Resource Owner: Ginkgo-Benutzer mit Twitter-Account.

Browser: Applikation, welche die ginkgo-REST-API nutzt.

Web-API: Die ginkgo-REST-API.

Facebook: (Service-Provider), kann auch Twitter sein.

OAuth wird hier nur benutzt, um den Nutzer über Accountinformationen von Facebook zu identifizieren. Salopp gesagt, wird Facebook also zum Identitätsprovider (vgl. OpenID!).

Für den Login mit Nutzername/Passwort bietet sich an, eine HTTP-Basic-Authentifizierung über TLS zu verwenden. Alternativ könnte ginkgo selbst zum OAuth-Service-Provider werden, eine entsprechende Login-Seite anbieten und selbst Tokens ausstellen (komplexer!).

Schreibe einen Kommentar

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s

%d Bloggern gefällt das: