Analyse sécurité Web Interne

Quels sont les biens à protéger?

• Le lien avec la DB
• Les données utilisateurs
• Les accès administrateur
• La disponibilité

Quelles sont leurs vulnérabilités et les menaces qui en découlent?

• La récupération des échanges
• Lecture des informations échangées
• Des requêtes non autorisées (injection SQL, tentative d'attaque, ...)

Pour chaque menace, quels sont les risques associés ? Risque = probabilité d’occurrence de la menace x impact de la menace

probablilités

• La récupération des échanges: haute. Sans sécurité, il est très facile de récupérer n'importe quel échange avec le serveur via une stratégie de man in the middle
• Lecture des informations échangées: haute. Sans sécurité, un outil simple comme wireshark permettrait de lire le contenu d'un échange
• Des requêtes non autorisées (injection SQL, tentative d'attaque, ...): moyenne. La probabilité d'injection SQL dépend du site web en lui-même, que nous ne gérons pas. Mais le serveur reste vulnérable à des attaques telles que DoS.

Impact

• La récupération des échanges: fort. Récuperer les échanges avec le serveur permettrait de savoir qui s'y connecte et constitue un risque pour les utilisateurs
• Lecture des informations échangées: fort. Sans sécurité, il serait possible de lire les identifiants/mots de passes lors d'une connexion ou encore lire en clair le contenu renvoyé par la DB.
• Des requêtes non autorisées (injection SQL, tentative d'attaque, ...): moyen. Le type de requêtes qui pourrait être effectuée sur la DB par injection dépend à nouveau de l'implémentation de l'API des pages webs en elles-mêmes. Cepandant une attaque visant a rendre le serveur indisponible couperait le site b2b et donc toute possibilité de transaction avec les entreprises clientes. Cela aurait également une conséquence sur la DB, liée au site web.

Classer les menaces en fonction du risque

Menace	Probabilité	Impact	Risque	Contre-mesure
Lecture des informations échangées	Haute	Fort	Fort	https
La récupération des échanges	Haute	Fort	Fort	https
Des requêtes non autorisées	Moyenne	Moyen	Moyen	reverse-proxy

Identifier les contre-mesures

• La récupération des échanges: HTTPS. Grace aux échanges TLS, les échanges seront sécurisés et irrécupérable par une méthode de man in the middle.

• Lecture des informations échangées: HTTPS. Les données envoyées peuvent être chiffrées avec HTTPS, ce qui les rendra illisible par quiconque accèderait aux échanges.

• Des requêtes non autorisées (injection SQL, tentative d'attaque, ...): La technique la plus répandure pour lutter contre ce type de vulnérabilité est un serveur reverse-proxy, dont le role est de servire de "ligne de front" à toute requête se dirigeant vers le serveur web. Il faudra le configurer pour qu'il reconnaisse les attaques telles que DoS ou injection SQL

• Outil de sécurité important pour toutes situation: Les logs. Il est important de garder un historique des échanges, tentatives de connexion et du trafic général pour pouvoir réagir en cas d'incident

Mettre en place les contre-mesures

[1] La mise en place de https demanderait:

• En premier lieu l'obtention d'un certificat fournit par une autorité de certification. C'est ce qui permet de chiffrer les échanges avec le serveur et authentifier le serveur auprès d'une autorité d'authentification.
• Installer le certificat dans le serveur nginx, cela peut se faire automatiquement via certains logiciels, qui modifient directement la config du serveur, ou cela peut se faire manuellement.
• Modifier les liens et les numéro de ports vers https/443. On peut modifier les numéro de port directement ou effectuer une redirection du port 80 vers 443

Documenter les risques résiduels

Erreur humaine

Si qqun le veut vraiment, il y arrivera toujour

Assurer la maintenance (plan de suivi, monitoring, stratégies de réaction/mitigation, …)

Un moyen de monitorer le trafic sur le site

un backup dans le cloud/ en physique a un autre endroit dans l'entreprise

Implémentation de l'HTTPS sur le serveur web public (par Tatiana Saragossi):

J'ai rencontré plusieurs problèmes lorsque j'ai essayé d'implémenter la sécurité HTTPS. Je me suis d'abord tournée vers ZéroSSL pour l'obtention du certificat. J'ai suivi les indications jusqu'à ce qu'on me demande de vérifier le domaine.

J'ai d'abord utiliser la vérification par record DNS où m'as demander d'injecter les données suivantes dans le fichier de zone du SOA public.

Malheureusement, j'obtenais sans arrêt cette erreur:

J'ai ensuite essayer la vérification via le HTTP File Upload. Cependant, cela n'a rien donné non plus...

Finalement le problème venait du fait qu'il n'y avait pas de points au bout du nom et au bout du CNAME. En effet sans le point, il ne partait pas de la racine pour joindre notre domaine, ce qui l'empochait de le joindre.

J'ai enfin pu vérifier mon domaine, ce qui m'a permit de recevoir le certificat et la clef privé:

Après l'avoir installé sur le serveur en suivant les indications de ZéroSSL, il m'as finalement affiché que le certificat n'était pas valide. Cela est sans doute dû au fait que le certificat est auto-signé et qu'il n'est donc pas validé par une autorité parente.

Cependant le certificat est visible dans un navigateur:

Il est également valide d'après Zéro SSL:

J'ai donc essayer d'installer certbot dans le but d'obtenir un certificat valide. L'installation via le Dockerfile n'a rien donné, il ne reconnaissait jamais la commande Cerbot. J'ai donc tapé la commande sudo docker exec -it woodytoys_webpub_1 certbot certonly --webroot -w /etc/ssl -d m2-1.ephec-ti.be.

Elle posé 2 problèmes: Tout d'abord, cela nous a empêcher d'accéder au site :

Ensuite, la commande a provoqué l'erreur suivante alors que les recods sont valides:

Je n'ai donc pas réussi à générer un certificat valide selon le navigateur même s'il est valide selon ZéroSSL puisque ce dernier me l'a délivré.

[1] https://www.keycdn.com/blog/http-to-https