Les codeurs conquièrent l'infrastructure de sécurité en tant que série de codes : protection insuffisante de la couche de transport

Si vous êtes développeur et souhaitez en savoir plus sur les étapes à suivre pour commencer à déployer une infrastructure sécurisée sous forme de code (IaC) dans votre organisation, vous êtes au bon endroit. Il s'agit du prochain chapitre de notre série IaC, conçue pour vous permettre de progresser en matière de meilleures pratiques en matière de sécurité IaC.

Avant de commencer, comment avez-vous relevé le défi du dernier épisode ? Si vous maîtrisez la cryptographie non sécurisée, voyons comment procéder si la protection de la couche de transport est insuffisante avant d'entrer dans les détails :

Vous voulez en savoir plus et obtenir un score parfait ? Lisez la suite :

Dans notre dernier article, nous avons parlé de l'importance de disposer d'une cryptographie sécurisée pour protéger toutes les données importantes ou personnelles stockées par des applications et des programmes. Si vous disposez d'un cryptage robuste, il constitue la dernière ligne de défense idéale. Même si un attaquant parvient à voler ces données, si elles sont fortement cryptées, les informations verrouillées dans ces fichiers sont toujours protégées.

La protection des données au repos n'est toutefois qu'une partie d'une défense complète des données. Chaque fois que des utilisateurs valides ont besoin d'accéder à des données protégées, celles-ci doivent leur être envoyées. Parfois, les applications partagent également des données avec d'autres programmes dans le cadre d'une charge de travail globale. À moins que la couche de transport ne soit protégée, elle la rend vulnérable à la fois à l'espionnage extérieur et à la visualisation interne non autorisée. Par conséquent, une protection insuffisante de la couche de transport peut entraîner de graves problèmes.

C'est un problème courant. L'organisation de sécurité OWASP tient même une page complète sur protection insuffisante de la couche de transport.

Pourquoi une protection insuffisante de la couche de transport est-elle dangereuse ?

Si vous ne protégez pas suffisamment vos couches de transport, il est relativement facile pour les pirates informatiques expérimentés d'intercepter les informations circulant entre vos utilisateurs et vos applications à l'aide de techniques telles que les attaques de type man-in-the-middle. L'aspect le plus dangereux de ce type d'espionnage est probablement qu'il est presque totalement invisible pour les plateformes de cybersécurité internes ou les scans, car il se produit en dehors de votre réseau et de votre contrôle.

Par exemple, dans un environnement Docker déployant un service Nginx :

services :
nginx :
image : localhost:5000/scw_nginx
construire :. /nginx
secrets :
- nginx_cert
- clé_nginx
volumes :
- type : lien
source :. /nginx/nginx.conf
cible : /etc/nginx/nginx.conf
read_only : oui
ports :
- 80:8443
réseaux :
- interface
déployer :
restart_policy : *default-restart_policy
ressources : *default-resources_policy

La configuration du service Nginx ne chiffrera ni ne protégera la connexion, ce qui rend toutes les informations échangées via le lien vulnérables à diverses attaques ou à l'espionnage.

serveur {
nom_serveur scw-dev-blog.org ;
écoutez 8443 ;
ssl_protocols TLSv1.2 TLSv1.3 ;
ssl_ciphers EECDH+AESGCM : EDH+AESGCM ;
ssl_prefer_server_ciphers activé ;
certificat_SSL /run/secrets/nginx_cert ;
clé_de certificat ssl/run/secrets/nginx_key ;
access_log /dev/stdout ;
error_log /dev/stderr ;
lieu/{
proxy_pass http://wordpress:8080 ;
proxy_set_header Hôte $http_host ;
proxy_set_header X-Forwarded-Host $http_host ;
proxy_set_header X-Real-IP $remote_addr ;
proxy_set_header X-Forwarded-Pour $proxy_add_x_forwarded_for ;
proxy_set_header X-Forwarded-Proto $scheme ;
}
}

Souvent, le premier signal indiquant que quelqu'un est en train de fouiner dans vos couches de transport est l'utilisation d'un grand nombre de mots de passe utilisateur volés lors d'attaques ultérieures. Si d'autres données telles que les informations sur les clients, les dossiers financiers ou d'importants secrets d'entreprise sont volées via une couche de transport non sécurisée, vous ne vous rendrez peut-être jamais compte que vous avez été compromise.

Et ce n'est pas seulement la couche de transport entre les utilisateurs et les applications qui doit être protégée. Sur le backend, de nombreuses applications communiquent entre elles et avec des serveurs situés plus loin dans la chaîne de flux de travail. Bien que ces communications internes ne soient généralement pas vulnérables à l'espionnage externe, elles peuvent exposer des données à des utilisateurs autorisés à accéder au réseau mais non autorisés à consulter certaines informations hautement protégées ou sensibles.

Sécurisation adéquate des couches de transport pour une protection totale des données

Il est préférable de protéger les couches de transport pendant la création des applications. Ce processus commence par la mise en place d'une infrastructure backend sécurisée. Pour les sites Web, tout doit être fait en HTTPS. Ne mélangez jamais les infrastructures HTTP et HTTPS. Vous devriez même configurer vos sites pour qu'ils acheminent automatiquement les requêtes HTTP non sécurisées vers l'infrastructure HTTPS.

Dans l'exemple ci-dessus, une méthode appropriée pour protéger la couche de transport serait la suivante :

serveur {
nom_serveur scw-dev-blog.org ;
écoutez 8443 ssl ;
ssl_protocols TLSv1.2 TLSv1.3 ;
ssl_ciphers EECDH+AESGCM : EDH+AESGCM ;
ssl_prefer_server_ciphers activé ;
certificat_SSL /run/secrets/nginx_cert ;
clé_de certificat ssl/run/secrets/nginx_key ;
access_log /dev/stdout ;
error_log /dev/stderr ;
lieu/{
proxy_pass http://wordpress:8080 ;
proxy_set_header Hôte $http_host ;
proxy_set_header X-Forwarded-Host $http_host ;
proxy_set_header X-Real-IP $remote_addr ;
proxy_set_header X-Forwarded-Pour $proxy_add_x_forwarded_for ;
proxy_set_header X-Forwarded-Proto $scheme ;
}
}

Dans cet exemple, toutes les connexions avec le service Nginx sont fortement cryptées. La section serveur de la configuration Nginx inclut uniquement écoutez 8443 ssl afin de forcer le protocole SSL à protéger les connexions.

Pour protéger vos données contre les menaces internes, les développeurs doivent utiliser un protocole de chiffrement robuste de la couche transport tel que TLS 1.2. Une fois que vous avez mis en place le protocole TLS 1.2 ou son équivalent, les protocoles les plus faibles tels que SSL v2 devraient être complètement supprimés de votre infrastructure et automatiquement interdits d'utilisation.

Et gardez toujours à l'esprit que la sécurisation d'une application n'est pas complète tant que les données au repos et les couches de transport ne sont pas suffisamment protégées. Vous pouvez ainsi garantir une protection complète de bout en bout des données, à la fois en interne et lorsqu'elles sont transmises à des utilisateurs externes autorisés.
Consultez le Secure Code Warrior pages de blog pour en savoir plus sur cette vulnérabilité et sur la manière de protéger votre organisation et vos clients des ravages causés par d'autres failles de sécurité. Vous pouvez également essayez une démo de la plateforme de formation Secure Code Warrior pour maintenir toutes vos compétences en cybersécurité à jour et à jour.