La vulnérabilité des services d'authentification web correspond aux faiblesses des protocoles d'authentification du web.

Les attaques contre les services d'authentification HTTP et HTTPS sont de plus en plus sophistiquées et touchent désormais les navigateurs. Pour faire face à cela, les développeurs ont décidé d'augmenter la sécurité de leur logiciel en proposant de nouvelles fonctionnalités, par exemple, un système de gestion de mot de passe.

Les usagers d’Internet sont confrontés à un nombre croissant d’applications web nécessitant de s’authentifier. Cette authentification permet de s’assurer que l’utilisateur est bien la personne qu'il prétend être mais aussi de lui fournir des informations personnalisées en fonction de son profil et des données personnelles qu’il transmet. Elle est donc sujette à de nombreuses attaques de la part de personnes malveillantes qui souhaitent en exploiter toutes ses vulnérabilités. L’exploitation de ces failles peut être utilisée pour compromettre les services d’authentification web, même les plus forts et les plus connus, que ce soit par mots de passe, cookies d'authentification, ou avec l'utilisation de SSL^{[1],[Note 1]}.

L'authentification HTTP^{[Note 2]} permet de s'identifier auprès d'un serveur HTTP à l’aide d’un nom d’utilisateur et d’un mot de passe. Il existe deux méthodes : la méthode Basic et la méthode Digest.

Cette méthode est la plus simple mais également la moins sécurisée. L'utilisateur doit fournir un nom d'utilisateur et un mot de passe pour s'authentifier. Le nom d'utilisateur et le mot de passe sont concaténés avec deux points et le tout est encodé en base 64^[2]. Il est donc très facile de décoder les données et d'obtenir les informations d'identification. Cette méthode est donc très vulnérable aux attaques par écoute. Il est possible de diminuer les risques par l'utilisation du protocole SSL, qui va envoyer les données sous forme chiffrée. Toutefois, cette méthode reste vulnérable à de nombreuses attaques côté client, mais aussi à l'attaque de l'homme du milieu et également aux attaques par brute force^[3].

L'authentification Digest a été conçue comme une amélioration de l'authentification HTTP de base. L'une des principales améliorations est que les données ne sont pas transmises en clair mais sont transmises à l'aide d'un message digeste chiffré^[4]. Si cette méthode est moins vulnérable aux attaques par écoute, elle le reste encore aux attaques par rejeu. En effet, si un attaquant est en mesure de rejouer le message digeste chiffré alors le serveur lui donnera l’accès^[5].

Toutefois, il arrive que le nonce fournit par le serveur contienne un timestamp. Ceci permet au serveur d'en vérifier la valeur lors de l'authentification : si la valeur du nonce est dépassée, alors la demande du client est rejetée^[6].

Une autre menace répandue est connue par le terme hameçonnage^{[Note 3]}. Elle consiste à employer diverses techniques pour récolter les informations d’un utilisateur. Cette collecte d'informations illégales peut être réalisée par plusieurs méthodes mais la plus répandue est le déploiement d’un faux site en trompant l'utilisateur sur sa légitimité. Pour être réalisée, l’attaquant imite un site et son nom de domaine. Puis il transmet ce site, quasi semblable au site légitime, à la victime. L'utilisateur tente donc de s'identifier au sein du site contrefait, tout en pensant être sur le site légitime. Et comme avec le protocole HTTP, les mots de passe sont transmis en clair, l’attaquant peut les récupérer. La capacité des utilisateurs à identifier de manière fiable la légitimité d'un site Web est donc essentielle^[7].

Ces techniques d’attaques sont devenues de plus en plus sophistiquées. Certains hameçonneurs vont jusqu'à faire suivre les données jusqu'au site authentique afin de voler ou détourner la session de la victime. Prenons l’exemple d’une victime qui transmet les données de son compte bancaire pour un transfert d’argent : l’attaquant peut modifier la requête pour rediriger le transfert sur son propre compte. Une façon de se prémunir est d’utiliser l’authentification mutuelle, également appelée authentification à double sens. Avec ce procédé, les deux entités doivent s’identifier mutuellement avant de pouvoir communiquer : le client authentifie le serveur et vice versa. L’utilisateur s’assure donc de bien communiquer avec le serveur légitime et réciproquement le serveur s’assure que l’utilisateur est là dans un but légitime ^[8].

Une variante de l'hameçonnage est le dévoiement^{[Note 4],[9]}. Ce type d’attaque vise à pratiquer l'hameçonnage par la redirection de l'utilisateur, grâce au DNS^{[Note 5]}, sur un serveur contrôlé par l’attaquant. Pour mener cette attaque, l’attaquant peut, par exemple, fournir un document web contenant un code malveillant à sa victime, puis exploiter la vulnérabilité du navigateur à gérer le DNS et forcer le navigateur de la victime à se connecter au serveur. Une fois l’utilisateur authentifié auprès du serveur, l’attaquant utilise le code malveillant pour détourner la session de la victime authentifiée ^[10].

Les cookies sont le moyen principal pour les applications web d’authentifier les requêtes HTTP et de maintenir la connexion avec le client. Ils relèvent donc d’un grand intérêt pour les pirates. Un protocole de cookie sécurisé devrait donc être en mesure de proposer les quatre services suivant : l'authentification, la confidentialité, l’intégrité et la non-duplication^[11].

Le détournement de cookie est un procédé par lequel le pirate va obtenir un accès non autorisé à des informations confidentielles. Pour cela, il va voler les cookies qui contiennent les informations nécessaires pour authentifier un utilisateur à un serveur web distant. Il suffit juste que la valeur du cookie existe dans la requête pour être authentifié auprès du serveur. Dès lors, n’importe quelle personne possédant la valeur du cookie est en mesure de s’authentifier avec l’identité de l’utilisateur. Ce détournement peut être effectué par le pirate en utilisant un ordinateur entre le nœud et le serveur ou en récupérant directement les cookies stockés sur l'ordinateur de l'utilisateur. Par défaut, la valeur du cookie est envoyée en clair, chaque partie ayant accès au réseau peut donc renifler la valeur ^[12]. Alors que SSL/TLS^{[Note 6]} protège contre cette menace, de nombreux sites ne protègent que la page de connexion avec SSL/TLS puis reviennent à du HTTP ce qui revient à laisser visible la valeur du cookie ^[13].

Toutefois, même avec l’existence d’une connexion SSL/TLS, le cookie est lisible par défaut avec JavaScript via la propriété document.cookie. De ce fait, l’utilisation d’un Cross-site Scripting (XSS) permet quand même au pirate d’obtenir la valeur du cookie^[14]. Pour contrer cette menace, les éditeurs de navigateurs ont introduit le HTTPonly-flag^[15] qui permet de cacher la valeur du cookie depuis JavaScript^[16].

L’attaque par fixation de session est une attaque proche du vol de session. Cette attaque permet à une personne mal intentionnée de déterminer l'identifiant de session d'une autre personne. En connaissant le SID^{[Note 7]} d’un utilisateur, il est possible de l’utiliser et de récupérer sa session pour soi. Cette attaque repose sur le fait que, lorsqu’un utilisateur s’authentifie, un nouveau SID ne lui est pas attribué, ce qui rend possible l’utilisation de son SID. Avec cette attaque, l’attaquant fixe le SID de l’utilisateur, avant même que celui-ci n’ouvre une session sur le serveur cible. Cette méthode évite ainsi à l’attaquant de devoir récupérer par la suite le SID de l’utilisateur. Pour ce faire, l’attaquant ouvre une session sur le serveur et obtient un SID valide. Puis, il transmet ce dernier à sa victime, à l’aide d’un lien, par exemple au travers d’un email. La victime clique sur le lien et se connecte au serveur. Une fois la connexion établie, l’attaquant peut envoyer de nouvelles requêtes aux serveurs et comme il possède le même SID, il a accès aux données. La session a été détournée^[17].

L’objet de cette attaque est de forcer des utilisateurs à exécuter une ou plusieurs requêtes non désirées sur un site donné. L’utilisateur devient donc complice d’une attaque sans même en avoir conscience ^[18]. Cette dernière étant actionnée par l'utilisateur, un grand nombre de systèmes d'authentification sont contournés. Pour cette attaque, l’attaquant falsifie une requête HTTP qui pointe sur une action précise interne au site (souvent par le biais d’une URL^{[Note 9]}, ou d’un formulaire). Puis, il se charge de la transmettre à la victime afin que celle-ci l'exécute sans en avoir conscience. L'intérêt de cette attaque et de pouvoir obtenir les droits de la victime pour réaliser une action dont l'attaquant ne possède pas l’autorisation^[19].

Transport Layer Security (TLS), aussi connu sous le nom précédent de Secure Sockets Layer (SSL), est un protocole qui a pour objectif de fournir la confidentialité et l'intégrité des données entre deux applications en communication^[20]. Son utilisation conjointe avec le protocole HTTP permet de se protéger contre certaines attaques en chiffrant les communications et les authentifications clients/serveurs. HTTPS^{[Note 10]} permet donc de transférer des données par le port 443 en utilisant un chiffrement asymétrique^[21]. Toutefois même si ce protocole est plus sécurisé, il peut également être compromis de différentes façons. Par exemple, Burkhoder a proposé une attaque qui consiste à renifler les données HTTPS en utilisant un faux certificat ^[22].

On peut également mentionner l'attaque qui consiste à ce qu’une personne malveillante se mette au milieu de la conversation et se fasse passer pour le serveur, dite attaque de l'homme du milieu. De même, l'attaque proposée en 2009 par Moxie Marlinspike est difficilement repérable par la victime car elle peut être menée sans avertissement de la part du navigateur. Les navigateurs web (tels que Chrome, IE, Firefox, Opera, Safari) émettent des messages d’avertissement sérieux face à un faux certificat SSL. Pour éviter ces messages, Marlinspike a proposé une nouvelle technique d'examen du SSL qui consiste à intercepter la communication, puis détourner le trafic HTTPS sur un réseau et le rediriger vers le navigateur client, les communications dans ce cas peuvent donc être espionnées puisqu’il n’y a plus de chiffrement et dans ce cas l’attaque peut se faire sans avertissement de la part du navigateur^[23],[24].

La concurrence sur le marché des navigateurs motive les développeurs à en faire plus qu’un simple outil pour la visualisation des pages web. La norme ISO 9126^[25] définit la qualité des fonctionnalités proposés par ces navigateurs. L’une d’elles consiste à la mise en place d’un système de gestion de mots de passe.

Ce besoin d'authentification provient du fait que de nombreuses applications web implémentent des sessions sécurisées qui demandent à l’utilisateur de s’authentifier à l’aide d’un nom d’utilisateur et d’un mot de passe. Ces méthodes obligent donc l’utilisateur à connaître ses multiples identifiants suivant chaque site. Face à cette problématique, les développeurs de navigateurs ont donc mis en place un système de gestion de mots de passe facilitant l’authentification de l’utilisateur. Ce système demande simplement que l'utilisateur se souvienne d'un mot de passe maître qui sera utilisé pour déchiffrer les autres qui se trouvent dans la base de données du gestionnaire de mots de passe^[26].

L'utilisation d'un gestionnaire de mots de passe a un autre avantage. L’adresse URL, ou au moins le nom de domaine, est stockée à côté du mot de passe correspondant. Elle permet au navigateur de remplir automatiquement le formulaire de connexion. Si l'utilisateur est dirigé vers un site web malveillant qui est conçu pour ressembler à l'identique au site légitime qu'il attend, alors le gestionnaire de mots de passe ne pourra pas autocompléter les champs du formulaire et connecter l’utilisateur. Ainsi, les utilisateurs qui utilisent un gestionnaire de mots de passe sont moins sensibles aux typosquattages ^[27] et aux attaques par hameçonnage.

Mozilla Firefox stocke ses données de connexion dans deux fichiers différents. Le premier fichier key3.db stocke le mot de passe principal pour accéder à la base de données, le second signons.sqlite stocke les mots de passe et les adresses des sites dans une base SQLite. Les identifiants sont chiffrés avec le mot de passe maître du fichier key3.db et encodés en Base64. Si l'utilisateur ne fournit pas de mot de passe maître alors Firefox utilise une valeur par défaut pour chiffrer les données. Quant aux adresses URL, elles sont toujours stockées en clair avec ou sans mot de passe maître^[28].

Si un attaquant souhaite déchiffrer les données de signons.sqlite, il doit d'abord obtenir le mot de passe principal stocké dans key3.db. Pour cela, différentes méthodes sont possibles : les attaques par brute force, soit en générant tous les mots de passe possibles à partir d'un vocabulaire donné, soit en utilisant un dictionnaire.

La sûreté des différents mots de passe repose donc sur la robustesse^[29] du mot de passe principal.

Mozilla Firefox stocke aussi d’autres données non chiffrées, comme le nom des champs de formulaire renseignés avec le mot de passe et le nom d’utilisateur. Le problème est que si un attaquant arrive à obtenir l’accès à la base de données, il peut récolter une quantité d’informations considérable. Il peut par exemple récupérer les adresses des sites Internet où la victime a des mots de passe enregistrés et monter une attaque par hameçonnage en s'appuyant sur les informations récoltées.

Google Chrome stocke les noms d'utilisateur et mots de passe, ainsi que d'autres données personnelles dans un fichier de base de données SQLite dans le répertoire du profil utilisateur. Seul le mot de mot de passe est chiffré et les autres données sont accessibles facilement. De ce fait, n'importe quelle personne ayant accès à la base de données peut en lire le contenu et y apporter facilement des modifications. L'utilisateur ne peut donc pas se fier à la confidentialité et l'intégrité de ses données. De même, Google Chrome ne propose pas de mot de passe principal comme Firefox. Mais il est possible d'installer une extension qui ajoute cette fonctionnalité et permet d'ajouter une couche de sécurité^[30].

Il est également possible de stocker les identifiants sur les serveurs de Google pour permettre la synchronisation avec les différents appareils. Les pages de support de Chrome affirment que les mots de passe sont stockés sous forme chiffrée sur les serveurs de Google ^[31].

Internet Explorer stocke les noms d'utilisateur et mots de passe dans le registre. Chaque enregistrement est stocké comme une entrée de registre distincte et est chiffré en utilisant les informations de connexion du système. Internet Explorer stocke l'URL de la page en utilisant une fonction de hachage SHA1^[32]. L'URL et le mot de passe de session sont ensuite utilisés comme clés avec un algorithme de chiffrement fourni par Windows pour chiffrer le mot de passe et le nom d’utilisateur. La sécurité du gestionnaire de mot de passe sous Internet Explorer dépend donc également de la robustesse du mot de passe du compte utilisateur^[33].

Les attaques sur les flux de données entre un client et un serveur sont devenues plus sophistiquées. Désormais, les attaques visent plutôt à contourner la protection de sécurité utilisée par les logiciels du client. MITB^{[Note 11]} est un type d’attaque qui consiste à infiltrer un logiciel client tel que le navigateur d’une victime, ce qui permet de lui voler des informations sensibles ou de manipuler les transactions entre le client et le navigateur. L’attaque MITB est conçue pour manipuler les informations entre le client et le navigateur. Ce type d’attaque est généralement compliqué à détecter en raison de sa nature qui consiste à attacher secrètement un code malveillant dans une extension du navigateur. L'attaquant attend ensuite que l’utilisateur visite certains sites Internet pour enregistrer les informations saisies et les manipule avant de les transmettre au serveur^[34].

• (en) Chomsiri, T., « HTTPS Hacking Protection », Advanced Information Networking and Applications Workshops, 2007, AINAW '07. 21st International Conference on, vol. 1,‎ mai 2007, p. 590 - 594 (ISBN 978-0-7695-2847-2, DOI 10.1109/AINAW.2007.200)

• (en) Puangpronpitag, S., « Simple and Lightweight HTTPS Enforcement to Protect against SSL Striping Attack », Computational Intelligence, Communication Systems and Networks (CICSyN), 2012 Fourth International Conference on, vol. 1,‎ juillet 2012, p. 590 - 594 (ISBN 978-1-4673-2640-7, DOI 10.1109/CICSyN.2012.50)

• (en) Sugavanesh, B., Hari Prasath, R. et Selvakumar, S., « SHS-HTTPS Enforcer: Enforcing HTTPS and Preventing MITM Attacks », Newsletter, ACM SIGSOFT Software Engineering Notes, vol. 38, n^o 6,‎ novembre 2013, p. 1-4 (ISSN 0163-5948, DOI 10.1145/2532780.2532802)

• (en) Durumeric, Zakir, Kasten, James, Bailey, Michael et Halderman, J. Alex, « Analysis of the HTTPS certificate ecosystem », IMC '13 Proceedings of the 2013 conference on Internet measurement conference,‎ 2013, p. 291-304 (ISBN 978-1-4503-1953-9, DOI 10.1145/2504730.2504755)

• (en) Arnbak, Axel, Asghari, Hadi, Van Eeten, Michel et Van Eijk, Nico, « Security Collapse in the HTTPS Market », Communications of the ACM, vol. 57, n^o 10,‎ septembre 2014, p. 47-55 (ISSN 0001-0782, DOI 10.1145/2660574)

• (en) Puangpronpitag, S. et Sriwiboon, N., « Simple and Lightweight HTTPS Enforcement to Protect against SSL Striping Attack », Computational Intelligence, Communication Systems and Networks (CICSyN), 2012 Fourth International Conference on,‎ juillet 2012, p. 229 - 234 (ISBN 978-1-4673-2640-7, DOI 10.1109/CICSyN.2012.50)

• (en) Nagarajan, V. et Huang, Dijiang., « Secure web referral service », Information Networking (ICOIN), 2012 International Conference on,‎ février 2012, p. 53-58 (ISBN 978-1-4673-0251-7, DOI 10.1109/ICOIN.2012.6164348)

• (en) Nagarajan, V. et Huang, Dijiang., « Improving Secure Server Performance by EAMRSA SSL Handshakes », Industrial Control and Electronics Engineering (ICICEE), 2012 International Conference on,‎ aout 2012, p. 1896 - 1899 (ISBN 978-1-4673-1450-3, DOI 10.1109/ICICEE.2012.503)

• (en) Abd Aziz,N., Udzir, N.I. et Mahmod, R., « Performance analysis for extended TLS with mutual attestation for platform integrity assurance », Industrial Control and Electronics Engineering (ICICEE), 2012 International Conference on Cyber Technology in Automation, Control, and Intelligent Systems (CYBER), 2014 IEEE 4th Annual International Conference on,‎ juin 2014, p. 13-18 (ISBN 978-1-4799-3668-7, DOI 10.1109/CYBER.2014.6917428)

• (en) Qi,Fang, Tang,Zhe et Wang,Guojun, « Attacks vs. Countermeasures of SSL Protected Trust Model », Service Oriented System Engineering (SOSE), 2013 IEEE 7th International Symposium on,‎ mars 2013, p. 584 - 593 (ISBN 978-1-4673-5659-6, DOI 10.1109/SOSE.2013.94)

• (en) Xu,Le et Li, Li, « Secure Web Referral Services for Mobile Cloud Computing », Young Computer Scientists, 2008. ICYCS 2008. The 9th International Conference for,‎ novembre 2008, p. 1986 - 1991 (ISBN 978-0-7695-3398-8, DOI 10.1109/ICYCS.2008.433)

• (en) Waleed,G.M. et Ahmad, R.B., « Security protection using simple object access protocol (SOAP) messages techniques », Electronic Design, 2008. ICED 2008. International Conference on,‎ décembre 2008, p. 1986 - 1991 (ISBN 978-1-4244-2315-6, DOI 10.1109/ICED.2008.4786714)

• (en) Liu,Yong, Zhao,Haixia et Li,Yaowei, « Research on secure transmission of SOAP messages », Computer Supported Cooperative Work in Design, 2008. CSCWD 2008. 12th International Conference on,‎ avril 2008, p. 771 - 776 (ISBN 978-1-4244-1651-6, DOI 10.1109/CSCWD.2008.4537076)

• (en) Shehab,Mohamed, Bhattacharya,Kamal et Ghafoor,Arif, « Web Services Discovery in Secure Collaboration Environments », ACM Transactions on Internet Technology (TOIT), vol. 8, n^o 1,‎ novembre 2007 (ISSN 1533-5399, DOI 10.1145/1294148.1294153)

• Guillaume, HARRY, « Failles de sécurité des applications Web », (TOIT), vol. 1.3,‎ 3 avril 2012, p. 18

• (en) Yutaka, Oiwa, Hajime, Watanabe et Hiromitsu, Takagi, « PAKE-based mutual HTTP authentication for preventing phishing attacks », ACM,‎ 27 novembre 2009, p. 1143-1144 (ISBN 978-1-60558-487-4)

• (en) Catalin, Boja, « Journal of Mobile, Embedded and Distributed Systems », (Security Survey of Internet Browsers Data Managers), vol. III, n^o 3,‎ 2011 (ISSN 2067-4074)

• (en) Aurélien, DUMAINE, « Évolution d’internet : confiance, identités, vie privée, statut des données et modèles économiques », (A),‎ 13 mars 2012, p. 18

• (en) Liu, A.X., Kovacs, J.M., Huang, Chin-Tser et Gouda, M.J., « A secure cookie protocol », http://crossecurity.com,‎ octobre 2005, p. 333 - 338 (ISSN 1095-2055, DOI 10.1109/ICCCN.2005.1523880)

• (en) Johns, Martin, Lekies, Sebastian, Braun, Bastian et Fiesch, Benjamin, « BetterAuth: Web Authentication Revisited », Proceedings of the 28th Annual Computer Security Applications Conference,‎ 2012, p. 169-178 (ISBN 978-1-4503-1312-4, DOI 10.1145/2420950.2420977)

• (en) Mitja, Kolšek, « Session Fixation Vulnerability in Web-based Applications », http://www.acrosssecurity.com,‎ 2002

• (en) Darwish, A. et Bataineh, E., « Eye tracking analysis of browser security indicators », International Conference on Computer Systems and Industrial Informatics (ICCSII),‎ décembre 2012, p. 1 - 6 (ISBN 978-1-4673-5155-3, DOI 10.1109/ICCSII.2012.6454330)

• (en) « ISO/IEC 9126 International Standard - Information Technology – Software product evaluation », Quality characteristics and guidelines for their use,‎ 1991 (lire en ligne [archive du 28 décembre 2013], consulté le 16 décembre 2014)

• (en) Gasti, Paolo et B. Rasmussen, Kasper, « On The Security of Password Manager Database Formats », Lecture Notes in Computer Science, vol. 7459,‎ 2012, p. 770 -787 (lire en ligne)

• (en) Silver, David, Jana, Suman, Chen, Eric, Jackson, Collin et Boneh, Dan, « Password Managers: Attacks and Defenses », Proceeding SEC'14 Proceedings of the 23rd USENIX conference on Security Symposium,‎ 2014, p. 449-464 (ISBN 978-1-931971-15-7)

• (en) « Protect your synced data », Google,‎ 2014 (lire en ligne)

• « Recommandations de sécurité relatives aux mots de passe », Agence nationale de la sécurité des systèmes d’information,‎ 5 juin 2012, p. 7 (lire en ligne)

• (en) Chen,Guanchen, Johnson, Matthew F., Marupally, Pavan R., Singireddy, Naveen K. et Yin, Xin, « Combating Typo-Squatting for Safer Browsing », Proceedings of the 2009 International Conference on Advanced Information Networking and Applications Workshops,‎ 2009, p. 31-36 (ISBN 978-0-7695-3639-2, DOI 10.1109/WAINA.2009.98)

• (en) Stamm, Sid, Ramzan, Zulfikar et Jakobsson, Markus, « Drive-by Pharming », Proceedings of the 9th International Conference on Information and Communications Security,‎ 2007, p. 495–506 (ISBN 978-3-540-77047-3)

• (en) P. Burkholder, « “SSL Man-in-the-Middle Attacks”, SANS Institue InfoSec Reading », ., vol. .,‎ février 2013 (lire en ligne)

• (en) Chris Karlof, David Wagner et J.D. Tygar, « Dynamic Pharming Attacks and Locked Same-origin Policies for Web Browsers », .,‎ 2007, P58-71 (ISBN 978-1-59593-703-2, DOI 10.1145/1315245.1315254)

• (en) Somnuk Puangpronpita et Nattavut Sriwiboon, « Simple and Lightweight HTTPS Enforcement to Protect against SSL Striping Attack », .,‎ 26 juin 2012, p. 229 - 234 (ISBN 978-1-4673-2640-7, DOI 10.1109/CICSyN.2012.50)

• (en) Bin Mat Nor, F., Jalil, K.A. et Manan,J.-L.A., « An enhanced remote authentication scheme to mitigate man-in-the-browser attacks », 2012 International Conference on Cyber Security, Cyber Warfare and Digital Forensic (CyberSec),‎ juin 2012, p. 271-276 (ISBN 978-1-4673-1425-1, DOI 10.1109/CyberSec.2012.6246086)

• « Mitigating Cross-site Scripting With HTTP-only Cookies », MSDN,‎ 2014 (lire en ligne)

• (en) Tatiana Alexenko, Mark Jenne, Suman Deb Roy et Wenjun Zeng, « Cross-Site Request Forgery: Attack and Defense », Consumer Communications and Networking Conference (CCNC), 2010 7th IEEE,‎ 9-12 janvier 2010, p. 1 - 2 (ISBN 978-1-4244-5175-3, DOI 10.1109/CCNC.2010.5421782)

• (en) Guy Pujolle et Ahmed Serhrouchni, « Secure Session Management with Cookies », Information, Communications and Signal Processing, 2009. ICICS 2009. 7th International Conference on,‎ 8-10 décembre 2009, p. 1 - 6 (ISBN 978-1-4244-4657-5, DOI 10.1109/ICICS.2009.5397550)

• (en) Kumar, R, « Mitigating the authentication vulnerabilities in Web applications through security requirements », Information and Communication Technologies (WICT), 2011 World Congress on,‎ 11-14 décembre 2011, p. 1294 - 1298 (ISBN 978-1-4673-0127-5, DOI 10.1109/WICT.2011.6141435)

• (en) T. Berners-Lee, R. Fielding et H. Frystyk, « Hypertext Transfer Protocol -- HTTP/1.0 », Internet Engineering Task Force,‎ mai 2011 (lire en ligne)

• (en) A. Niemi, J. Arkko et V. Torvinen, « Hypertext Transfer Protocol (HTTP) Digest Authentication Using Authentication and Key Agreement (AKA) », Internet Engineering Task Force,‎ septembre 2002 (lire en ligne)

• (en) J. Franks, P. Hallam-Baker, J. Hostetler, S. Lawrence, P. Leach, A. Luotonen et L. Stewart, « HTTP Authentication: Basic and Digest Access Authentication », Internet Engineering Task Force,‎ juin 1999 (lire en ligne)

• (en) V. Torvinen, J. Arkko et M. Naslund, « HTTP Authentication: Basic and Digest Access Authentication », Internet Engineering Task Force,‎ novembre 2005 (lire en ligne)

• (en) A. Freier, P. Karlton et P. Kocher, « The Secure Sockets Layer (SSL) Protocol Version 3.0 », Internet Engineering Task Force,‎ aout 2011 (lire en ligne)

• (en) E. Rescorla, « HTTP Over TLS », Internet Engineering Task Force,‎ mai 2000 (lire en ligne)

• (en) Moxie Marlinspike, « New Tricks For Defeating SSL In Practice », www.blackhat.com,‎ 2009 (lire en ligne)

• (en) « HttpOnly », OWASP,‎ 2014 (lire en ligne)

• (en) Takesue, M., « An HTTP Extension for Secure Transfer of Confidential Data », Networking, Architecture, and Storage, 2009. NAS 2009. IEEE International Conference on,‎ 9-11 juillet 2009, p. 111-108 (ISBN 978-0-7695-3741-2, DOI 10.1109/NAS.2009.21)

• (en) Adam Barth, Collin Jackson et John C. Mitchell, « Robust Defenses for Cross-Site Request Forgery », CCS '08 Proceedings of the 15th ACM conference on Computer and communications security,‎ 2008, p. 75-88 (ISBN 978-1-59593-810-7, DOI 10.1145/1455770.1455782)

• (en) Mikhael Felker, « Browser Market Share », OWASP,‎ aout 2010 (lire en ligne)

• Portail d’Internet
• Portail de la sécurité informatique