Chromium Chronicle n°5: coder en dehors du bac à sable

Épisode 5:d'Ade à Mountain View, en Californie (août 2019)
Épisodes précédents

Chrome est divisé en processus. Certaines d'entre elles sont en bac à sable, ce qui signifie qu'elles ont un accès limité au système et aux comptes des utilisateurs. Dans un processus en bac à sable, les bugs qui permettent l'exécution de code malveillant sont bien moins graves.

Le processus du navigateur n'a pas de bac à sable. Un bug peut donc accorder à un code malveillant un accès complet à l'ensemble de l'appareil. Que devez-vous faire différemment ? Et quelle est la situation avec les autres processus ?

Schéma du bac à sable

Tout le code comporte des bugs. Dans le processus du navigateur, ces bugs permettent à du code malveillant d'installer un programme, de voler les données des utilisateurs, d'ajuster les paramètres de l'ordinateur, d'accéder au contenu de tous les onglets du navigateur, d'accéder aux données de connexion, etc.

Dans d'autres processus, l'accès au système d'exploitation est limité par des restrictions spécifiques à la plate-forme. Pour plus d'informations, consultez le Guide de mise en œuvre du bac à sable dans Chrome.

Veillez à éviter les erreurs courantes suivantes:

règle des deux

  • N'analysez pas et n'interprétez pas les données non fiables à l'aide de C++ dans le processus du navigateur.
  • Méfiez-vous de l'origine qu'un moteur de rendu prétend représenter. L'élément RenderFrameHost du navigateur permet d'obtenir l'origine actuelle de manière sécurisée.


À faire

Appliquez plutôt les bonnes pratiques suivantes:

  • Soyez particulièrement parano si votre code est dans le processus du navigateur.
  • Valider tous les IPC des autres processus. Supposons que tous les autres processus soient déjà compromis et prêts à vous tromper.
  • Effectuez le traitement dans un processus de moteur de rendu ou utilitaire, ou dans un autre processus en bac à sable. Idéalement, utilisez également un langage à mémoire sécurisée tel que JavaScript (qui résout plus de 50% des bugs de sécurité).

Pendant des années, nous avons exécuté des piles réseau (par exemple, HTTP, DNS, QUIC) dans le processus du navigateur, ce qui a entraîné certaines failles de sécurité critiques. Sur certaines plates-formes, la mise en réseau dispose désormais de son propre processus, avec bientôt un bac à sable.

Autres ressources

  • Règle de deux selon Chromium: pas plus de deux avec des données non sécurisées, du code non sécurisé et des processus non sécurisés.
  • Validation des données IPC: guide sur la façon de s'assurer que les IPC du processus de rendu ne sont pas remplis de fib et de déclarations trompeuses ou déceptives.