Dank Funktionen von Facebook Login wie Zugriffsschlüssel und Berechtigungen sind Nutzer sowie Apps geschützt. Trotzdem müssen Apps einige Sicherheitsfunktionen selbst implementieren.
Jonathan Gross und Brent Dorman informieren über Möglichkeiten, die Sicherheit deiner Facebook Login-Integration zu verbessern (F8 2015).
In der unten stehenden Liste findest du alle Funktionen, die eine App, die Facebook Login verwendet, mindestens implementieren sollte. Andere Funktionen richten sich nach deiner speziellen App. Du solltest aber 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.
Der App-Geheimcode kommt bei einigen Anmeldevorgängen zum Einsatz, um Zugriffsschlüssel zu erstellen. Der App-Geheimcode soll dafür sorgen, dass nur diejenigen Nutzer Zugriff auf deine App erhalten, denen du vertraust. Du kannst damit ganz einfach einen App-Zugriffsschlüssel erstellen, der API-Anfragen im Namen eines Nutzers deiner App durchführt. Deshalb darf der App-Geheimcode unter keinen Umständen kompromittiert werden.
Du solltest den App-Geheimcode oder einen App-Zugriffsschlüssel niemals in Code implementieren, auf den eine andere Person als ein Entwickler der App zugreifen kann. Dies gilt für alle Code-Methoden, die nicht gesichert sind, wie clientseitiger Code (z. B. HTML oder JavaScript) oder native Apps (z. B. iOS-, Android- oder Windows-Desktop-Apps), die dekompiliert werden könnten.
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-Art“ 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.
Wenn dein App-Geheimcode kompromittiert wurde, solltest du ihn unverzüglich in den Grundeinstellungen deines App-Dashboards zurücksetzen. Wenn du den Prozess zum Zurücksetzen durchführst, kannst du angeben, wie lange der kompromittierte Geheimcode noch zum Durchführen von Anfragen verwendet werden soll. Alle Übermittlungen von Facebook (z. B. signierte Anfragen) verwenden jedoch gleich den neuen Geheimcode, weshalb du deinen Code entsprechend anpassen musst, damit er akzeptiert wird.
appsecret_proofDu kannst Übergriffe durch Malware und Spammer vermeiden, wenn die Server-zu-Server-Aufrufe an die API von Facebook mit dem appsecret_proof-Parameter signiert werden müssen. Genauere Informationen zu diesem Thema findest du in der Dokumentation Sichern von Graph API-Aufrufen.
In manchen Konfigurationen verwenden Apps denselben langlebigen Schlüssel für verschiedene Clients. Das ist keine gute Idee. Verwende stattdessen kurzlebige Schlüssel, die mit dem Codevorgang erstellt werden. Eine Beschreibung dazu findest du in der Dokumentation zu Zugriffsschlüsseln.
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.
Falls du nicht mit den Facebook-SDKs arbeitest, musst du regelmäßig die Gültigkeit des Zugriffsschlüssels überprüfen. Auch wenn es für Zugriffsschlüssel geplante Ablaufdaten gibt, können Schlüssel aus Sicherheitsgründen vorzeitig ablaufen. Falls du in deiner App keine Facebook-SDKs verwendest, ist es besonders wichtig, manuell häufige Überprüfungen der Gültigkeit der Schlüssel einzuplanen (mindestens täglich), um sicherzustellen, dass für deine App kein Schlüssel angegeben wurde, der aus Sicherheitsgründen vorzeitig abgelaufen ist.
Wenn du den Facebook-Login-Dialog auf deiner Webseite verwendest, solltest du den state-Parameter nutzen. Mit diesem eindeutigen String-Parameter sicherst du deine App gegen Cross-Site-Request-Forgery-Angriffe ab.
Der Strict-Modus schützt Apps, indem er verhindert, dass Angreifer deine Umleitung 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 Umleitungs-Traffic weiterhin funktioniert. Nimm dazu die folgenden Handlungen in den Facebook Login-Einstellungen vor:
Verwende bei Apps mit dynamischen Umleitungs-URIs den state-Parameter, um die dynamischen Informationen an eine begrenzte Anzahl von Umleitungs-URIs zu übergeben. Füge dann die einzelnen Umleitungs-URIs zur Liste „Gültige OAuth Redirect URIs“ hinzu.
Füge bei Apps mit einer begrenzten Anzahl von Umleitungs-URIs die einzelnen Umleitungs-URIs zur Liste „Gültige OAuth Redirect URIs“ hinzu.
Aktiviere den Strict-Modus, nachdem du diese Maßnahmen vorgenommen hast.
Der Strict-Modus schützt davor, dass Angreifer deine Umleitung missbrauchen, da eine genaue Übereinstimmung mit deiner Liste „Gültige OAuth Redirect URIs“ erforderlich ist. Wenn deine Liste für „Gültige OAuth Redirect URIs“ beispielsweise www.beispiel.com enthält, lässt der Strict-Modus www.example.com/token nicht als gültige Umleitung zu. Er lässt außerdem keine zusätzlichen Abfrageparameter zu, die nicht in der Liste „Gültige OAuth Redirect URIs“ enthalten sind.
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 bösartigen Code.
Ab dem 6. Oktober 2018 ist für alle Apps HTTPS obligatorisch.
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 Schlüsseln oder vom Server bereitgestellten langlebigen Schlüsseln. Mit dem Code-generierten kurzlebigen Zugriffsschlüsselvorgang muss der App-Server den Code gegen einen Schlüssel eintauschen, was sicherer ist, als einen Schlüssel über den Browser zu erhalten. Apps sollten diesen Vorgang, wenn möglich, bevorzugen, um besseren Schutz zu bieten. Wenn eine App nur diesen Vorgang aktiviert hat, kann Malware, die auf Computern von Nutzern ausgeführt wird, 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 Umleitungs-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.
Erzwinge HTTPS. Diese Einstellung erfordert HTTPS für OAuth-Umleitungen und alle Facebook JavaScript-SDK-Aufrufe, die einen Zugriffsschlüssel zurückgeben oder erfordern, müssen ausschließlich von HTTPS-Seiten 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 großen Hosts von Cloudanwendungen bieten die kostenlose und automatische Konfiguration von TLS-Zertifikaten für deine Anwendungen. 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:
Native/Desktop fest, damit deine App nicht dekompiliert und dein App-Geheimcode nicht gestohlen werden kann.