Vidéo

Vidéo tirée de la conférence F8 2015, dans laquelle Jonathan Gross et Brent Dorman étudient différents moyens de sécuriser davantage votre intégration de Facebook Login.

Liste de contrôle de sécurité

La liste de contrôle ci-dessous reprend les mesures de sécurité minimales que toute application utilisant Facebook Login doit mettre en œuvre. Votre application inclura également des fonctionnalités qui lui sont propres, vous devez donc constamment réfléchir à la meilleure façon de la sécuriser. Les utilisateurs d’une application non protégée risquent de ne plus avoir confiance en celle-ci et cesseront de l’utiliser.

Ne jamais inclure votre clé secrète dans un code côté client ou un code décompilable.

Signer tous les appels d’API Graph de serveur à serveur avec votre clé secrète.

Utiliser des tokens à court terme uniques sur les clients.

Ne pas partir du principe que les tokens d’accès utilisés par votre application ont été générés par cette dernière.

Utiliser le paramètre d’état lors de l’utilisation de la boîte de dialogue Login.

Utiliser, si possible, nos SDK officiels.

Réduire l’exposition de votre application aux attaques en verrouillant les paramètres de votre application Facebook.

Utiliser le protocole HTTPS.

Clé secrète

La clé secrète est utilisée dans certains processus de connexion afin de générer des tokens d’accès. Elle permet de protéger les utilisateurs de confiance lorsqu’ils utilisent votre application. La clé secrète permet de créer facilement un token d’accès d’application capable d’envoyer des requêtes d’API pour le compte de tout ou toute utilisateur ou utilisatrice de l’application. Par conséquent, il est essentiel que la clé secrète ne soit pas compromise.

C’est la raison pour laquelle il ne faut jamais inclure la clé secrète ou un token d’accès d’application à quelque code que ce soit.

Pour une sécurité optimale, nous vous conseillons d’utiliser uniquement les tokens d’accès d’application directement à partir des serveurs de votre application. Pour les apps natives, nous suggérons que l’app communique avec votre propre serveur, et que celui-ci envoie ensuite les requêtes d’API à Facebook à l’aide du token d’accès de l’app. Ainsi, si le type d’application indiqué sous Paramètres avancés dans l’Espace App est défini sur Native/Desktop, nous partons du principe que votre application native contient la clé secrète ou un token d’accès d’application dans le fichier binaire, et nous n’autorisons aucun appel signé avec un token d’accès d’application. L’API se comportera comme si aucun token d’accès n’avait été fourni.

Sécurisation des appels côté serveur avec appsecret_proof

Vous pouvez demander à ce que les appels de serveur à serveur vers l’API de Facebook soient signés avec le paramètre appsecret_proof afin de réduire l’exposition de votre application aux attaques de logiciels malveillants et de spammeurs. La preuve de clé secrète est un hachage sha256 de votre token d’accès qui utilise la clé secrète comme clé. La clé secrète est disponible dans le tableau de bord de votre application sous Paramètres > Paramètres de base.

Générer la preuve

L’exemple de code suivant illustre un appel en langage PHP :

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

Certains systèmes d’exploitation et langages de programmation renvoient un horodatage correspondant à un nombre flottant. Veillez à convertir cette valeur en nombre entier avant de calculer la preuve de clé secrète. Certains langages de programmation créent le hachage sous la forme d’un objet condensé. Prenez soin d’exprimer le hachage en tant qu’objet hexadécimal.

Ajouter la preuve

Ajoutez le résultat sous forme de paramètre appsecret_proof avec appsecret_time défini sur l’horodatage utilisé lors du hachage de la clé secrète pour chaque appel effectué :

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

Les preuves de clé secrète horodatées sont considérées comme expirées au bout de 5 minutes. Nous vous recommandons donc de générer une nouvelle preuve en ligne pour chaque appel de l’API Graph.

Demander la preuve

Dans la section Paramètres > Paramètres avancés du tableau de bord de votre application, sous Sécurité, activez Demander la clé secrète. Lorsque cette option est activée, nous n’autorisons que les appels d’API comprenant le paramètre appsecret_proof.

Sécurisation des appels côté client avec des tokens à court terme et un flux de code

Dans certaines configurations, les apps réutilisent un token à long terme sur plusieurs serveurs clients. Ne procédez pas de la sorte. Utilisez plutôt des tokens à court terme générés avec le flux de code, comme expliqué dans notre documentation sur les tokens d’accès.

Détournement de tokens

Pour mieux comprendre ce cas de figure, prenons l’exemple suivant : une app iOS native souhaite passer des appels d’API et, plutôt que de le faire directement, communique avec un serveur qui lui appartient pour lui transmettre un token généré à l’aide du SDK iOS. Le serveur utilise alors le token pour passer des appels d’API.

Le point de terminaison utilisé par le serveur pour recevoir le token peut être compromis, et d’autres personnes pourraient lui transmettre des tokens d’accès pour des applications totalement différentes. Il va de soi qu’il s’agit d’une faille de sécurité majeure, mais il existe un moyen de se protéger contre une telle éventualité : il ne faut jamais supposer que les tokens d’accès ont été générés par l’application qui les utilise. Ils doivent toujours faire l’objet d’une vérification à l’aide de points de terminaison de débogage.

Vérification régulière de la validité du token d’accès

Si vous n’utilisez pas les SDK Facebook, vérifiez régulièrement si le token d’accès est valide. Bien qu’ils aient une date d’expiration programmée, les tokens d’accès peuvent expirer plus tôt pour des raisons de sécurité. Si vous n’utilisez pas les SDK Facebook dans votre application, il est extrêmement important que vous mettiez en œuvre manuellement des contrôles fréquents de la validité des tokens (au moins quotidiennement) pour vous assurer que votre application ne dépend pas d’un token qui a expiré plus tôt pour des raisons de sécurité.

Paramètre d’état

Si vous utilisez la boîte de dialogue Login de Facebook sur votre site web, le paramètre state est une chaîne unique qui protège votre application contre les attaques de type Falsification de requête intersite.

Activation du mode Strict

Le mode Strict protège vos applications en empêchant les personnes malveillantes de détourner votre redirection. L’activation du mode Strict est obligatoire pour toutes les applications.

Avant d’activer le mode Strict dans l’Espace App, vérifiez que votre trafic de redirection actuel fonctionne en effectuant les actions suivantes dans les paramètres Facebook Login :

  • Pour les applications avec des URI de redirection dynamique, utilisez le paramètre d’état pour renvoyer les informations dynamiques à un nombre limité d’URI de redirection. Ajoutez ensuite chacun des URI de redirection limité à la liste des URI de redirection OAuth valides.

  • Pour les applications avec un nombre limité d’URI de redirection, ajoutez chacun d’eux à la liste des URI de redirection OAuth valides.

  • Pour les applications qui utilisent uniquement le SDK JavaScript de Facebook, le trafic de redirection est déjà protégé. Aucune action supplémentaire n’est nécessaire.

Après avoir effectué ces actions, activez le mode Strict.

Fonctionnement du mode Strict

Le mode Strict empêche le détournement de vos URI de redirection en exigeant une correspondance exacte depuis votre liste des URI de redirection OAuth valides. Par exemple, si votre liste contient www.example.com, le mode Strict n’autorisera pas www.example.com/token comme redirection valide. Il n’autorisera pas non plus tout paramètre de requête supplémentaire ne figurant pas dans votre liste des URI de redirection OAuth valides.

Utilisation du protocole HTTPS

Utilisez le protocole Internet HTTPS plutôt que le protocole HTTP, car il utilise le chiffrement. Le protocole HTTPS assure donc la confidentialité des données transmises et les protège contre les attaques malveillantes. Il empêche également que les données soient modifiées pendant la transmission par l’insertion, par exemple, de publicités ou d’un code malveillant.

À partir du 6 octobre 2018, toutes les applications devront utiliser le protocole HTTPS.

Activation du SDK JavaScript pour Facebook Login

Lorsque vous indiquez que vous utilisez le SDK JavaScript pour vous connecter en configurant l’option de connexion avec le SDK JavaScript sur « oui », le domaine de votre page qui héberge le SDK doit correspondre à l’une des entrées de la liste Domaines autorisés pour le SDK Javascript. Cela garantit que les tokens d’accès sont uniquement renvoyés aux rappels dans les domaines autorisés. Seules les pages HTTPS sont prises en charge pour les actions d’authentification avec le SDK JavaScript de Facebook.

Pour les intégrations JSSDK existantes créées avant le 10 août 2021, cette liste est remplie avec des valeurs basées sur l’utilisation actuelle. Aucune autre action n’est requise.

Pour les nouvelles intégrations créées après le 10 août 2021, vous devez ajouter des valeurs à cette liste.

Si vous voyez que le champ du domaine JSSDK de votre application contient des URL qui commencent par *., veuillez modifier ce contenu de façon à le remplacer par des URL absolues pour plus de sécurité.

Fonctionnement de la vérification des URI de redirection

Les attaques de redirection ouvertes surviennent lorsqu’une personne malveillante fournit un paramètre redirect_uri non autorisé lors de la demande de connexion, entraînant la fuite éventuelle d’informations sensibles telles qu’un token d’accès vers la chaîne ou le fragment de requête dans l’URI de redirection.

Pour les intégrations web personnalisées, vous devez fournir des URI de redirection autorisés dans les paramètres de votre application pour empêcher de telles attaques. Pour répondre à une demande de connexion, le paramètre redirect_uri sera comparé aux entrées de cette liste. L’URI complet doit être identique, y compris tous les paramètres, à l’exception du paramètre d’état facultatif, dont la valeur est ignorée.

Navigateurs dans l’app et SDK JavaScript

Le SDK JavaScript repose généralement sur des pop-ups et des rappels pour effectuer une connexion. Pour certains navigateurs dans l’app qui suppriment les pop-ups, cela peut échouer. Si tel est le cas, le SDK tentera automatiquement de procéder à une redirection, avec un token d’accès, vers la page qui l’a invoqué. Il peut uniquement procéder à une redirection en toute sécurité si l’URI complet de la page est répertorié dans la liste des URI de redirection OAuth valides.

Si les scénarios de navigateur dans l’app sont importants pour votre application web, vous devez ajouter le domaine de votre page de connexion aux domaines autorisés, ainsi que son URI complet (y compris le chemin et les paramètres de requête), aux URI de redirection OAuth valides. Si les URI varient beaucoup lors de la connexion à votre application, vous pouvez spécifier manuellement une option fallback_redirect_uri dans l’appel FB.login(), de sorte que vous aurez simplement besoin d’ajouter cette entrée à votre liste d’URI de redirection OAuth valides.

Verrouillage des paramètres de votre application Facebook

Activez et/ou désactivez tout processus d’authentification non utilisé par l’application pour réduire l’exposition à des attaques.

  • Utilisez des tokens d’accès à court terme générés par un code dans les clients plutôt que des tokens générés par les clients ou des tokens à long terme fournis par un serveur. Le processus associé aux tokens d’accès à court terme générés par un code requiert que l’application échange le code contre un token, et ce processus est plus sûr que l’obtention d’un token dans le navigateur. Les applications doivent privilégier ce processus autant que possible pour une sécurité optimale. La seule activation de ce processus par une application permet d’empêcher un logiciel malveillant présent sur l’ordinateur d’un·e utilisateur·trice d’obtenir un token d’accès et de l’utiliser à des fins malhonnêtes. Pour en savoir plus, consultez notre documentation sur les tokens d’accès.

  • Désactivez le processus de connexion OAuth côté client si votre application ne l’utilise pas. Le processus de connexion OAuth côté client est un bouton permettant d’activer ou de désactiver l’utilisation des flux de tokens client OAuth. Si votre application n’utilise aucun processus OAuth côté client, ce qui est le cas des SDK associés au Facebook Login, vous devez désactiver ce processus. Notez, cependant, que vous ne pouvez pas demander d’autorisations pour un token d’accès si votre processus de connexion OAuth côté client est désactivé. Ce paramètre se trouve dans la section Produits > Facebook Login > Paramètres de l’Espace App.

  • Désactivez le processus OAuth sur le web ou spécifiez une liste de redirections autorisées. Les paramètres de la connexion OAuth sur le web permettent à tout processus OAuth associé à un token client et utilisant la boîte de dialogue Login sur le web de Facebook de renvoyer des tokens vers votre propre site web. Ce paramètre se trouve dans la section Produits > Facebook Login > Paramètres de l’Espace App. Désactivez ce paramètre si vous ne créez pas de processus de connexion sur le web personnalisé ni n’utilisez le SDK Facebook Login sur le web.

  • Appliquez le protocole HTTPS. Ce paramètre doit utiliser HTTPS pour toutes les redirections OAuth et exige que tous les appels SDK Facebook pour Javascript de renvoyant ou exigeant un token d’accès se fassent uniquement depuis des pages HTTPS. Toutes les nouvelles applications créées à partir de mars 2018 ont ce paramètre activé par défaut. Nous vous conseillons de prévoir une migration des applications existantes pour n’utiliser que des URL HTTPS d’ici le 6 octobre 2018. La plupart des grands hébergeurs d’applications sur le cloud proposent une configuration automatique et gratuite des certificats TLS pour vos applications. Si vous hébergez vous-même votre application ou que votre service d’hébergement n’offre pas le protocole HTTPS par défaut, vous pouvez obtenir un certificat gratuit pour vos domaines sur Let’s Encrypt.

  • Désactivez le processus OAuth intégré dans un navigateur si votre application ne l’utilise pas. Certaines applications natives sur ordinateur ou mobile authentifient les utilisateurs par l’intermédiaire du processus OAuth côté client au sein d’un webview intégré. Si votre application n’utilise pas cette méthode d’authentification, désactivez-la dans la section Produits > Facebook Login > Paramètres de l’Espace App.

  • Désactivez les processus d’authentification unique pour mobile si votre application ne les utilise pas. Si votre application n’utilise pas la Connexion iOS ou Android, désactivez le paramètre Authentification unique dans les sections Paramètres > Paramètres de base sur iOS et Android.

L’Espace App contient plusieurs paramètres supplémentaires qui permettent aux développeur·euses de contrer les attaques qui pourraient nuire à la sécurité :

  • Paramètres de base > Clé secrète : si la clé secrète de votre application est compromise, vous pouvez la réinitialiser à cet endroit.
  • Paramètres de base > Domaines de l’app : utilisez ce paramètre pour verrouiller les domaines et sous-domaines pouvant être utilisés pour exécuter Facebook Login au nom de votre application.
  • Avancé > Type d’app : lorsque vous créez une application native pour ordinateur de bureau ou mobile et y incluez la clé secrète, réglez ce paramètre sur Native/Desktop pour éviter tout risque de décompilation de votre application ou de vol de votre clé secrète.
  • Avancé > IP serveur autorisées : ce paramètre spécifie une liste d’adresses IP à partir desquelles des appels d’API Graph peuvent être effectués à l’aide de votre clé secrète. Toute tentative d’appel d’API Graph à l’aide de votre clé secrète effectuée depuis une adresse qui ne fait partie de cette liste échouera. Les appels passés avec les tokens d’accès des utilisateurs ne sont pas affectés par ce paramètre.
  • Avancé > Liste d’IP autorisées pour les modifications de paramètres : ce paramètre limite à une plage spécifique les adresses IP à partir desquelles une personne peut modifier ces paramètres d’application. Assurez-vous de définir votre liste d’IP autorisées sur un réseau résidentiel haut débit. En cas de changement de votre adresse IP, vous ne pourrez plus modifier les paramètres de votre app.
  • Avancé > Mettre à jour l’e-mail de notification : ce paramètre permet d’envoyer une notification à une adresse e-mail à chaque modification d’un paramètre d’application dans l’Espace App.
  • Avancé > Sécurité du flux de publication des URL : ce paramètre permet d’empêcher votre application de publier une URL qui ne renvoie pas vers un domaine qu’elle possède. Ce paramètre n’est pas toujours utile, en particulier si votre application publie des liens vers d’autres sites.