Vulnérabilité des services d'authentification web

Un article de Wikipédia, l'encyclopédie libre.
Aller à : navigation, rechercher

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.

Vulnérabilités des techniques d'authentification[modifier | modifier le code]

Introduction aux protocoles d'authentification[modifier | modifier le code]

Article principal : authentification.

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].

Authentification HTTP[modifier | modifier le code]

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.

HTTP Basic[modifier | modifier le code]

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].

HTTP Digest[modifier | modifier le code]

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].

Attaque par hameçonnage[modifier | modifier le code]

Article détaillé : Hameçonnage.

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 et 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].

Authentification par cookies[modifier | modifier le code]

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].

Vol de cookies[modifier | modifier le code]

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].

Fixation de session[modifier | modifier le code]

Principe d'une attaque par fixation de session
Article détaillé : Fixation de session.

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].

Injections de requêtes illégitimes par rebond[Note 8][modifier | modifier le code]

Article détaillé : Cross-Site Request Forgery.

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].

Authentification HTTPS[modifier | modifier le code]

L'attaque proposée par Marlinspike contre SSL

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].

Vulnérabilités des navigateurs[modifier | modifier le code]

Gestionnaire de mot de passe[modifier | modifier le code]

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’elle 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.

Firefox[modifier | modifier le code]

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[modifier | modifier le code]

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[modifier | modifier le code]

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].

Attaque de l'homme dans le navigateur[modifier | modifier le code]

Attaque contre les navigateurs MITB (Man-in-the-Browser)

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].

Notes et références[modifier | modifier le code]

Notes[modifier | modifier le code]

  1. SSL pour Secure Sockets Layer Protocol
  2. HTTP pour Hypertext Transfer Protocol
  3. Phishing en anglais
  4. Pharming en anglais
  5. DNS pour Domain Name System
  6. TLS pour Transport Layer Security
  7. SID pour Session ID
  8. CSRF pour Cross-Site Request Forgery
  9. URL pour Uniform Resource Locator
  10. HTTPS pour HyperText Transfer Protocol Secure
  11. MITB pour Man-in-the-Browser

Références[modifier | modifier le code]

Bibliographie[modifier | modifier le code]

  • (en) Chomsiri, T., « HTTPS Hacking Protection », Advanced Information Networking and Applications Workshops, 2007, AINAW '07. 21st International Conference on, vol. 1,‎ , 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,‎ , 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, no 6,‎ , 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,‎ , 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, no 10,‎ , 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,‎ , p. 229 - 234 (ISBN 978-1-4673-2640-7, DOI 10.1109/CICSyN.2012.50)
  • (en) Nagarajan, V. et Huang, Dijiang., « Improving Secure Server Performance by EAMRSA SSL Handshakes », Industrial Control and Electronics Engineering (ICICEE), 2012 International Conference on,‎ , 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,‎ , 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,‎ , 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,‎ , 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,‎ , 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,‎ , 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, no 1,‎ (ISSN 1533-5399, DOI 10.1145/1294148.1294153)
  • Guillaume, HARRY, « Failles de sécurité des applications Web », (TOIT), vol. 1.3,‎ , p. 18
  • (en) Yutaka, Oiwa, Hajime, Watanabe et Hiromitsu, Takagi, « PAKE-based mutual HTTP authentication for preventing phishing attacks », ACM,‎ , 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, no 3,‎ (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),‎ , p. 18
  • (en) Johns, Martin, Lekies, Sebastian, Braun, Bastian et Fiesch, Benjamin, « BetterAuth: Web Authentication Revisited », Proceedings of the 28th Annual Computer Security Applications Conference,‎ , p. 169-178 (ISBN 978-1-4503-1312-4, DOI 10.1145/2420950.2420977)
  • (en) Darwish, A. et Bataineh, E., « Eye tracking analysis of browser security indicators », International Conference on Computer Systems and Industrial Informatics (ICCSII),‎ , 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,‎ (lire en ligne)
  • (en) Gasti, Paolo et B. Rasmussen, Kasper, « On The Security of Password Manager Database Formats », Lecture Notes in Computer Science, vol. 7459,‎ , 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,‎ , p. 449-464 (ISBN 978-1-931971-15-7)
  • (en) « Protect your synced data », Google,‎ (lire en ligne)
  • « Recommandations de sécurité relatives aux mots de passe », Agence nationale de la sécurité des systèmes d’information,‎ , 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,‎ , 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,‎ , p. 495–506 (ISBN 978-3-540-77047-3)
  • (en) P. Burkholder, « “SSL Man-in-the-Middle Attacks”, SANS Institue InfoSec Reading », ., vol. .,‎ (lire en ligne)
  • (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),‎ , p. 271-276 (ISBN 978-1-4673-1425-1, DOI 10.1109/CyberSec.2012.6246086)
  • « Mitigating Cross-site Scripting With HTTP-only Cookies », MSDN,‎ (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,‎ , 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,‎ , 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,‎ , 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,‎ (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,‎ (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,‎ (lire en ligne)
  • (en) V. Torvinen, J. Arkko et M. Naslund, « HTTP Authentication: Basic and Digest Access Authentication », Internet Engineering Task Force,‎ (lire en ligne)
  • (en) A. Freier, P. Karlton et P. Kocher, « The Secure Sockets Layer (SSL) Protocol Version 3.0 », Internet Engineering Task Force,‎ (lire en ligne)
  • (en) E. Rescorla, « HTTP Over TLS », Internet Engineering Task Force,‎ (lire en ligne)
  • (en) Moxie Marlinspike, « New Tricks For Defeating SSL In Practice », www.blackhat.com,‎ (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,‎ , 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,‎ , p. 75-88 (ISBN 978-1-59593-810-7, DOI 10.1145/1455770.1455782)
  • (en) Mikhael Felker, « Browser Market Share », OWASP,‎ (lire en ligne)