Fonctionnement des navigateurs - introduction à la sécurité des applications Web

Commençons une série d'articles sur la sécurité des applications Web avec une explication de ce que font les navigateurs et comment ils le font. Étant donné que la plupart de vos clients interagiront avec votre application Web via des navigateurs, vous devez comprendre les bases du fonctionnement de ces excellents programmes.


Chrome et lynx

Un navigateur est un moteur de rendu . Son travail consiste à télécharger une page Web et à la présenter d'une manière lisible par l'homme.

Bien que ce soit presque une simplification criminelle, mais pour l'instant, c'est tout ce que nous devons savoir pour le moment.

• L'utilisateur entre l'adresse dans la ligne de saisie du navigateur.
• Le navigateur télécharge le «document» à cette URL et l'affiche.

Vous pouvez être habitué à travailler avec l'un des navigateurs les plus populaires tels que Chrome, Firefox, Edge ou Safari, mais cela ne signifie pas qu'il n'y a pas d'autres navigateurs dans le monde.

Par exemple, lynx est un navigateur de texte en ligne de commande léger. Au cœur de lynx se trouvent les mêmes principes que vous trouverez dans tous les autres navigateurs grand public. L'utilisateur entre une adresse Web (URL), le navigateur télécharge le document et l'affiche - la seule différence est que lynx n'utilise pas le moteur de rendu graphique, mais l'interface de texte, grâce à laquelle des sites comme Google ressemblent à ceci:



En général, nous avons une idée de ce que fait le navigateur, mais regardons de plus près les actions que ces applications ingénieuses effectuent pour nous.

Que fait le navigateur?

En bref, le navigateur se compose essentiellement de

• Résolution DNS
• Échange HTTP
• Rendu
• Réinitialiser et répéter

Résolution DNS

Ce processus aide le navigateur à savoir à quel serveur il doit se connecter lorsqu'un utilisateur saisit une URL. Le navigateur contacte le serveur DNS et détecte que google.com correspond à l'ensemble des chiffres 216.58.207.110 - l'adresse IP à laquelle le navigateur peut se connecter.

Échange HTTP

Dès que le navigateur détermine quel serveur servira notre demande, il établira une connexion TCP avec lui et commencera l' échange HTTP . Ce n'est rien d'autre qu'un moyen de communication entre le navigateur et le serveur dont il a besoin, et pour le serveur, c'est le moyen de répondre aux demandes du navigateur.

HTTP est simplement le nom du protocole le plus populaire pour communiquer sur le réseau, et les navigateurs choisissent principalement HTTP pour communiquer avec les serveurs. L'échange HTTP implique que le client (notre navigateur) envoie une demande et que le serveur envoie une réponse .

Par exemple, une fois que le navigateur s'est connecté avec succès au serveur desservant google.com , il envoie une demande qui ressemble à ceci.

GET / HTTP/1.1
Host: google.com
Accept

Analysons la requête ligne par ligne:

• GET / HTTP / 1.1 : sur cette première ligne, le navigateur demande au serveur de récupérer le document depuis l'emplacement / , ajoutant ensuite que le reste de la requête se fera via HTTP / 1.1 (ou vous pouvez également utiliser la version 1.0 ou 2)
• Hôte: google.com : il s'agit du seul en-tête HTTP requis pour le protocole HTTP / 1.1 . Étant donné que le serveur peut desservir plusieurs domaines (google.com, google.co.uk , etc.), le client mentionne ici que la demande visait cet hôte particulier.
• Accepter: * / * : un en-tête facultatif dans lequel le navigateur indique au serveur qu'il acceptera toute réponse. Le serveur peut avoir une ressource disponible en JSON, XML ou HTML, il peut donc choisir n'importe quel format qu'il préfère

Une fois que le navigateur agissant en tant que client a terminé sa demande, le serveur envoie une réponse. Voici la réponse:

 HTTP/1.1 200 OK Cache-Control: private, max-age=0 Content-Type: text/html; charset=ISO-8859-1 Server: gws X-XSS-Protection: 1; mode=block X-Frame-Options: SAMEORIGIN Set-Cookie: NID=1234; expires=Fri, 18-Jan-2019 18:25:04 GMT; path=/; domain=.google.com; HttpOnly <!doctype html><html"> ... ... </html> 

Wow, cette fois, beaucoup d'informations qui doivent être digérées. Le serveur nous indique que la demande a réussi ( 200 OK ) et ajoute plusieurs en-têtes à la réponse , par exemple, vous pouvez savoir quel serveur a traité notre demande ( serveur: gws ), quelle est la politique de protection X-XSS pour cette réponse, etc. plus loin et similaires.

Pour l'instant, vous n'avez pas besoin de comprendre chaque ligne de la réponse. Plus loin dans cette série de publications, nous parlerons davantage du protocole HTTP, de ses en-têtes, etc.

Pour le moment, tout ce que vous devez savoir, c'est que le client et le serveur échangent des informations et qu'ils le font via le protocole HTTP.

Rendu

Enfin, le processus de rendu est en cours. Quelle est la qualité du navigateur si la seule chose qu'il montre à l'utilisateur est une liste de personnages amusants?

 <!doctype html><html"> ... ... </html> 

Dans le corps de la réponse, le serveur inclut la présentation du document demandé conformément à l'en - tête Content-Type . Dans notre cas, le type de contenu a été défini sur text / html , nous nous attendons donc à un balisage HTML dans la réponse - et c'est ce que nous trouvons dans le corps du document.

C'est exactement le moment où le navigateur montre vraiment ses capacités. Il lit et analyse le code HTML, charge les ressources supplémentaires incluses dans le balisage (par exemple, les fichiers JavaScript ou les documents CSS peuvent y être spécifiés pour le chargement) et les présente à l'utilisateur dès que possible.

Encore une fois, le résultat final devrait être ce qui est accessible au Vasya moyen.



Si vous avez besoin d'une explication plus détaillée de ce qui se passe réellement lorsque nous appuyons sur la touche Entrée dans la barre d'adresse du navigateur, je vous suggère de lire l'article "Que se passe-t-il quand ..." , une tentative très méticuleuse d'expliquer les mécanismes qui sous-tendent ce processus.

Étant donné que cette série est dédiée à la sécurité, je vais donner un indice sur ce que nous venons de découvrir: les attaquants vivent facilement des vulnérabilités en termes d'échange HTTP et de rendu . Des vulnérabilités, des utilisateurs malveillants et d'autres créatures fantastiques se trouvent ailleurs, mais une approche plus efficace pour fournir une protection aux niveaux mentionnés vous permet déjà de réussir à améliorer votre état de sécurité.

Vendeurs

Les 4 navigateurs les plus populaires appartiennent à différents fournisseurs:

• Google Chrome
• Firefox par Mozilla
• Apple Safari
• Microsoft Edge

En plus de se battre pour accroître leur pénétration du marché, les fournisseurs interagissent également entre eux pour améliorer les normes Web, qui sont une sorte d '«exigences minimales» pour les navigateurs.

Le W3C est la pierre angulaire du développement des normes, mais les navigateurs développent souvent leurs propres fonctions, qui finissent par devenir des normes Web, et la sécurité ne fait pas exception.

Par exemple, les cookies SameSite ont été introduits dans Chrome 51, une fonctionnalité qui a permis aux applications Web de se débarrasser d'un certain type de vulnérabilité connue sous le nom de CSRF (plus à ce sujet plus tard). D'autres fabricants ont décidé que c'était une bonne idée et ont emboîté le pas, ce qui a conduit l'approche SameSite à devenir la norme Web: Safari est actuellement le seul navigateur majeur qui ne prend pas en charge les cookies SameSite .



Cela nous dit deux choses:

• Safari ne semble pas se soucier suffisamment de la sécurité de ses utilisateurs (je plaisante: les cookies SameSite seront disponibles dans Safari 12, qui ont peut-être déjà été publiés au moment de la lecture de cet article)
• la correction des vulnérabilités dans un seul navigateur ne signifie pas que tous vos utilisateurs sont en sécurité

Le premier point est un tir sur Safari (comme je l'ai dit, je plaisante!), Et le deuxième point est vraiment important. Lors du développement d'applications Web, nous devons non seulement nous assurer qu'elles sont identiques dans différents navigateurs, mais également fournir la même protection à nos utilisateurs sur différentes plates-formes.

Votre stratégie de sécurité réseau doit varier en fonction des capacités que le fournisseur de navigateur nous offre. La plupart des navigateurs prennent actuellement en charge le même ensemble de fonctionnalités et s'écartent rarement de leur feuille de route globale, mais des cas comme celui ci-dessus se produisent toujours, et c'est quelque chose que nous devons considérer lors de la définition de notre stratégie de sécurité.

Dans notre cas, si nous décidons de ne neutraliser que les attaques CSRF avec les cookies SameSite, nous devons savoir que nous mettons en danger nos utilisateurs Safari. Et nos utilisateurs devraient également le savoir.

Et enfin et surtout, vous devez vous rappeler que vous pouvez décider de prendre en charge la version du navigateur ou non: la prise en charge de chaque version du navigateur ne sera pas pratique (n'oubliez pas Internet Explorer 6). Malgré cela, une prise en charge sûre de plusieurs versions récentes des principaux navigateurs est généralement une bonne solution. Cependant, si vous ne prévoyez pas de fournir de protection sur une plate-forme particulière, il est fortement conseillé que vos utilisateurs en soient informés.

Astuce pour les pros : vous ne devez jamais encourager vos utilisateurs à utiliser des navigateurs obsolètes ou à les soutenir activement. Même si vous avez pris toutes les précautions nécessaires, d'autres développeurs Web ne l'ont pas fait. Encouragez les utilisateurs à utiliser la dernière version prise en charge de l'un de leurs principaux navigateurs.

Vendeur ou bug standard?

Le fait qu'un utilisateur régulier accède à notre application à l'aide d'un logiciel client tiers (navigateur) ajoute un autre niveau qui complique le chemin vers une navigation Web pratique et sûre: le navigateur lui-même peut être une source de vulnérabilité de sécurité.

Les fournisseurs fournissent généralement des récompenses (également connues sous le nom de primes de bogues) aux chercheurs en sécurité qui peuvent rechercher des vulnérabilités dans le navigateur lui-même. Ces erreurs ne sont pas liées à votre application Web, mais à la façon dont le navigateur gère indépendamment la sécurité.

Par exemple, le programme de récompenses Chrome permet aux chercheurs en sécurité de contacter l'équipe de sécurité Chrome pour signaler les vulnérabilités qu'ils ont découvertes. Si le fait de la vulnérabilité est confirmé, un correctif sera émis et, en règle générale, un avis de sécurité sera publié et le chercheur recevra une récompense (généralement financière) du programme.

Des entreprises comme Google ont investi beaucoup de capitaux dans leurs programmes Bug Bounty, car cela leur permet d'attirer de nombreux chercheurs, leur promettant des avantages financiers en cas de problème avec le logiciel testé.

Tout le monde gagne le programme Bug Bounty: le fournisseur parvient à augmenter la sécurité de son logiciel et les chercheurs sont payés pour leurs découvertes. Nous discuterons de ces programmes plus tard, car je pense que les initiatives de Bug Bounty méritent une section distincte dans le paysage de la sécurité.

Jake Archibald est un avocat de Google qui a découvert une vulnérabilité affectant plusieurs navigateurs. Il a documenté ses efforts pour le détecter, le processus de contact avec les différents fournisseurs affectés par la vulnérabilité et la réaction des représentants des fournisseurs dans un article de blog intéressant , que je vous recommande de lire.

Navigateur développeur

A ce jour, nous aurions dû comprendre un concept très simple mais assez important: les navigateurs ne sont que des clients HTTP créés pour un internaute «moyen».

Les navigateurs sont certainement plus puissants qu'un simple client HTTP pour n'importe quelle plateforme (par exemple, rappelez-vous que NodeJS a une dépendance sur 'http'), mais, en fin de compte, ils ne sont "que" le produit de l'évolution naturelle de clients HTTP plus simples.

Quant aux développeurs, notre client HTTP est probablement cURL par Daniel Stenberg, l'un des programmes les plus populaires que les développeurs Web utilisent quotidiennement. Il nous permet d'effectuer un échange HTTP à la volée en envoyant une requête HTTP depuis notre ligne de commande:

 $ curl -I localhost:8080 HTTP/1.1 200 OK server: ecstatic-2.2.1 Content-Type: text/html etag: "23724049-4096-"2018-07-20T11:20:35.526Z"" last-modified: Fri, 20 Jul 2018 11:20:35 GMT cache-control: max-age=3600 Date: Fri, 20 Jul 2018 11:21:02 GMT Connection: keep-alive 

Dans l'exemple ci-dessus, nous avons demandé un document sur localhost: 8080 / et le serveur local y a répondu avec succès.

Au lieu de décharger le corps de la réponse sur la ligne de commande, nous avons utilisé l'indicateur -I , qui indique à cURL que nous ne sommes intéressés que par les en-têtes de réponse. Pour aller plus loin, nous pouvons donner à la commande cURL un peu plus d'informations, y compris la demande réelle qu'elle exécute, afin que nous puissions mieux examiner tout cet échange HTTP. L'option que nous devrions utiliser: -v ( verbeux , plus):

 $ curl -I -v localhost:8080 * Rebuilt URL to: localhost:8080/ * Trying 127.0.0.1... * Connected to localhost (127.0.0.1) port 8080 (#0) > HEAD / HTTP/1.1 > Host: localhost:8080 > User-Agent: curl/7.47.0 > Accept: */* > < HTTP/1.1 200 OK HTTP/1.1 200 OK < server: ecstatic-2.2.1 server: ecstatic-2.2.1 < Content-Type: text/html Content-Type: text/html < etag: "23724049-4096-"2018-07-20T11:20:35.526Z"" etag: "23724049-4096-"2018-07-20T11:20:35.526Z"" < last-modified: Fri, 20 Jul 2018 11:20:35 GMT last-modified: Fri, 20 Jul 2018 11:20:35 GMT < cache-control: max-age=3600 cache-control: max-age=3600 < Date: Fri, 20 Jul 2018 11:25:55 GMT Date: Fri, 20 Jul 2018 11:25:55 GMT < Connection: keep-alive Connection: keep-alive < * Connection #0 to host localhost left intact 

Les mêmes informations sont disponibles dans les navigateurs courants via leurs DevTools.

Comme nous l'avons vu, les navigateurs ne sont rien de plus que des clients HTTP sophistiqués. Bien sûr, ils ajoutent un grand nombre de fonctions (par exemple, gestion des informations d'identification, bookmarking, historique, etc.), mais la vérité est qu'ils sont nés en tant que clients HTTP pour les gens. Ceci est important, car dans la plupart des cas, vous n'avez pas besoin d'un navigateur pour vérifier la sécurité de votre application Web, quand vous pouvez simplement le «fumer» et regarder la réponse.

Et la dernière chose que je voudrais noter: le navigateur peut être n'importe quoi. Si vous avez une application mobile qui utilise des API via HTTP, alors cette application est votre navigateur - elle est simplement configurée par vous sur une commande individuelle, qui ne reconnaît qu'un certain type de réponses HTTP (à partir de votre propre API).

Plongée HTTP

Comme nous l'avons déjà mentionné, nous allons couvrir les phases d' échange HTTP et de rendu dans les moindres détails, car ce sont elles qui fournissent le plus grand nombre de vecteurs d'attaque aux attaquants.

Dans le prochain article, nous allons examiner de plus près le protocole HTTP et essayer de comprendre quelles mesures nous devons prendre pour garantir la sécurité des échanges HTTP.

---

La traduction a été prise en charge par EDISON Software , une société professionnelle de développement de sites Web pour les gros clients, ainsi que par le développement Web C # et .NET .