Est-il sûr de transmettre des jetons d'accès via des en-têtes HTTP?

Il s'agit du premier service Web RESTful et je suis préoccupé par les problèmes de sécurité. Est-il sûr de transmettre mon jeton d'accès via des en-têtes HTTP? Par exemple:

POST /v1/i/resource HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Api-key: 5cac3297f0d9f46e1gh3k83881ba0980215cd71e
Access_token: 080ab6bd49b138594ac9647dc929122adfb983c8

parameter1=foo&parameter2=bar

La connexion s'est établie SSL. En outre, ce qui doit être défini comme scopeattribut pour chaqueaccess token

— ahmedsaber111
source

Réponses:

Si vous deviez transmettre l'en-tête du jeton d'accès via HTTP, il serait vulnérable à l'attaque de l'homme du milieu.

Lorsque vous transmettez l'en-tête du jeton d'accès via HTTPS, personne à part le client ne pourra voir ce jeton car la demande sera tunnelisée via une connexion sécurisée.

— CodeART
source

Un client bâclé peut être vulnérable aux attaques MITM même avec SSL.

— ott--

Pouvez-vous fournir un exemple s'il vous plaît?

— CodeART

Vous ne pouvez pas garantir la sécurité côté client si vous ne contrôlez pas le client, mais c'est vrai pour à peu près n'importe quoi.

— Matt

@CodeWorks La plupart des navigateurs offrent à l'utilisateur la possibilité de se connecter à une ressource HTTPS même si le certificat SSL est incorrect pour la ressource. C'est sans doute l'une des choses les plus stupides que les auteurs de navigateurs aient jamais faites, et elle propose essentiellement d'accepter les attaques MITM.

— Ross Patterson

@Dan, alors ce certificat MITM spécifique doit être ajouté à la liste des certificats racine des clients. Sinon, vous avez réduit l'avertissement HTTPS à un "loup pleureur" littéral que les deux A) entraînent vos utilisateurs à l'ignorer pour toujours, B) est difficile (impossible à cause de A) à distinguer d'une véritable attaque MITM malveillante.

— Nick T

Le transfert de jeton d'accès sur les en-têtes HTTP ne pose aucun problème grave, car les données transférées sont chiffrées lorsque SSL est utilisé, ce qui signifie qu'elles ne peuvent être comprises que par un client particulier qui a fait cette demande et le serveur qui répond à la demande, entre les deux, il n'y a aucune chance de comprendre les données par un tiers.

Une autre chose est access tokenbasée sur le temps afin qu'ils aient une vie pendant une période spécifique afin qu'ils n'aient aucune chance d'être utilisés à l'avenir.

— Ashwin
source

-1

Une chose à considérer est également la mise en cache.

Votre backend pourrait voir plusieurs appels vers la même URL, avec les mêmes paramètres GET / POST mais un jeton d'accès d'en-tête différent et considérer que le contenu peut être mis en cache et se divise vers n'importe quel corps.

— Thomas Decaux
source