Learning by Doing.
Un monde en cybersécurité

Chapitre 6
Defend the web
Indices supplementaires :
Indice 1 : <!-- Write your comments here -->
Indice 2 : C'est une question du style
Indice 3 : Il est ou javascript il est ou? il est la… dans le code
Indice 4 : https://cyberstudydb.000webhostapp.com/filelink.html
Indice 5 : javascript encore
Indice 6 : value=
Indice 6 : add what is missing
Indice 7 : encore un fichier
Indice 8 : binary
Indice 9 : Recover password by e-mail
Indice 10 : hex
Indice 11 : javascript
Indice 12 : hash function
On voit bien qu'avec le code. L'essentiel est invisible pour les yeux.
Vous avez réussi les défis, mais qu’est ce que ces défis essaient d’illustrer ?
Intro 1
Intro 1 vous montre que le code source d’une page web est facilement accessible. N’importe qui peut donc ouvrir et analyser la page et cela vaut pour le code interprété (affiché dans le navigateur et visible sur l’interface) comme pour le code non interprété, comme, par exemple, les commentaires. Les développeurs doivent éviter de laisser des informations sensibles, comme les codes d’accès tests ou administrateurs, les clés de chiffrement dans le code. Aussi, les commentaires dans le code peuvent fournir des indices sur les versions des bibliothèques ou des plateformes utilisées et donc sur les failles exploitables. Pour éviter la fuite de données par commentaires, il est commun de supprimer tous les commentaires avant le passage en production. Cela est souvent automatique et peut être configuré avec des outils d’intégration continue, comme Jenkins.
Intro 2
Il est plus compliqué de desceller les fuites d’information qui sont cachées dans le code interprété. À la différence des commentaires qui sont faciles à identifier avec <!-- --> automatiquement, un outil ne peut pas comprendre si un texte est visible et si cela est prévu par le développeur. Pour éviter ce type d’erreur, il est conseillé de mettre en place une pratique de relecture du code dans l’équipe. Chaque fois qu’un développeur finalise une tache, il demande à un de ses collègues de venir à son poste de travail et de relire son code. Le collègue va donc se familiariser avec le code ce qui permettra de le reprendre en main plus facilement s’il doit le reprendre plus tard pour une autre tache. Il va également s’assurer que le code respecte les conventions de l’entreprise, qu’il ne contient pas d’erreurs et qu’il est compréhensible et commenté.
Intro 3
Le code JavaScript est aussi visible dans le code source de la page comme le code HTML. JavaScript est un langage « client » exécuté du côté client. Il n’est donc pas fait pour des vérifications de mots de passe ou d’autres données sensibles.
Intro 4
Les champs cachés ne sont par affichés dans l’interface, mais sont visibles dans le code source. Il ne faut pas utiliser les champs cachés pour garder des informations sensibles. Aussi, chaque ressource de serveur (fichier, dossier) est potentiellement accessible avec une URL. Si un utilisateur n’a pas de lien hypertexte disponible dans l’interface pour accéder à une ressource, il peut potentiellement y accéder en modifiant directement l’URL. Par exemple, supposé qu’un client a accès aux fichiers représentant ses factures. Il n’a pas accès aux factures d’autres clients via l’interface, mais il peut réussir à les voir en modifiant le numéro de la facture directement dans l’URL si le contrôle d’accès et les permissions sont mal configurées.
Intro 5
Les popups sont générés par le code JavaScript de la page. Ils ne sont donc pas faits pour assurer un contrôle d’accès.
Intro 6
N’importe quelle page web peut non seulement être consultée, mais peut aussi être modifiée par l’utilisateur. Le serveur ne fait donc jamais confiance au client en assumant que la page peut toujours changer. Les vérifications des accès doivent être effectuées du côté « serveur » et non en fonction des données renseignées sur la page. Le serveur doit toujours vérifier si les données qu’il a reçues du client sont fiables: bon nombre de variables, de la bonne taille, si c’est du texte et non du code, etc. Le code du côté client peut toujours être modifié.
Intro 7
Le fichier robots.txt existe sur tous les sites web et toujours au même endroit : à la racine du site. Ce fichier peut être exploré par les acteurs malveillants à la recherche d’indices.
Intro 8
L’encodage, à la différence du chiffrement, n’est pas un outil de sécurité, car il est facile de passer d’un type d’encodage à un autre. Par exemple, la table ASCII donne des bases permettant d’encoder les symboles en code binaire manipulé par la machine.
Intro 9
Comme indiqué précédemment, le serveur ne doit pas faire confiance aux données reçues de la part du client. Dans cet exercice, les données renseignées par le client sont comparées avec les données également reçues du client. La vérification doit plutôt avoir lieu sur le serveur, dans le fichier PHP directement.
Intro 10
Cet exercice fait référence à la pratique de sécurité par obscurité qui est, à priori, considérée comme une mauvaise pratique. On considère qu’un attaquant peut toujours connaitre les algorithmes ou les pratiques utilisées; essayer de les cacher ne permet par de protéger le système.
Néanmoins, l’obfuscation de code rend l’analyse plus complexe pour un attaquant et permet de le ralentir. Les outils d’intégration continue intègrent des fonctions d’obfuscation pour rendre le processus de rétro-ingénierie plus complexe et d’éviter le vol de code. L’obfuscation est souvent utilisée, par exemple, pour les applications Android, car la rétro-ingénierie sur les applications mobiles est plutôt facile.
Intro 11
JavaScript ne propose par de solution fiable pour empêcher un client d’accéder à une page web. L’exécution du JavaScript peut être interrompue par le client.
Intro 12
Cet exercice explique à la manière dont les mots de passe sont stockés dans une base de données — haché. Par contre, la fonction de hachage appliquée est une ancienne fonction qui n’est plus considérée comme fiable. Plus de détails seront fournis dans le chapitre suivant.