Pourquoi avons-nous besoin de la sécurité du service REST si nous avons HTTPS

13

Je me réfère à cet excellent article http://www.thebuzzmedia.com/designing-a-secure-rest-api-without-oauth-authentication/ qui parle d'Amazon comme la sécurité pour le service Web. Cependant, on m'a posé une question dans l'équipe: pourquoi en avons-nous besoin si nous utilisons déjà HTTPS. Je n'ai pas pu répondre car il me semble qu'ils ont peut-être raison, même si mon instinct me dit le contraire.

Y a-t-il également des endroits lors de la fourniture de services REST où HTTPS peut ne pas fonctionner? Vous aimez les sites Web tiers?

Si quelqu'un a de l'expérience dans la sécurisation de services Web sur les interwebs publics, veuillez faire la lumière sur votre expérience.

Merci d'avance.

EDIT: Pour clarifier, je ne parle pas d'authentification d'utilisateur mais plus d'authentification client. L'authentification de l'utilisateur peut être supposée être du texte brut sur HTTPS + REST.

Mon inquiétude est que cela permet toujours à n'importe qui d'utiliser le service Web sans que mon client y accède, car tout est en texte plat, bien que sur HTTPS le point de terminaison client puisse toujours utiliser mon service Web sans l'application client.

rest

— Abhishek Dujari
source

3

Le mieux adapté pour security.stackexchange.com ?

— jweyrich

1

vous avez peut-être raison, mais ma question est davantage liée.

13

Pourquoi devons-nous donner à Gmail - ou à tout autre site avec des comptes d'utilisateurs - notre nom d'utilisateur et notre mot de passe s'il utilise déjà HTTPS? La réponse est la même que la réponse à votre question.

HTTPS fournit, avant tout, une connexion cryptée entre le serveur et le client.

La confiance inhérente à HTTPS est basée sur les principales autorités de certification préinstallées dans les logiciels de navigation (cela revient à dire "Je fais confiance à l'autorité de certification (par exemple VeriSign / Microsoft / etc.) Pour me dire à qui je dois faire confiance").

À moins que le serveur ne donne à chaque utilisateur un certificat , le serveur ne peut pas faire confiance au client sans une autre méthode d'authentification.

— Matt Ball
source

désolé vous vous méprenez ou je n'ai pas été clair. Les documents Amazon APi indiquent que nous devons utiliser HTTPS mais si nous ne le faisons PAS, nous signons la demande. Le mot de passe du nom d'utilisateur n'est pas pertinent à ce stade.

3

À un niveau élevé, vous devez prouver votre identité au serveur pour qu'il accepte les commandes de votre part. L'authentification du client peut être effectuée via HTTPS, et elle peut également être effectuée à l'aide de la signature de message.

— Matt Ball

1

Si vous souhaitez utiliser HTTPS pour l'authentification client, vous devez émettre à chaque utilisateur un certificat de clé publique, comme décrit dans le dernier lien de ma réponse. Considérez ces certificats comme la version électronique d'un passeport.

— Matt Ball

1

Vous liez pour "donner à chaque utilisateur un certificat" kidn de réponses à ma question. Je suppose que toute la clé publique privée et la signature sont toujours nécessaires pour sécuriser correctement les deux extrémités d'un service Web, donc un SSL sur le serveur ne suffit pas. Votre réponse est la plus proche jusqu'à présent. Merci beaucoup.

— Abhishek Dujari

1

+1 C'est génial que vous mentionniez les certificats clients, mais il n'est pas nécessaire que le serveur émette les certificats. Ils doivent simplement être signés par une autorité de certification de confiance; essentiellement la même chose que le fonctionnement des certificats serveur.

— JimmyJames

3

HTTPS est très efficace pour prévenir les écoutes et les attaques de type "homme au milieu". Comme il crypte tout le trafic pour une session.

Mais comme la plupart des gens utilisent les certificats par défaut fournis avec leur navigateur et ne savent pas comment créer leur propre certificat personnel ou configurer le navigateur pour l'utiliser.

Cela rend HTTPS assez inutile pour l'authentification des utilisateurs autre que la protection d'une boîte de dialogue d'authentification contre l'écoute, etc.

— James Anderson
source

Je pense que vous êtes très proche de ce que je demande. Vous proposez donc que nous devrions toujours signer la demande côté client même si nous utilisons HTTPS?

2

HTTPS consiste à sécuriser le canal, pas à prouver qui est l'appelant ou les nombreuses autres choses dont vous devez tenir compte. L'authentification, l'autorisation et le chiffrement de la couche de transport ne sont qu'une petite partie de ce que vous devez considérer. De nombreuses vulnérabilités connues liées aux applications Web s'appliquent beaucoup aux API REST. Vous devez prendre en compte la validation des entrées, le craquage de session, les messages d'erreur inappropriés, les vulnérabilités internes des employés, etc. C'est un gros sujet.

Robert

— Robert Morschel
source

0

Vous pouvez adopter l'approche des certificats SSL client et séparer la sécurité de l'API. Le gros inconvénient de cette approche est le surcoût de l'opération qui deviendra coûteux car de plus en plus de clients consomment votre API.

Quoi qu'il en soit, l'authentification de base HTTP convient parfaitement à la grande majorité des services publics.

— CodeToGlory
source