Facebook Login

Login-Sicherheit

Dank Funktionen von Facebook Login wie Zugriffsschlüssel und Berechtigungen sind Nutzer sowie Apps geschützt. Trotzdem müssen Apps einige Sicherheitsfunktionen selbst implementieren.

Sicherheitscheckliste

In der unten stehenden Liste findest du alle Funktionen, die eine App mit Facebook Login mindestens implementieren sollte. Andere Funktionen richten sich nach deiner speziellen App. Du solltest dabei immer nach Wegen suchen, deine App so sicher wie möglich zu machen. Unsichere Apps verlieren das Vertrauen der Nutzer und werden von ihnen nicht mehr verwendet.

Dein App-Geheimcode darf niemals in clientseitigem oder dekompilierbarem Code vorhanden sein.

Signiere alle Server-an-Server-Graph-API-Aufrufe mit deinem App-Geheimcode.

Verwende eindeutige, kurzlebige Tokens für Clients.

Vertraue nicht darauf, dass Zugriffsschlüssel, die von deiner App verwendet werden, auch von ihr erstellt wurden.

Verwende beim Login-Dialog den Statusparameter.

Verwende möglichst unsere offiziellen SDKs.

Sperre deine Facebook-App-Einstellungen, um die Angriffsfläche deiner App zu verringern.

Verwende HTTPS.

App-Geheimcode

Der App-Geheimcode kommt bei einigen Anmeldevorgängen zum Einsatz, um Zugriffsschlüssel zu erstellen. Er soll dafür sorgen, dass nur vertrauenswürdige Nutzer*innen Zugriff auf deine App erhalten. Du kannst damit ganz einfach einen App-Zugriffsschlüssel erstellen, der API-Anfragen im Namen eine*einer Nutzer*in deiner App durchführt. Deshalb darf der App-Geheimcode unter keinen Umständen kompromittiert werden.

Der App-Geheimcode oder ein App-Zugriffsschlüssel darf daher niemals in Code enthalten sein.

Wir empfehlen dir, App-Zugriffsschlüssel nur auf deinen App-Servern zu speichern, damit maximale Sicherheit gewährleistet ist. Native Apps sollten nur mit deinem Server kommunizieren. Er leitet dann die API-Anfragen an Facebook über den App-Zugriffsschlüssel weiter. Wenn du bei „App-Typ“ in den Erweiterten Einstellungen im App-DashboardNative/Desktop eingestellt hast, gehen wir deshalb davon aus, dass deine native App den App-Geheimcode oder einen App-Zugriffsschlüssel in der Binärdatei enthält, und blockieren daraufhin jegliche Aufrufe, die mit einem App-Zugriffsschlüssel durchgeführt werden. Die API verhält sich so, als wäre kein Zugriffsschlüssel angegeben worden.

Sichere serverseitige Aufrufe über appsecret_proof

Du kannst Übergriffe durch Schadprogramme und Spammer vermeiden, indem du eine Signierung der Server-zu-Server-Aufrufe an die API von Facebook mit dem appsecret_proof-Parameter erforderlich machst. Der App-Geheimcode-Nachweis ist ein SHA256-Hash deines Zugriffsschlüssels, in dem dein App-Geheimcode als Schlüssel verwendet wird. Den App-Geheimcode findest du in deinem App-Dashboard unter Einstellungen > Allgemein.

Nachweis generieren

Das folgende Codebeispiel zeigt, wie der Aufruf in PHP aussieht:

$appsecret_proof= hash_hmac('sha256', $access_token.'|'.time(), $app_secret);

Einige Betriebssysteme und Programmiersprachen geben einen Zeitstempel zurück, der eine Gleitkommazahl ist. Wandle den Wert in eine Ganzzahl um, bevor der App-Geheimcode-Nachweis berechnet wird. Einige Programmiersprachen erstellen den Hash als ein Digest-Objekt. Der Hash sollte als Hexadezimalwert ausgedrückt werden.

Nachweis hinzufügen

Füge zu jedem deiner Aufrufe das Ergebnis als appsecret_proof-Parameter hinzu und lege für appsecret_time den Zeitstempel fest, den du beim Hashen des App-Geheimcodes verwendet hast:

curl \
  -F 'access_token=ACCESS-TOKEN' \
  -F 'appsecret_proof=APP-SECRET-PROOF' \
  -F 'appsecret_time=APP-SECRET-TIME' \
  -F 'batch=[{"method":"GET", "relative_url":"me"},{"method":"GET", "relative_url":"me/accounts"}]' \
  https://graph.facebook.com

App-Geheimcode-Nachweise mit Zeitstempel gelten nach fünf Minuten als abgelaufen. Daher wird empfohlen, bei jedem Graph API-Aufruf inline einen neuen Nachweis zu erstellen.

Nachweis anfordern

Um App-Geheimcode erforderlich für alle API-Aufrufe zu aktivieren, gehe zum Dashboard der Meta-App und klicke im Menü links auf App-Einstellungen > Erweitert. Scrolle zum Bereich Sicherheit und klicke auf den Schalter App-Geheimcode erforderlich.

Wenn diese Einstellung aktiviert ist, müssen alle vom Client initiierten Aufrufe über einen Proxy über dein Backend geleitet werden, wo der appsecret_proof-Parameter der Anfrage hinzugefügt werden kann, bevor sie an die Graph API gesendet wird. Andernfalls schlägt der Aufruf fehl.

Sichere clientseitige Aufrufe über kurzlebige Tokens und Code-Flow

In manchen Konfigurationen verwenden Apps dasselbe langlebige Token für verschiedene Clients. Das ist keine gute Idee. Verwende stattdessen kurzlebige Tokens, die mit dem Code-Flow erstellt werden. Eine Beschreibung dazu findest du in der Dokumentation zu Zugriffsschlüsseln.

Token-Hijacking

Um zu verstehen, wie dies vonstatten geht, stell dir eine native iOS-App vor, die einen API-Aufruf durchführen möchte. Statt ihn direkt durchzuführen, kommuniziert sie aber mit einem Server, der derselben App gehört, und leitet an diesen Server einen Schlüssel weiter, der über das iOS-SDK erstellt wurde. Der Server verwendet dann diesen Schlüssel, um API-Aufrufe durchzuführen.

Der Endpunkt, über den der Server den Schlüssel erhält, könnte kompromittiert sein und andere Personen könnten Zugriffsschlüssel für vollkommen andere Apps dorthin weiterleiten. Selbstverständlich wäre das komplett unsicher, aber du kannst dich dagegen schützen. Du solltest niemals annehmen, dass Zugriffsschlüssel von der App generiert wurden, die sie verwendet. Prüfe sie stattdessen mit Debugging-Endpunkten.

Zugriffsschlüssel-Gültigkeit regelmäßig überprüfen

Falls du nicht mit den Facebook-SDKs arbeitest, musst du regelmäßig die Gültigkeit des Zugriffsschlüssels überprüfen. Selbst wenn für Zugriffsschlüssel Ablaufdaten geplant sind, können Schlüssel aus Sicherheitsgründen vorzeitig ablaufen. Wenn du in deiner App keine Facebook-SDKs verwendest, ist es außerordentlich wichtig, manuell häufige Überprüfungen der Gültigkeit des Schlüssels (mindestens täglich) einzuplanen, um sicherzustellen, dass deine App nicht auf einem Schlüssel basiert, der aus Sicherheitsgründen vorzeitig abgelaufen ist.

State-Parameter

Wenn du den Facebook-Login-Dialog auf deiner Webseite verwendest, solltest du den state-Parameter nutzen. Mit diesem eindeutigen String sicherst du deine App gegen Cross-Site-Request-Forgery-Angriffe.

Strict-Modus aktivieren

Der Strict-Modus schützt Apps, indem er verhindert, dass böswillige Nutzer deine Weiterleitung missbrauchen. Der Strict-Modus ist für alle Apps erforderlich.

Bevor du den Strict-Modus im App-Dashboard aktivierst, musst du sicherstellen, dass dein derzeitiger Weiterleitungs-Traffic weiterhin funktioniert. Nimm dazu die folgenden Handlungen in den Facebook Login-Einstellungen vor:

  • Verwende bei Apps mit dynamischen Weiterleitungs-URIs den State-Parameter, um die dynamischen Informationen an eine begrenzte Anzahl von Weiterleitungs-URIs zu übergeben. Füge dann die einzelnen Weiterleitungs-URIs zur Liste „Gültige OAuth Redirect URIs“ hinzu.

  • Füge bei Apps mit einer begrenzten Anzahl von Weiterleitungs-URIs die einzelnen Weiterleitungs-URIs zur Liste „Gültige OAuth Redirect URIs“ hinzu.

  • Bei Apps, die nur das Facebook-JavaScript-SDK verwenden, ist der Weiterleitungs-Traffic bereits geschützt. Es sind keine weiteren Maßnahmen von deiner Seite erforderlich.

Aktiviere den Strict-Modus, nachdem du diese Maßnahmen vorgenommen hast.

So funktioniert der Strict-Modus

Der Strict-Modus schützt davor, dass Angreifer deine Umleitung missbrauchen, da eine genaue Übereinstimmung mit deiner „Gültige OAuth Redirect URIs“-Liste erforderlich ist. Wenn deine Liste für „Gültige OAuth Redirect URIs“ beispielsweise www.beispiel.com enthält, lässt der Strict-Modus www.beispiel.com/token nicht als gültige Weiterleitung zu. Er lässt außerdem keine zusätzlichen Abfrageparameter zu, die nicht in der „Gültige OAuth Redirect URIs“-Liste enthalten sind.

Verwende HTTPS

Verwende HTTPS anstelle von HTTP als Internetprotokoll, da es Daten verschlüsselt überträgt. Bei HTTPS bleiben die übertragenen Daten geheim und werden vor Lauschangriffen geschützt. Außerdem wird so verhindert, dass Daten während der Übertragung manipuliert werden, z. B. durch Werbung oder schädlichen Code.

Seit dem 6. Oktober 2018 ist für alle Apps HTTPS obligatorisch.

JavaScript-SDK für Facebook Login aktivieren

Wenn du angibst, dass du das JavaScript-SDK für die Anmeldung verwendest, indem du die Option Login mit JavaScript SDK auf „Ja“ umstellst, muss die Domain deiner Seite, die das SDK hostet, mit einem der Einträge in der Liste Für das JavaScript-SDK zugelassene Domains übereinstimmen. So wird gewährleistet, dass Zugriffsschlüssel nur bei Rückrufen von autorisierten Domains ausgegeben werden. Das Facebook SDK for Javascript unterstützt ausschließlich HTTPS-Seiten zur Authentifizierung.

Bei JSSDK-Integrationen, die bis einschließlich 10. August 2021 erstellt wurden, wird die Liste mit Werten aufgefüllt, die auf der aktuellen Nutzung basieren. Es sind keine weiteren Maßnahmen von deiner Seite erforderlich.

Bei neuen Integrationen, die nach dem 10. August 2021 erstellt wurden, musst du selbst Werte in die Liste einfügen.

Solltest du feststellen, dass das Feld der JSSDK-Domain deiner App URLs enthält, die mit *. beginnen, ersetze diese bitte durch eindeutige Domain-URLs, um für zusätzliche Sicherheit zu sorgen.

Weiterleitungs-URI überprüfen

Wenn ein böswilliger Nutzer einen nicht autorisierten „redirect_uri“-Parameter bei der Login-Anfrage verwendet, sind Angriffe auf offene Weiterleitungen möglich, die dazu führen können, dass vertrauliche Informationen wie Zugriffsschlüssel über den Abfrage-String oder ein Fragment in der Weiterleitungs-URI nach außen dringen können.

Du solltest bei benutzerdefinierten Web-Integrationen in deinen App-Einstellungen stets autorisierte Weiterleitungs-URIs bereitstellen, um solche Angriffe zu verhindern. Während der Ausführung der Login-Anfrage wird dann der „redirect_uri“-Parameter mit den Einträgen in der Liste abgeglichen. Die vollständige URI muss, einschließlich aller Parameter, genau übereinstimmen. Davon ausgenommen ist nur der „state“-Parameter, dessen Wert nicht berücksichtigt wird.

App-interne Browser und das JavaScript-SDK

Das JavaScript-SDK ist normalerweise auf Pop-ups und Rückrufe angewiesen, um ein Login abzuschließen. Da einige App-interne Browser Pop-ups unterdrücken, kann dieser Vorgang fehlschlagen. Ist das der Fall, sucht das SDK mithilfe eines Zugriffsschlüssels nach einer Umleitung zur Seite, die ihn ausgelöst hat. Das SDK kann diesen Vorgang nur dann sicher durchführen, wenn die vollständige URI der Seite in der „Gültige OAuth Redirect URIs“-Liste aufgeführt ist.

Wenn Anwendungsfälle mit App-internen Browsern für deine Web-App von Bedeutung sind, solltest du die Domain deiner Login-Seite zu den zulässigen Domains und die zugehörige vollständige URI (einschließlich des Pfades und der Abfrageparameter) zu den gültigen OAuth Redirect URIs hinzufügen. Wenn bei deinen URIs verschiedene Varianten existieren, über die der Login für deine App erfolgt, kannst du manuell eine fallback_redirect_uri als Option beim FB.login()-Abruf spezifizieren, damit du nur einen Eintrag zur Liste deiner gültigen OAuth Redirect URIs hinzufügen musst.

Facebook-App-Einstellungen sperren

Aktiviere bzw. deaktiviere alle Authentifizierungsvorgänge, die die App nicht verwendet, um die Angriffsfläche zu minimieren.

  • Verwende Code-generierte kurzlebige Zugriffsschlüssel in Clients anstelle von Client-generierten Tokens oder vom Server bereitgestellten langlebigen Tokens. Bei einem codegenerierten kurzlebigen Zugriffsschlüssel muss der App-Server den Code gegen ein Token eintauschen, was sicherer ist, als ein Token über den Browser zu erhalten. Apps sollten diesen Vorgang möglichst bevorzugen, um besseren Schutz zu bieten. Wenn eine App nur diesen Vorgang aktiviert hat, können Schadprogramme, die auf Computern von Nutzern ausgeführt werden, nicht auf den Zugriffsschlüssel zugreifen und ihn auch nicht zu böswilligen Zwecken missbrauchen. Weitere Informationen erhältst du in der Dokumentation zu Zugriffsschlüsseln.

  • Deaktiviere die Client-OAuth-Anmeldung, wenn deine App sie nicht verwendet. Die Client-OAuth-Anmeldung ist der globale An-/Aus-Schalter zur Verwendung von OAuth-Client-Schlüsselvorgängen. Wenn deine App keine OAuth-Vorgänge verwendet, die Facebook-Login-SDKs beinhalten, solltest du diesen Vorgang deaktivieren. Beachte dabei jedoch, dass du keine Berechtigungen für einen Zugriffsschlüssel anfordern kannst, wenn die Client-OAuth-Anmeldung deaktiviert ist. Diese Einstellung findest du unter „Produkte“ > „Facebook Login“ > „Einstellungen“ im App-Dashboard.

  • Deaktiviere den Web-OAuth-Vorgang oder gib eine Weiterleitungs-Positivliste an. Über die Einstellungen für die Web-OAuth-Anmeldung können alle OAuth-Client-Zugriffsschlüssel, die den Facebook-Web-Login-Dialog verwenden, Schlüssel an deine eigene Webseite zurückleiten. Diese Einstellung findest du unter „Produkte“ > „Facebook Login“ > „Einstellungen“ im App-Dashboard. Deaktiviere diese Einstellung, wenn du keinen individuellen Web-Login-Vorgang entwickelst, der Facebook-Login-SDKs im Web verwendet.

  • HTTPS verwenden. Diese Einstellung erfordert HTTPS für OAuth-Umleitungen und alle Facebook-JavaScript-SDK-Aufrufe, die einen Zugriffsschlüssel zurückgeben oder erfordern, dürfen ausschließlich von HTTPS-Seiten aus erfolgen. Alle ab März 2018 neu erstellten Apps besitzen diese Einstellung standardmäßig und du solltest die Migration von vorhandenen Apps auf HTTPS-URLs bis 6. Oktober 2018 planen. Die meisten führenden Hosts von Cloud-Apps bieten die kostenlose und automatische Konfiguration von TLS-Zertifikaten für deine Apps. Wenn du deine App selbst hostest oder dein Hosting-Dienst HTTPS nicht standardmäßig anbietet, erhältst du ein kostenloses Zertifikat für deine Domain(s) von Let's Encrypt.

  • Deaktiviere den integrierten Browser-OAuth-Vorgang, wenn deine App ihn nicht verwendet. Einige Desktop- und mobile native Apps authentifizieren Nutzer über den OAuth-Client-Vorgang in einer integrierten Web-Ansicht. Wenn deine App diesen Vorgang nicht verwendet, deaktiviere die Einstellung unter „Produkte“ > „Facebook Login“ > „Einstellungen“ im App-Dashboard.

  • Deaktiviere mobile SSO-Vorgänge, wenn deine App sie nicht verwendet. Wenn deine App weder iOS noch Android Login verwendet, deaktiviere die Einstellung „Single Sign On“ in den iOS- und Android-Bereichen unter Einstellungen > Grundeinstellungen.

Im App-Dashboard findest du eine Reihe weiterer Einstellungen, mit denen Entwickler Angriffspfade „dichtmachen“ können, die anderweitig zu Sicherheitslücken führen würden:

  • Allgemeines > App-Geheimcode: Wenn dein App-Geheimcode kompromittiert sein sollte, kannst du ihn hier zurücksetzen.
  • Allgemeines > App Domains: Damit kannst du Domains und Sub-Domains sperren, mit denen Facebook Login im Namen deiner App durchgeführt werden kann.
  • Erweitert > App-Typ: Wenn du eine native App für Mobilgeräte oder Desktops entwickelst und den App-Geheimcode darin speicherst, lege bei dieser Einstellung Native/Desktop fest, damit deine App nicht dekompiliert und dein App-Geheimcode nicht gestohlen werden kann.
  • Erweitert > Server-IP-Positivliste: Hiermit gibst du eine Liste von IP-Adressen an, über die Graph-API-Aufrufe mit deinem App-Geheimcode gestartet werden können. Alle Graph-API-Aufrufe mit deinem App-Geheimcode, die außerhalb dieses Bereichs gestartet werden, schlagen fehl. Aufrufe über Nutzer-Zugriffsschlüssel sind von dieser Einstellung nicht betroffen.
  • Erweitert > IP-Positivliste der Einstellungen aktualisieren: Damit begrenzt du IP-Adressen, über die ein Nutzer die App-Einstellungen verändern kann, auf einen bestimmten Bereich. Sei beim Festlegen einer IP-Positivliste auf einem Breitband für Privatkunden vorsichtig. Wenn sich deine IP-Adresse verändert, kannst du deine App-Einstellungen nicht mehr bearbeiten.
  • Erweitert > Update-Benachrichtigung per E-Mail: Damit wird eine E-Mail-Adresse benachrichtigt, wenn eine App-Einstellung im App-Dashboard geändert wurde.
  • Erweitert > Stream-Post-URL-Sicherheit: Damit verhinderst du, dass URLs von deiner App gepostet werden, die nicht auf eine Domain zurückverweisen, die deiner App gehört. Dies muss nicht immer nützlich sein, vor allem, wenn du weißt, dass deine App Links zu anderen Seiten postet.