11
votes

Quels sont les risques de sécurité pour exposer le jeton d'accès à l'utilisateur de Facebook en JavaScript?

Supposons que mon application ait un jeton d'accès à un utilisateur de Facebook. Y a-t-il un risque de sécurité dans l'exposition de ce jeton d'accès au code JS à certains autres utilisateurs qui visitent mon site? Si oui, que peuvent-ils faire avec ça?


1 commentaires

Security.stackexchange.com pourrait également être un bon forum pour cette question.


4 Réponses :


9
votes

Un jeton d'accès Facebook donne les mêmes droits que votre application a à un utilisateur particulier à quiconque a accès au jeton. Donc, si votre application acquiert les droits de faire des actions A, B et C et reçoivent un jeton à cet effet, toute autre application qui serait en mesure d'obtenir le jeton aurait les mêmes droits à cet utilisateur (jusqu'à ce que le jeton expire ).

Donc, oui, il y a un risque. Vous devez protéger le jeton de l'accès à quiconque / tout ce qui ne devrait pas avoir les mêmes droits sur l'utilisateur Facebook que votre application.


3 commentaires

Mais l'utilisation du jeton d'accès est limitée au domaine de l'application. Il semble donc que d'autres applications ne puissent pas l'utiliser.


Votre application dispose d'un jeton d'accès pour Facebook, par votre exemple. Cela signifie qu'il a des droits de faire des actions A, B et C sur Facebook. Toute personne qui attrape que le jeton a maintenant le même droit de faire des actions A, B et C sur Facebook en tant qu'utilisateur en question. Le domaine d'application empêche d'autres applications d'accepter le jeton, mais Facebook l'acceptera de manière heureuse, quel que soit leur soumission. C'est pourquoi les jetons OAuth doivent être protégés et être de courte durée. Le projet Internet IETF sur OAuth 2.0 Les jetons au porteur devraient expliquer cela en détail: Self-Riquued.info/docs/draft-ietf-oauth-v2-beer.html


j'ai compris. Pourtant, j'utilise une application pour mon propre but et aucun autre utilisateur n'est impliqué. Je voulais lire des commentaires postés pour mon article en utilisant Cron. J'ai donc créé un jeton d'accès de longue durée qui est à cette date est de 60 jours de long. Je suis sûr qu'il est utilisé dans le script de serveur. Je vais devoir le stocker dans un fichier dB ou plat. La permission que j'ai définie à c'était juste hors ligne .access. Si ce jeton d'accès a eu du public, ce que sont toutes les actions possibles sur ce jeton d'accès? En d'autres termes, comment puis-je limiter cela pour ne lire que des commentaires et non d'autre opération? J'espère que j'avais rendu clairement?



14
votes

vous êtes à risque de

  1. Adjoint confus - Votre code attribue des privilèges au code qui pourrait abuser intentionnellement de ces privilèges intentionnellement ou en agissant au nom de pourtant plus de code qui est malveillant.
  2. Vol via Injection de code (XSS) - Les informations d'identification pourraient être volées par code injecté Votre page via une vulnérabilité XSS puis utilisé pour agir au nom de l'utilisateur, générer éventuellement des journaux qui vous incitent comme un coupable.
  3. Vol de VIA via EaveDropping - S'il existe une teneur non-HTTPS qui traverse la connexion entre le navigateur et votre serveur, une écoute d'écoute avec la possibilité de lire les paquets pourrait voler les informations d'identification.
  4. Vol de malware - S'il y a des logiciels malveillants exécutés sur l'ordinateur de l'utilisateur, envoyez ensuite ces informations d'identification au navigateur les expose à ce logiciel malveillant. Les logiciels malveillants devraient probablement lire la mémoire appartenant au processus de navigateur ou au cache écrit par le navigateur.

5 commentaires

Le jeton d'accès n'est-il pas limité au domaine?


Environ # 4 ... S'il y a des logiciels malveillants, l'utilisateur est déjà en difficulté et l'envoi de jeton d'accès ne devrait pas créer un autre niveau de défaut de sécurité, non? Parce que si les logiciels malveillants peuvent contrôler et accéder au navigateur, il peut simplement aller sur le site et lire du contenu privé.


@Muhammadumer, non. Si un site envoie des informations d'identification C à un navigateur exécutant sur cette machine en réponse à une connexion à l'aide des informations d'identification D, un logiciel malveillant sur cette machine a accès aux informations d'identification C et D. mais si ce site n'envoie pas C au navigateur, le La machine n'a accès qu'à des informations d'identification D. La différence est que la différence est que d combiné avec des jetons XSRF de courte durée pourraient impliquer C en interne, mais si c est envoyé, les logiciels malveillants ont maintenant une fenêtre large pour abuser de C.


Je comprends cela crée une autre porte .. Mais tout le mur est manquant. C est court vécu et limité (porte) et si D est déjà comprometté le mur, le mot de passe et le nom d'utilisateur, il y a un problème plus important. Mais je suppose que c'est une invulnérabilité, mais je m'appuie un autre que vous pourriez vivre. Je pense que je ne sauvegarder pas le jeton d'accès dans le stockage local, mais simplement l'utiliser en le demandant, il pourrait être suffisant.


@Muhammadumer, ouais, les logiciels malveillants en cours d'exécution sur une machine peuvent faire beaucoup de choses donc parfois ces distinctions sont sans importance. Les logiciels malveillants sur une machine ne peuvent pas tout faire. Il est beaucoup plus facile d'écrire des logiciels malveillants pour gratter les informations du système de fichiers et plus difficile à l'obtenir à partir d'un résident de processus en mémoire, il est donc important d'empêcher les informations d'identification de se retrouver dans des fichiers de cache (et, à mesure que vous parlez de stockage local) où les logiciels malveillants seulement a besoin d'accès au système de fichiers.



3
votes

Ce jeton d'accès peut être utilisé n'importe où par quiconque pour faire tout ce que le jeton d'accès a des autorisations à faire. Qui est ce qui le rend puissant, non?

Ainsi, exposant l'Access_Token en JavaScript dépend vraiment de l'endroit où JavaScript est exécuté et sur quel type de réseau qui accède à un jeton est envoyé.

Si les choses sont sur https, vous ne devriez pas avoir de soucis si le périphérique que le javascript est exécuté est en sécurité (disons un navigateur de téléphone cellulaire personnel avec une serrure d'écran).

Si l'appareil est indiqué à un terminal Internet communément partagé, même avec HTTPS, où tout le monde utilise le même compte d'utilisateur, alors si un escroc a serré à travers des fichiers d'historique sur le navigateur et retirez-le que le jeton d'accès. Mauvais mauvais mauvais.

Si vous communiquez sur http, il est grand ouvert sur le monde entier à voir. Mauvais mauvais mauvais.

Donc, depuis que vous n'avez aucune de ces informations sur ce que l'environnement est, ce sont des questions assez vagues. Donc, mon résultat ne sera pas si vague. ne le faites pas! Laissez simplement le SDK JavaScript de Facebook pour vous.


0 commentaires

2
votes

La divulgation de jeton de sécurité peut rendre vos utilisateurs vulnérables à obtenir HACK

Je me souviens d'un logiciel "FacEniff" qui fonctionne sur un téléphone Android enraciné, il renifle un jeton de sécurité de Facebook et d'autres sites Web et vous pouvez vous connecter à tout compte de l'utilisateur qui est connecté à ce wifi.

Il y avait une faille de sécurité dans un autre logiciel Android qui permet à des pirates informatiques renifler votre jeton de sécurité Calendrier Gmail et peut accéder pleinement.

Lire ce message http: //www.techlicious.com/blog/andrroid-security-Flaw-Could-expose-YOU-TO-DATA-TEFT/


0 commentaires