Share
Dans ce dernier chapitre, nous examinerons les aspects de sécurité de HTTP, notamment l'identification des utilisateurs, le fonctionnement de l'authentification HTTP et les raisons pour lesquelles certains scénarios nécessitent le protocole HTTPS (HTTP sécurisé). En cours de route, nous allons également apprendre un peu plus sur la gestion de l'état avec HTTP..
HTTP est un protocole sans état, ce qui signifie que chaque transaction demande-réponse est indépendante de toute transaction précédente ou future. Rien dans le protocole HTTP n'oblige un serveur à conserver des informations sur une requête HTTP. Tout ce que le serveur doit faire est de générer une réponse pour chaque demande. Chaque demande contiendra toutes les informations dont un serveur a besoin pour créer la réponse..
La nature sans état de HTTP est l’un des facteurs déterminants du succès du Web. Les services en couches que nous avons examinés au chapitre précédent, des services tels que la mise en cache, sont tous rendus possibles (ou au moins plus faciles), car chaque message contient toutes les informations nécessaires à son traitement. Les serveurs proxy et les serveurs Web peuvent inspecter, transformer et mettre en cache des messages. Sans la mise en cache, le Web ne pourrait pas s'adapter à la demande d'Internet..
Cependant, la plupart des applications et des services Web que nous construisons au-dessus de HTTP sont extrêmement dynamiques..
Une application bancaire voudra qu'un utilisateur se connecte avant de lui permettre de visualiser les ressources liées à son compte. Lorsque chaque demande sans état arrive pour une ressource privée, l'application veut s'assurer que l'utilisateur a déjà été authentifié. Un autre exemple est lorsque l'utilisateur veut ouvrir un compte et remplir des formulaires dans un assistant de trois pages. L’application voudra s’assurer que la première page de l’assistant est complète avant de permettre à l’utilisateur de soumettre la deuxième page..
Heureusement, il existe de nombreuses options pour stocker l’état dans une application Web. Une approche consiste à incorporer l'état dans les ressources transférées au client, de sorte que tout l'état requis par l'application sera renvoyé à la demande suivante. Cette approche nécessite généralement des champs de saisie masqués et fonctionne mieux pour les états de courte durée (comme l'état requis pour se déplacer dans un assistant de trois pages). L'intégration de l'état dans la ressource conserve tout l'état à l'intérieur des messages HTTP. Il s'agit donc d'une approche hautement évolutive, mais qui peut compliquer la programmation de l'application..
Une autre option consiste à stocker l'état sur le serveur (ou derrière le serveur). Cette option est requise pour un état qui doit durer longtemps. Supposons que l'utilisateur envoie un formulaire pour modifier son adresse électronique. L'adresse électronique doit toujours être associée à l'utilisateur pour que l'application puisse prendre la nouvelle adresse, la valider et la stocker dans une base de données, un fichier ou appeler un service Web pour permettre à une autre personne de s'enregistrer..
Pour le stockage côté serveur, de nombreux frameworks de développement Web tels que ASP.NET fournissent également un accès à une "session utilisateur". La session peut vivre en mémoire ou dans une base de données, mais un développeur peut stocker des informations dans la session et récupérer les informations à chaque demande ultérieure. Les données stockées dans une session sont étendues à un utilisateur individuel (en fait, à sa session de navigation) et ne sont pas partagées par plusieurs utilisateurs..
Le stockage de session a un modèle de programmation simple et ne convient que pour les états de courte durée, car le serveur doit finalement supposer que l'utilisateur a quitté le site ou fermé le navigateur et le serveur ignorera la session. Le stockage de session, s’il est stocké en mémoire, peut avoir un impact négatif sur l’évolutivité, car les demandes suivantes doivent aller au même serveur où se trouvent les données de la session. Certains équilibreurs de charge aident à prendre en charge ce scénario en mettant en œuvre des "sessions persistantes"..
Vous vous demandez peut-être comment un serveur peut suivre un utilisateur pour implémenter l'état de session. Si deux demandes arrivent sur un serveur, comment le serveur sait-il s'il s'agit de deux demandes émanant du même utilisateur ou s'il y a deux utilisateurs différents effectuant une seule demande??
Au tout début du Web, le logiciel serveur pouvait différencier les utilisateurs en regardant l'adresse IP d'un message de requête. De nos jours, toutefois, de nombreux utilisateurs vivent derrière des périphériques utilisant la traduction d'adresses réseau. Pour cette raison, entre autres, vous pouvez avoir plusieurs utilisateurs avec la même adresse IP. Une adresse IP n'est pas une technique fiable pour différencier les utilisateurs.
Heureusement, il existe des techniques plus fiables.
Les sites Web qui souhaitent suivre les utilisateurs se tournent souvent vers biscuits. Les cookies sont définis par RFC6265 (http://tools.ietf.org/html/rfc6265), et le présent RFC s'intitule à juste titre "Mécanisme de gestion d'état HTTP". Lorsqu'un utilisateur visite pour la première fois un site Web, celui-ci peut attribuer un cookie à son navigateur à l'aide d'un en-tête HTTP. Le navigateur sait alors envoyer le cookie dans les en-têtes de chaque requête supplémentaire qu’il envoie au site. En supposant que le site Web ait placé une sorte d'identifiant unique dans le cookie, le site peut désormais suivre un utilisateur au fur et à mesure qu'il fait des demandes et différencier un utilisateur d'un autre..
Avant d'entrer dans les détails de ce à quoi ressemblent les cookies et de leur comportement, il convient de noter quelques limitations. Premièrement, les cookies peuvent identifier les utilisateurs dans le sens où votre cookie est différent de mon cookie, mais les cookies n'authentifient pas les utilisateurs. Un utilisateur authentifié a généralement prouvé son identité en fournissant des informations d'identification telles qu'un nom d'utilisateur et un mot de passe. Les cookies dont nous parlons jusqu'à présent nous fournissent simplement un identifiant unique permettant de différencier un utilisateur d'un autre et de suivre un utilisateur au fur et à mesure des demandes adressées au site..
Deuxièmement, comme les cookies peuvent suivre ce que fait un utilisateur, ils soulèvent des problèmes de confidentialité dans certains milieux. Certains utilisateurs désactiveront les cookies dans leur navigateur, ce qui signifie que le navigateur rejettera tous les cookies envoyés par un serveur dans une réponse. Les cookies désactivés posent bien sûr un problème aux sites qui doivent suivre les utilisateurs et les alternatives sont compliquées. Par exemple, une approche des "sessions sans cookie" consiste à placer l'identifiant de l'utilisateur dans l'URL. Les sessions sans cookie nécessitent que chaque URL qu'un site donne à un utilisateur contienne l'identifiant approprié, et les URL deviennent beaucoup plus volumineuses (c'est pourquoi cette technique est souvent appelée technique de "l'URL en gras").
Lorsqu'un site Web veut donner un cookie à un utilisateur, il utilise un Set-Cookie en-tête dans une réponse HTTP.
HTTP / 1.1 200 OK Type de contenu: text / html; jeu de caractères = utf-8 Set-Cookie: fname = Scott $ lname = Allen; domain = .mywebsite.com; chemin = /…
Le cookie présenté dans cet exemple contient trois zones d’information. Les trois zones sont délimitées par des points-virgules (;). Premièrement, il existe une ou plusieurs paires nom-valeur. Ces paires nom-valeur sont délimitées par un signe dollar ($) et ressemblent beaucoup à la façon dont les paramètres de requête sont formatés en une URL. Dans l'exemple de cookie, le serveur souhaitait stocker le prénom et le nom de l'utilisateur dans le cookie. Les deuxième et troisième zones sont respectivement le domaine et le chemin. Nous reviendrons plus tard pour parler du domaine et du chemin..
Un site Web peut mettre toutes les informations qu'il souhaite dans un cookie, bien que sa taille soit limitée à 4 Ko. Cependant, de nombreux sites Web n'indiquent qu'un identifiant unique pour un utilisateur, par exemple un GUID. Un serveur ne peut jamais faire confiance à quoi que ce soit stocké sur le client s'il n'est pas sécurisé de manière cryptographique. Oui, il est possible de stocker des données cryptées dans un cookie, mais il est généralement plus facile de stocker un identifiant.
HTTP / 1.1 200 OK Set-Cookie: GUID = 00a48b7f6a4946a8adf593373e53347c; domaine = .msn.com; chemin = /
En supposant que le navigateur est configuré pour accepter les cookies, le navigateur envoie le cookie au serveur lors de chaque requête HTTP ultérieure..
GET… HTTP / 1.1 Cookie: GUID = 00a48b7f6a4946a8adf593373e53347c;…
Lorsque l'ID arrive, le logiciel serveur peut rapidement rechercher les données utilisateur associées à partir d'une structure de données en mémoire, d'une base de données ou d'un cache distribué. Vous pouvez configurer la plupart des infrastructures d'application Web pour manipuler les cookies et rechercher automatiquement l'état de la session. Par exemple, dans ASP.NET, le Session object expose une API simple pour lire et écrire l'état de session d'un utilisateur. En tant que développeurs, nous n’avons jamais à nous soucier d’envoyer une Set-Cookie en-tête ou en lisant les cookies entrants pour trouver l’état de session associé. En coulisse, ASP.NET va gérer le cookie de session.
Session ["firstName"] = "Scott"; // écriture de l'état de la session… var lastName = Session ["lastName"]; // lecture de l'état de la session
Encore une fois, il convient de souligner que le Prénom et nom de famille les données stockées dans l'objet de session sont ne pas entrer dans le cookie. Le cookie contient uniquement un identifiant de session. Les valeurs associées à l'identifiant de session sont sécurisées sur le serveur. Par défaut, les données de session entrent dans une structure de données en mémoire et restent actives pendant 20 minutes. Lorsqu'un cookie de session arrive dans une demande, ASP.NET associe les données de session correctes au Session objet après avoir trouvé les données de l'utilisateur à l'aide de l'identifiant stocké dans le cookie. S'il n'y a pas de cookie entrant avec un ID de session, ASP.NET en créera un avec un Set-Cookie entête.
Un problème de sécurité lié aux identificateurs de session est la manière dont ils peuvent ouvrir la possibilité à une personne de détourner la session d'un autre utilisateur. Par exemple, si j’utilise un outil tel que Fiddler pour suivre le trafic HTTP, il se peut que je voie un Set-Cookie en-tête proviennent d'un serveur avec SessionID = 12 à l'intérieur. Je devine peut-être qu'un autre utilisateur a déjà un ID de session sur 11, et créez une requête HTTP avec cet ID uniquement pour voir si je peux voler ou afficher le code HTML destiné à un autre utilisateur. Pour lutter contre ce problème, la plupart des applications Web utiliseront de grands nombres aléatoires comme identificateurs (ASP.NET utilise une résolution aléatoire de 120 bits). Un identifiant de session ASP.NET ressemble à ce qui suit, ce qui rend plus difficile de deviner à quoi ressemblerait l'ID de session d'une autre personne..
Set-Cookie: ASP.NET_SessionId = en5yl2yopwkdamv2ur5c3z45; chemin = /; HttpOnly
Un autre problème de sécurité lié aux cookies est leur vulnérabilité à une attaque par script intersite (XSS). Lors d'une attaque XSS, un utilisateur malveillant injecte du code JavaScript malveillant dans le site Web d'une autre personne. Si l'autre site envoie le script malveillant à ses utilisateurs, ce dernier peut modifier, inspecter et dérober des informations de cookie (ce qui peut entraîner un détournement de session ou pire)..
Pour lutter contre cette vulnérabilité, Microsoft a introduit le HttpOnly drapeau (vu dans le dernier Set-Cookie Exemple). le HttpOnly flag indique à l'agent utilisateur de ne pas autoriser le code de script à accéder au cookie. Le cookie existe pour "HTTP uniquement" -i.e. voyager dans l'en-tête de chaque message de requête HTTP. Les navigateurs qui implémentent HttpOnly n'autorisera pas JavaScript à lire ou à écrire le cookie sur le client.
Les cookies que nous avons vus jusqu'à présent sont cookies de session. Les cookies de session existent pour une session utilisateur unique et sont détruits lorsque l'utilisateur ferme le navigateur.. Cookies persistants peut survivre à une seule session de navigation et un agent utilisateur stockera les cookies sur le disque. Vous pouvez éteindre un ordinateur et revenir une semaine plus tard, accéder à votre site Web préféré, et un cookie persistant sera toujours là pour la première demande..
La seule différence entre les deux est qu’un cookie persistant nécessite un Expire valeur.
Set-Cookie: nom = valeur; expire = lundi, 09-juillet-2012 21:12:00 GMT
Un cookie de session peut explicitement ajouter un Jeter attribuer à un cookie, mais sans Expire l’utilisateur doit supprimer le cookie dans tous les cas..
Jusqu'à présent, nous avons dit qu'une fois qu'un cookie est défini par un site Web, le cookie sera redirigé vers le site Web à chaque nouvelle demande (en supposant que le cookie ne soit pas expiré). Cependant, tous les cookies ne se rendent pas sur tous les sites. Les seuls cookies qu'un agent utilisateur doit envoyer sur un site sont les cookies donnés à l'agent utilisateur par le même site. Il n’a pas de sens que les cookies de amazon.com soient dans une requête HTTP adressée à google.com. Ce type de comportement ne pouvait que susciter des préoccupations supplémentaires en matière de sécurité et de confidentialité. Si vous définissez un cookie dans une réponse à une demande adressée à www.server.com, le cookie résultant sera acheminé uniquement dans les demandes adressées à www.server.com..
Une application Web peut également modifier la portée d'un cookie pour le limiter à un hôte ou à un domaine spécifique, voire à un chemin de ressource spécifique. L’application Web contrôle l’étendue à l’aide de la touche domaine et chemin les attributs.
HTTP / 1.1 200 OK Set-Cookie: nom = valeur; domaine = .server.com; path = / stuff…
le domaine attribut permet à un cookie de s'étendre sur des sous-domaines. En d'autres termes, si vous définissez un cookie à partir de www.server.com, l'agent utilisateur n'enverra le cookie qu'à www.server.com. Le domaine de l'exemple précédent permet également au cookie de se rendre vers n'importe quelle URL du domaine server.com, y compris images.server.com, help.server.com et tout simplement server.com. Vous ne pouvez pas utiliser l'attribut de domaine pour étendre des domaines. Il n'est donc pas légal de définir le domaine sur .microsoft.com dans une réponse à .server.com. L'agent utilisateur doit rejeter le cookie..
le chemin attribut peut restreindre un cookie à un chemin de ressource spécifique. Dans l'exemple précédent, le cookie ne se rendra sur un site server.com que lorsque l'URL de la demande pointe vers /des trucs, ou un endroit en dessous /des trucs, comme / stuff / images. Les paramètres de chemin peuvent aider à organiser les cookies lorsque plusieurs équipes créent des applications Web selon des chemins différents..
Les cookies permettent aux sites Web de stocker des informations dans le client. Ces informations seront ensuite renvoyées sur les sites lors de demandes ultérieures. Les avantages pour le développement Web sont énormes, car les cookies nous permettent de savoir quelle requête appartient à quel utilisateur. Mais, les cookies ont des problèmes que nous avons déjà évoqués.
Comme nous l'avons mentionné précédemment, les cookies sont vulnérables aux attaques XSS et reçoivent également une mauvaise publicité lorsque des sites (en particulier des sites de publicité) utilisent cookies tiers suivre les utilisateurs sur Internet. Les cookies tiers sont des cookies qui sont définis à partir d'un domaine différent de celui de la barre d'adresse du navigateur. Les cookies tiers offrent cette possibilité car de nombreux sites Web, lors du renvoi d’une ressource de page au client, incluent des liens vers des scripts ou des images à partir d’autres URL. Les demandes qui accèdent aux autres URL permettent aux autres sites de définir des cookies..
Par exemple, la page d’accueil sur server.com peut inclure un >
Les deux inconvénients majeurs des cookies, cependant, sont la manière dont ils interfèrent avec la mise en cache et la manière dont ils transmettent les données à chaque demande. Toute réponse avec un Set-Cookie l'en-tête ne doit pas être mis en cache, du moins pas les en-têtes, car cela pourrait interférer avec l'identification de l'utilisateur et créer des problèmes de sécurité. N'oubliez pas non plus que tout ce qui est stocké dans un cookie est visible lorsqu'il se déplace sur le réseau (et dans le cas d'un cookie persistant, du fait qu'il se trouve sur le système de fichiers). Comme nous savons que de nombreux périphériques peuvent écouter et interpréter le trafic HTTP, un cookie ne devrait jamais stocker d'informations sensibles. Même les identifiants de session sont risqués, car si quelqu'un peut intercepter l'ID d'un autre utilisateur, il peut voler les données de la session au serveur..
Même avec tous ces inconvénients, les cookies ne vont pas disparaître. Parfois, nous avons besoin d'un état pour voyager via HTTP, et les cookies offrent cette possibilité de manière simple et généralement transparente. Une autre capacité dont nous avons parfois besoin est la capacité d'authentifier l'utilisateur. Nous discuterons ensuite des fonctionnalités d'authentification.
Le processus d'authentification oblige un utilisateur à prouver son identité en saisissant un nom d'utilisateur et un mot de passe, un courrier électronique et un code PIN, ou un autre type d'informations d'identification..
Au niveau du réseau, l'authentification suit généralement un format défi / réponse. Le client demandera une ressource sécurisée et le serveur demandera au client de s'authentifier. Le client doit ensuite envoyer une autre demande et inclure les informations d'authentification à valider par le serveur. Si les informations d'identification sont bonnes, la demande aboutira.
L'extensibilité de HTTP permet à HTTP de prendre en charge divers protocoles d'authentification. Dans cette section, nous examinerons brièvement le top 5: base, digest, Windows, formulaires et OpenID. Sur ces cinq, seuls deux sont "officiels" dans la spécification HTTP: les protocoles d'authentification de base et de synthèse. Nous allons regarder ces deux premiers.
Avec l’authentification de base, le client demande d’abord une ressource avec un message HTTP normal..
GET http: // localhost / html5 / HTTP / 1.1 Hôte: localhost
Les serveurs Web vous permettront de configurer l'accès à des fichiers et des répertoires spécifiques. Vous pouvez autoriser l'accès à tous les utilisateurs anonymes ou limiter l'accès afin que seuls des utilisateurs ou des groupes spécifiques puissent accéder à un fichier ou à un répertoire. Pour la requête précédente, imaginons que le serveur est configuré pour autoriser uniquement certains utilisateurs à afficher les informations. / html5 / Ressource. Dans ce cas, le serveur émettra un défi d'authentification..
HTTP / 1.1 401 Authentification WWW non autorisée: Royaume de base = "localhost"
le 401 Le code d'état indique au client que la demande n'est pas autorisée. le WWW-Authentifier en-tête indique au client de collecter les informations d'identification de l'utilisateur et de réessayer. le domaine attribut donne à l'agent utilisateur une chaîne qu'il peut utiliser comme description de la zone protégée. Ce qui se passera ensuite dépend de l'agent utilisateur, mais la plupart des navigateurs peuvent afficher une interface utilisateur permettant à l'utilisateur de saisir ses informations d'identification..
Dialogue d'authentification Avec les informations d'identification en main, le navigateur peut envoyer une autre demande au serveur. Cette demande comprendra un Autorisation entête.
GET http: // localhost / html5 / HTTP / 1.1 Autorisation: Base bm86aXdvdWxkbnRkb3RoYXQh
La valeur de l'en-tête d'autorisation est le nom d'utilisateur et le mot de passe du client dans un codage base 64.. L'authentification de base n'est pas sécurisée par défaut, Toute personne disposant d'un décodeur en base 64 et pouvant consulter le message peut voler le mot de passe d'un utilisateur. Pour cette raison, l'authentification de base est rarement utilisée sans utiliser le protocole HTTP sécurisé, que nous examinerons plus loin..
Il incombe au serveur de décoder l'en-tête d'autorisation et de vérifier le nom d'utilisateur et le mot de passe avec le système d'exploitation, ou le système de gestion des informations d'identification qui se trouve sur le serveur. Si les informations d'identification correspondent, le serveur peut répondre normalement. Si les informations d'identification ne correspondent pas, le serveur doit répondre par un message. 401 statut à nouveau.
L'authentification Digest constitue une amélioration par rapport à l'authentification de base car elle ne transmet pas les mots de passe des utilisateurs à l'aide du codage en base 64 (qui consiste essentiellement à transmettre le mot de passe en texte brut). Au lieu de cela, le client doit envoyer un digérer du mot de passe. Le client calcule le résumé à l'aide de l'algorithme de hachage MD5 avec un nonce fourni par le serveur pendant le défi d'authentification (un nonce est un numéro cryptographique utilisé pour aider à prévenir les attaques par rejeu.).
La réponse à l’enquête de synthèse est semblable à la réponse à l’enquête de base d’authentification, mais avec des valeurs supplémentaires provenant du serveur dans le répertoire. WWW-Authentifier en-tête à utiliser dans les fonctions cryptographiques.
HTTP / 1.0 401 Authentification WWW non autorisée: Digest realm = "localhost", qop = "auth, auth-int", nonce = "dcd98b7102dd2f0e8b11d0f600bfb0c093", opaque = "5ccc069c403ebafff170917"
L'authentification Digest est meilleure que l'authentification de base lorsque le protocole HTTP sécurisé n'est pas disponible, mais il est encore loin d'être parfait. L'authentification Digest est toujours vulnérable aux attaques d'interception dans lesquelles une personne renifle le trafic réseau.
L'authentification intégrée de Windows n'est pas un protocole d'authentification standard, mais elle est populaire parmi les produits et les serveurs Microsoft. Bien que l’authentification Windows soit prise en charge par de nombreux navigateurs modernes (pas uniquement Internet Explorer), elle ne fonctionne pas bien sur Internet ou là où résident les serveurs proxy. Vous constaterez qu'il est courant sur les sites Web internes et intranet sur lesquels existe un serveur Microsoft Active Directory..
L'authentification Windows dépend des protocoles d'authentification sous-jacents pris en charge par Windows, notamment NTLM et Kerberos. Les étapes de défi / réponse de l’authentification Windows sont très similaires à ce que nous avons déjà vu, mais le serveur spécifiera NTLM ou Négocier dans le WWW-Authentifier entête (Négocier est un protocole qui permet au client de sélectionner Kerberos ou HTML).
HTTP / 1.1 401 Authentification WWW non autorisée: Négocier
L'authentification Windows présente l'avantage d'être sécurisée, même sans utiliser de protocole HTTP sécurisé, et d'être discrète pour les utilisateurs d'Internet Explorer. Internet Explorer authentifiera automatiquement un utilisateur lorsqu'il est mis en cause par un serveur et le fera à l'aide des informations d'identification de l'utilisateur avec lesquelles il s'est connecté au système d'exploitation Windows..
L’authentification par formulaires est l’approche la plus populaire pour l’authentification des utilisateurs sur Internet. L’authentification basée sur les formulaires n’est pas un protocole d’authentification standard et n’utilise pas WWW-Authentifier ou Autorisation en-têtes. Cependant, de nombreux frameworks d’applications Web fournissent une prise en charge immédiate de l’authentification basée sur des formulaires..
Avec l'authentification basée sur des formulaires, une application répond à une demande de ressource sécurisée par un utilisateur anonyme en redirigeant l'utilisateur vers une page de connexion. La redirection est une redirection temporaire HTTP 302. En règle générale, l’URL demandée par l’utilisateur peut être incluse dans la chaîne de requête de l’emplacement de redirection afin que, une fois l’utilisateur connecté, l’application puisse le rediriger vers la ressource sécurisée qu’il essayait d’atteindre..
HTTP / 1.1 302 Emplacement trouvé: /Login.aspx?ReturnUrl=/Admin.aspx
La page de connexion pour l'authentification basée sur les formulaires est un formulaire HTML avec des entrées permettant à l'utilisateur de saisir ses informations d'identification. Lorsque l'utilisateur clique sur Soumettre, les valeurs du formulaire POSTER vers une destination où l'application doit extraire les informations d'identification et les valider par rapport à un enregistrement de base de données ou à un système d'exploitation.
Notez que l'authentification basée sur les formulaires transmettra les informations d'identification d'un utilisateur sous forme de texte brut. Par conséquent, comme l'authentification de base, l'authentification basée sur des formulaires n'est pas sécurisée, sauf si vous utilisez le protocole HTTP sécurisé. En réponse à la POSTER message avec les informations d'identification (en supposant que les informations d'identification sont bonnes), l'application redirigera généralement l'utilisateur vers la ressource sécurisée et créera également un cookie indiquant que l'utilisateur est maintenant authentifié.
HTTP / 1.1 302 Emplacement trouvé: /admin.aspx Set-Cookie: .ASPXAUTH = 9694BAB… path = /; HttpOnly
Pour ASP.NET, le ticket d'authentification (le .ASPXAUTH valeur du cookie) est cryptée et hachée afin d’empêcher toute altération. Cependant, sans HTTP sécurisé, le cookie est susceptible d'être intercepté, le détournement de session reste donc un problème potentiel. Cependant, l'authentification par formulaires reste populaire car elle permet aux applications de contrôler totalement l'expérience de connexion et la validation des informations d'identification..
Alors que l'authentification basée sur les formulaires donne à une application un contrôle total sur l'authentification de l'utilisateur, de nombreuses applications ne souhaitent pas ce niveau de contrôle. Plus précisément, les applications ne veulent pas gérer et vérifier les noms d'utilisateur et les mots de passe (et les utilisateurs ne veulent pas avoir un nom d'utilisateur et un mot de passe différents pour chaque site Web). OpenID est un standard ouvert pour l'authentification décentralisée. Avec OpenID, un utilisateur s'enregistre auprès d'un fournisseur d'identité OpenID, et le fournisseur d'identité est le seul site qui doit stocker et valider les informations d'identification de l'utilisateur. Il existe de nombreux fournisseurs OpenID dans le monde, notamment Google, Yahoo et Verisign..
Lorsqu'une application doit authentifier un utilisateur, cela fonctionne avec l'utilisateur et le fournisseur d'identité de l'utilisateur. L’utilisateur doit en fin de compte vérifier son nom d’utilisateur et son mot de passe auprès du fournisseur d’identité, mais l’application saura si l’authentification réussit grâce à la présence de jetons cryptographiques et de secrets. Google dispose d'une vue d'ensemble du processus sur sa page Web "Connexion fédérée pour les utilisateurs de compte Google" (https://developers.google.com/accounts/docs/OpenID)..
Alors que OpenID offre de nombreux avantages potentiels par rapport à l'authentification par formulaires, il a été confronté à un manque d'adoption en raison de la complexité liée à la mise en œuvre, au débogage et à la maintenance de la connexion OpenID. Il faut espérer que les boîtes à outils et les frameworks continuent d'évoluer pour faciliter l'approche OpenID en matière d'authentification..
Auparavant, nous avons expliqué comment les messages HTTP textuels auto-descriptifs sont l’un des atouts du Web. Tout le monde peut lire un message et comprendre ce qu’il contient. Cependant, nous envoyons sur le Web de nombreux messages que nous ne souhaitons pas que quiconque les voie. Nous avons discuté de certains de ces scénarios dans ce livre. Par exemple, nous ne voulons pas que nos collègues du réseau voient nos mots de passe, mais nous ne voulons pas non plus qu'ils voient nos numéros de carte de crédit ou de compte bancaire. Le protocole HTTP sécurisé résout ce problème en chiffrant les messages avant qu'ils ne soient acheminés sur le réseau..
Le protocole HTTP sécurisé est également appelé HTTPS (car il utilise une https schéma dans l'URL au lieu d'un régulier http schème). Le port par défaut pour HTTP est le port 80 et le port par défaut pour HTTPS est le port 443. Le navigateur se connectera au port approprié en fonction du schéma (sauf s'il doit utiliser un port explicite présent dans l'URL). Le protocole HTTPS utilise une couche de sécurité supplémentaire dans la pile de protocoles réseau. La couche de sécurité existe entre les couches HTTP et TCP, et utilise le protocole TLS (Transport Layer Security) ou son prédécesseur appelé SSL (Secure Sockets Layer)..
Couches de protocole HTTP sécurisées HTTPS nécessite un serveur pour avoir un certificat cryptographique. Le certificat est envoyé au client lors de l’installation de la communication HTTPS. Le certificat comprend le nom d'hôte du serveur, et un agent d'utilisateur peut utiliser ce certificat pour valider qu'il est en communication avec le serveur avec lequel il pense parler. La validation est rendue possible par la cryptographie à clé publique et l’existence d’autorités de certification, telles que Verisign, qui signeront et garantiront l’intégrité d’un certificat. Les administrateurs doivent
Accentsconagua