Blog

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

Matias Madou, Ph.D.
Publié le 01 juin 2020

Si vous êtes un développeur et que vous souhaitez en savoir plus sur les étapes à suivre pour commencer à déployer une infrastructure sécurisée sous forme de code (IaC) dans votre entreprise, vous êtes au bon endroit. Il s'agit du chapitre suivant de notre série sur l'IaC, conçue pour vous faire progresser dans les meilleures pratiques de sécurité de l'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 vous vous en sortez avec une protection de la couche transport insuffisante avant d'entrer dans les détails :

Vous voulez en savoir plus et obtenir une note parfaite ? 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 fort, il agit comme une dernière ligne de défense parfaite. Même si un pirate est en mesure de voler ces données, si elles sont fortement cryptées, les informations enfermé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. Lorsque 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. Si la couche transport n'est pas protégée, elle est vulnérable à la fois à l'espionnage extérieur et à la visualisation interne non autorisée. Ainsi, une protection insuffisante de la couche transport peut entraîner de graves problèmes.

Il s'agit d'un problème courant. L'organisation de sécurité OWASP consacre même une page entière à la 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 des pirates compétents 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 qu'il est presque totalement invisible pour les plateformes ou les analyses de cybersécurité internes, car il se produit en dehors de votre réseau et de votre contrôle.

Par exemple, dans un environnement Docker qui déploie un service Nginx, les pirates peuvent intercepter les informations qui circulent entre vos utilisateurs et vos applications :

services :
nginx :
image : localhost:5000/scw_nginx
build : ./nginx
secrets :
- nginx_cert
- nginx_key
volumes :
- type : bind
source : ./nginx/nginx.conf
target : /etc/nginx/nginx.conf
read_only : yes
ports :
- 80:8443
networks :
- frontend
deploy :
restart_policy : *default-restart_policy
resources : *politique_default-resources

La configuration du service Nginx ne crypte ni ne protège la connexion, ce qui rend toutes les informations échangées par le biais de la liaison vulnérables à diverses attaques ou à l'espionnage.

server {
       server_name scw-dev-blog.org;
       listen 8443;
       ssl_protocols TLSv1.2 TLSv1.3;
       ssl_ciphers EECDH+AESGCM:EDH+AESGCM;
       ssl_prefer_server_ciphers on;
       ssl_certificate /run/secrets/nginx_cert;
       ssl_certificate_key /run/secrets/nginx_key;
       access_log /dev/stdout;
       error_log /dev/stderr;
       location / {
           proxy_pass http://wordpress:8080;
           proxy_set_header Host $http_host;
           proxy_set_header X-Forwarded-Host $http_host;
           proxy_set_header X-Real-IP $remote_addr;
           proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
           proxy_set_header X-Forwarded-Proto $scheme;
       }
   }

Souvent, le premier signe que quelqu'un est en train d'espionner vos couches de transport est l'utilisation d'un grand nombre de mots de passe d'utilisateurs volés lors d'attaques ultérieures. Si d'autres données, telles que des informations sur les clients, des dossiers financiers ou des secrets d'entreprise importants, sont volées via une couche de transport non sécurisée, il se peut que vous ne vous rendiez même pas compte que vous avez été compromis.

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

Sécuriser correctement les couches de transport pour une protection totale des données

La meilleure façon de protéger les couches de transport est de le faire pendant la création des applications. Ce processus commence par la mise en place d'une infrastructure dorsale 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 de manière à ce que les requêtes HTTP non sécurisées soient automatiquement acheminées vers l'infrastructure HTTPS.

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

server {
       server_name scw-dev-blog.org;
       listen 8443 ssl;
       ssl_protocols TLSv1.2 TLSv1.3;
       ssl_ciphers EECDH+AESGCM:EDH+AESGCM;
       ssl_prefer_server_ciphers on;
       ssl_certificate /run/secrets/nginx_cert;
       ssl_certificate_key /run/secrets/nginx_key;
       access_log /dev/stdout;
       error_log /dev/stderr;
       location / {
           proxy_pass http://wordpress:8080;
           proxy_set_header Host $http_host;
           proxy_set_header X-Forwarded-Host $http_host;
           proxy_set_header X-Real-IP $remote_addr;
           proxy_set_header X-Forwarded-For $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 de Nginx n'inclut que listen 8443 ssl afin de forcer SSL à protéger les connexions.

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

N'oubliez jamais 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. De cette façon, vous pouvez garantir une protection complète de bout en bout des données, tant en interne que lorsqu'elles sont transmises à des utilisateurs externes autorisés.
Consultez les pages du Secure Code Warrior 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 essayer une démo de la plateforme de formation Secure Code Warrior pour maintenir vos compétences en cybersécurité à jour.

Voir la ressource
Voir la ressource

Parfois, les applications partagent également des données avec d'autres programmes dans le cadre d'une charge de travail globale. Si la couche transport n'est pas protégée, elle est vulnérable à la fois à l'espionnage extérieur et à la consultation interne non autorisée.

Vous souhaitez en savoir plus ?

Matias Madou est expert en sécurité, chercheur, directeur technique et cofondateur de Secure Code Warrior. Matias a obtenu son doctorat en sécurité des applications à l'université de Gand, en se concentrant sur les solutions d'analyse statique. Il a ensuite rejoint Fortify aux États-Unis, où il s'est rendu compte qu'il ne suffisait pas de détecter les problèmes de code sans aider les développeurs à écrire du code sécurisé. C'est ce qui l'a incité à développer des produits qui aident les développeurs, allègent le fardeau de la sécurité et dépassent les attentes des clients. Lorsqu'il n'est pas à son bureau en tant que membre de l'équipe Awesome, il aime être sur scène pour présenter des conférences, notamment RSA Conference, BlackHat et DefCon.

Secure Code Warrior est là pour vous aider à sécuriser le code tout au long du cycle de vie du développement logiciel et à créer une culture dans laquelle la cybersécurité est une priorité. Que vous soyez responsable AppSec, développeur, CISO ou toute autre personne impliquée dans la sécurité, nous pouvons aider votre organisation à réduire les risques associés à un code non sécurisé.

Réservez une démonstration
Partager sur :
Auteur
Matias Madou, Ph.D.
Publié le 01 juin 2020

Matias Madou est expert en sécurité, chercheur, directeur technique et cofondateur de Secure Code Warrior. Matias a obtenu son doctorat en sécurité des applications à l'université de Gand, en se concentrant sur les solutions d'analyse statique. Il a ensuite rejoint Fortify aux États-Unis, où il s'est rendu compte qu'il ne suffisait pas de détecter les problèmes de code sans aider les développeurs à écrire du code sécurisé. C'est ce qui l'a incité à développer des produits qui aident les développeurs, allègent le fardeau de la sécurité et dépassent les attentes des clients. Lorsqu'il n'est pas à son bureau en tant que membre de l'équipe Awesome, il aime être sur scène pour présenter des conférences, notamment RSA Conference, BlackHat et DefCon.

Matias est un chercheur et un développeur qui possède plus de 15 ans d'expérience pratique dans le domaine de la sécurité des logiciels. Il a développé des solutions pour des entreprises telles que Fortify Software et sa propre entreprise Sensei Security. Au cours de sa carrière, Matias a dirigé de nombreux projets de recherche sur la sécurité des applications qui ont débouché sur des produits commerciaux et peut se targuer d'avoir déposé plus de 10 brevets. Lorsqu'il n'est pas à son bureau, Matias a été instructeur pour des formations avancées en matière de sécurité des applications ( courses ) et intervient régulièrement lors de conférences mondiales telles que RSA Conference, Black Hat, DefCon, BSIMM, OWASP AppSec et BruCon.

Matias est titulaire d'un doctorat en ingénierie informatique de l'Université de Gand, où il a étudié la sécurité des applications par le biais de l'obscurcissement des programmes afin de dissimuler le fonctionnement interne d'une application.

Partager sur :

Si vous êtes un développeur et que vous souhaitez en savoir plus sur les étapes à suivre pour commencer à déployer une infrastructure sécurisée sous forme de code (IaC) dans votre entreprise, vous êtes au bon endroit. Il s'agit du chapitre suivant de notre série sur l'IaC, conçue pour vous faire progresser dans les meilleures pratiques de sécurité de l'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 vous vous en sortez avec une protection de la couche transport insuffisante avant d'entrer dans les détails :

Vous voulez en savoir plus et obtenir une note parfaite ? 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 fort, il agit comme une dernière ligne de défense parfaite. Même si un pirate est en mesure de voler ces données, si elles sont fortement cryptées, les informations enfermé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. Lorsque 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. Si la couche transport n'est pas protégée, elle est vulnérable à la fois à l'espionnage extérieur et à la visualisation interne non autorisée. Ainsi, une protection insuffisante de la couche transport peut entraîner de graves problèmes.

Il s'agit d'un problème courant. L'organisation de sécurité OWASP consacre même une page entière à la 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 des pirates compétents 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 qu'il est presque totalement invisible pour les plateformes ou les analyses de cybersécurité internes, car il se produit en dehors de votre réseau et de votre contrôle.

Par exemple, dans un environnement Docker qui déploie un service Nginx, les pirates peuvent intercepter les informations qui circulent entre vos utilisateurs et vos applications :

services :
nginx :
image : localhost:5000/scw_nginx
build : ./nginx
secrets :
- nginx_cert
- nginx_key
volumes :
- type : bind
source : ./nginx/nginx.conf
target : /etc/nginx/nginx.conf
read_only : yes
ports :
- 80:8443
networks :
- frontend
deploy :
restart_policy : *default-restart_policy
resources : *politique_default-resources

La configuration du service Nginx ne crypte ni ne protège la connexion, ce qui rend toutes les informations échangées par le biais de la liaison vulnérables à diverses attaques ou à l'espionnage.

server {
       server_name scw-dev-blog.org;
       listen 8443;
       ssl_protocols TLSv1.2 TLSv1.3;
       ssl_ciphers EECDH+AESGCM:EDH+AESGCM;
       ssl_prefer_server_ciphers on;
       ssl_certificate /run/secrets/nginx_cert;
       ssl_certificate_key /run/secrets/nginx_key;
       access_log /dev/stdout;
       error_log /dev/stderr;
       location / {
           proxy_pass http://wordpress:8080;
           proxy_set_header Host $http_host;
           proxy_set_header X-Forwarded-Host $http_host;
           proxy_set_header X-Real-IP $remote_addr;
           proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
           proxy_set_header X-Forwarded-Proto $scheme;
       }
   }

Souvent, le premier signe que quelqu'un est en train d'espionner vos couches de transport est l'utilisation d'un grand nombre de mots de passe d'utilisateurs volés lors d'attaques ultérieures. Si d'autres données, telles que des informations sur les clients, des dossiers financiers ou des secrets d'entreprise importants, sont volées via une couche de transport non sécurisée, il se peut que vous ne vous rendiez même pas compte que vous avez été compromis.

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

Sécuriser correctement les couches de transport pour une protection totale des données

La meilleure façon de protéger les couches de transport est de le faire pendant la création des applications. Ce processus commence par la mise en place d'une infrastructure dorsale 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 de manière à ce que les requêtes HTTP non sécurisées soient automatiquement acheminées vers l'infrastructure HTTPS.

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

server {
       server_name scw-dev-blog.org;
       listen 8443 ssl;
       ssl_protocols TLSv1.2 TLSv1.3;
       ssl_ciphers EECDH+AESGCM:EDH+AESGCM;
       ssl_prefer_server_ciphers on;
       ssl_certificate /run/secrets/nginx_cert;
       ssl_certificate_key /run/secrets/nginx_key;
       access_log /dev/stdout;
       error_log /dev/stderr;
       location / {
           proxy_pass http://wordpress:8080;
           proxy_set_header Host $http_host;
           proxy_set_header X-Forwarded-Host $http_host;
           proxy_set_header X-Real-IP $remote_addr;
           proxy_set_header X-Forwarded-For $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 de Nginx n'inclut que listen 8443 ssl afin de forcer SSL à protéger les connexions.

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

N'oubliez jamais 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. De cette façon, vous pouvez garantir une protection complète de bout en bout des données, tant en interne que lorsqu'elles sont transmises à des utilisateurs externes autorisés.
Consultez les pages du Secure Code Warrior 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 essayer une démo de la plateforme de formation Secure Code Warrior pour maintenir vos compétences en cybersécurité à jour.

Voir la ressource
Voir la ressource

Remplissez le formulaire ci-dessous pour télécharger le rapport

Nous aimerions que vous nous autorisiez à vous envoyer des informations sur nos produits et/ou sur des sujets liés au codage sécurisé. Nous traiterons toujours vos données personnelles avec le plus grand soin et ne les vendrons jamais à d'autres entreprises à des fins de marketing.

Soumettre
Pour soumettre le formulaire, veuillez activer les cookies "Analytics". N'hésitez pas à les désactiver à nouveau une fois que vous aurez terminé.

Si vous êtes un développeur et que vous souhaitez en savoir plus sur les étapes à suivre pour commencer à déployer une infrastructure sécurisée sous forme de code (IaC) dans votre entreprise, vous êtes au bon endroit. Il s'agit du chapitre suivant de notre série sur l'IaC, conçue pour vous faire progresser dans les meilleures pratiques de sécurité de l'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 vous vous en sortez avec une protection de la couche transport insuffisante avant d'entrer dans les détails :

Vous voulez en savoir plus et obtenir une note parfaite ? 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 fort, il agit comme une dernière ligne de défense parfaite. Même si un pirate est en mesure de voler ces données, si elles sont fortement cryptées, les informations enfermé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. Lorsque 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. Si la couche transport n'est pas protégée, elle est vulnérable à la fois à l'espionnage extérieur et à la visualisation interne non autorisée. Ainsi, une protection insuffisante de la couche transport peut entraîner de graves problèmes.

Il s'agit d'un problème courant. L'organisation de sécurité OWASP consacre même une page entière à la 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 des pirates compétents 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 qu'il est presque totalement invisible pour les plateformes ou les analyses de cybersécurité internes, car il se produit en dehors de votre réseau et de votre contrôle.

Par exemple, dans un environnement Docker qui déploie un service Nginx, les pirates peuvent intercepter les informations qui circulent entre vos utilisateurs et vos applications :

services :
nginx :
image : localhost:5000/scw_nginx
build : ./nginx
secrets :
- nginx_cert
- nginx_key
volumes :
- type : bind
source : ./nginx/nginx.conf
target : /etc/nginx/nginx.conf
read_only : yes
ports :
- 80:8443
networks :
- frontend
deploy :
restart_policy : *default-restart_policy
resources : *politique_default-resources

La configuration du service Nginx ne crypte ni ne protège la connexion, ce qui rend toutes les informations échangées par le biais de la liaison vulnérables à diverses attaques ou à l'espionnage.

server {
       server_name scw-dev-blog.org;
       listen 8443;
       ssl_protocols TLSv1.2 TLSv1.3;
       ssl_ciphers EECDH+AESGCM:EDH+AESGCM;
       ssl_prefer_server_ciphers on;
       ssl_certificate /run/secrets/nginx_cert;
       ssl_certificate_key /run/secrets/nginx_key;
       access_log /dev/stdout;
       error_log /dev/stderr;
       location / {
           proxy_pass http://wordpress:8080;
           proxy_set_header Host $http_host;
           proxy_set_header X-Forwarded-Host $http_host;
           proxy_set_header X-Real-IP $remote_addr;
           proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
           proxy_set_header X-Forwarded-Proto $scheme;
       }
   }

Souvent, le premier signe que quelqu'un est en train d'espionner vos couches de transport est l'utilisation d'un grand nombre de mots de passe d'utilisateurs volés lors d'attaques ultérieures. Si d'autres données, telles que des informations sur les clients, des dossiers financiers ou des secrets d'entreprise importants, sont volées via une couche de transport non sécurisée, il se peut que vous ne vous rendiez même pas compte que vous avez été compromis.

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

Sécuriser correctement les couches de transport pour une protection totale des données

La meilleure façon de protéger les couches de transport est de le faire pendant la création des applications. Ce processus commence par la mise en place d'une infrastructure dorsale 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 de manière à ce que les requêtes HTTP non sécurisées soient automatiquement acheminées vers l'infrastructure HTTPS.

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

server {
       server_name scw-dev-blog.org;
       listen 8443 ssl;
       ssl_protocols TLSv1.2 TLSv1.3;
       ssl_ciphers EECDH+AESGCM:EDH+AESGCM;
       ssl_prefer_server_ciphers on;
       ssl_certificate /run/secrets/nginx_cert;
       ssl_certificate_key /run/secrets/nginx_key;
       access_log /dev/stdout;
       error_log /dev/stderr;
       location / {
           proxy_pass http://wordpress:8080;
           proxy_set_header Host $http_host;
           proxy_set_header X-Forwarded-Host $http_host;
           proxy_set_header X-Real-IP $remote_addr;
           proxy_set_header X-Forwarded-For $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 de Nginx n'inclut que listen 8443 ssl afin de forcer SSL à protéger les connexions.

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

N'oubliez jamais 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. De cette façon, vous pouvez garantir une protection complète de bout en bout des données, tant en interne que lorsqu'elles sont transmises à des utilisateurs externes autorisés.
Consultez les pages du Secure Code Warrior 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 essayer une démo de la plateforme de formation Secure Code Warrior pour maintenir vos compétences en cybersécurité à jour.

Accès aux ressources

Cliquez sur le lien ci-dessous et téléchargez le PDF de cette ressource.

Secure Code Warrior est là pour vous aider à sécuriser le code tout au long du cycle de vie du développement logiciel et à créer une culture dans laquelle la cybersécurité est une priorité. Que vous soyez responsable AppSec, développeur, CISO ou toute autre personne impliquée dans la sécurité, nous pouvons aider votre organisation à réduire les risques associés à un code non sécurisé.

Voir le rapportRéservez une démonstration
Télécharger le PDF
Voir la ressource
Partager sur :
Vous souhaitez en savoir plus ?

Partager sur :
Auteur
Matias Madou, Ph.D.
Publié le 01 juin 2020

Matias Madou est expert en sécurité, chercheur, directeur technique et cofondateur de Secure Code Warrior. Matias a obtenu son doctorat en sécurité des applications à l'université de Gand, en se concentrant sur les solutions d'analyse statique. Il a ensuite rejoint Fortify aux États-Unis, où il s'est rendu compte qu'il ne suffisait pas de détecter les problèmes de code sans aider les développeurs à écrire du code sécurisé. C'est ce qui l'a incité à développer des produits qui aident les développeurs, allègent le fardeau de la sécurité et dépassent les attentes des clients. Lorsqu'il n'est pas à son bureau en tant que membre de l'équipe Awesome, il aime être sur scène pour présenter des conférences, notamment RSA Conference, BlackHat et DefCon.

Matias est un chercheur et un développeur qui possède plus de 15 ans d'expérience pratique dans le domaine de la sécurité des logiciels. Il a développé des solutions pour des entreprises telles que Fortify Software et sa propre entreprise Sensei Security. Au cours de sa carrière, Matias a dirigé de nombreux projets de recherche sur la sécurité des applications qui ont débouché sur des produits commerciaux et peut se targuer d'avoir déposé plus de 10 brevets. Lorsqu'il n'est pas à son bureau, Matias a été instructeur pour des formations avancées en matière de sécurité des applications ( courses ) et intervient régulièrement lors de conférences mondiales telles que RSA Conference, Black Hat, DefCon, BSIMM, OWASP AppSec et BruCon.

Matias est titulaire d'un doctorat en ingénierie informatique de l'Université de Gand, où il a étudié la sécurité des applications par le biais de l'obscurcissement des programmes afin de dissimuler le fonctionnement interne d'une application.

Partager sur :

Si vous êtes un développeur et que vous souhaitez en savoir plus sur les étapes à suivre pour commencer à déployer une infrastructure sécurisée sous forme de code (IaC) dans votre entreprise, vous êtes au bon endroit. Il s'agit du chapitre suivant de notre série sur l'IaC, conçue pour vous faire progresser dans les meilleures pratiques de sécurité de l'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 vous vous en sortez avec une protection de la couche transport insuffisante avant d'entrer dans les détails :

Vous voulez en savoir plus et obtenir une note parfaite ? 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 fort, il agit comme une dernière ligne de défense parfaite. Même si un pirate est en mesure de voler ces données, si elles sont fortement cryptées, les informations enfermé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. Lorsque 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. Si la couche transport n'est pas protégée, elle est vulnérable à la fois à l'espionnage extérieur et à la visualisation interne non autorisée. Ainsi, une protection insuffisante de la couche transport peut entraîner de graves problèmes.

Il s'agit d'un problème courant. L'organisation de sécurité OWASP consacre même une page entière à la 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 des pirates compétents 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 qu'il est presque totalement invisible pour les plateformes ou les analyses de cybersécurité internes, car il se produit en dehors de votre réseau et de votre contrôle.

Par exemple, dans un environnement Docker qui déploie un service Nginx, les pirates peuvent intercepter les informations qui circulent entre vos utilisateurs et vos applications :

services :
nginx :
image : localhost:5000/scw_nginx
build : ./nginx
secrets :
- nginx_cert
- nginx_key
volumes :
- type : bind
source : ./nginx/nginx.conf
target : /etc/nginx/nginx.conf
read_only : yes
ports :
- 80:8443
networks :
- frontend
deploy :
restart_policy : *default-restart_policy
resources : *politique_default-resources

La configuration du service Nginx ne crypte ni ne protège la connexion, ce qui rend toutes les informations échangées par le biais de la liaison vulnérables à diverses attaques ou à l'espionnage.

server {
       server_name scw-dev-blog.org;
       listen 8443;
       ssl_protocols TLSv1.2 TLSv1.3;
       ssl_ciphers EECDH+AESGCM:EDH+AESGCM;
       ssl_prefer_server_ciphers on;
       ssl_certificate /run/secrets/nginx_cert;
       ssl_certificate_key /run/secrets/nginx_key;
       access_log /dev/stdout;
       error_log /dev/stderr;
       location / {
           proxy_pass http://wordpress:8080;
           proxy_set_header Host $http_host;
           proxy_set_header X-Forwarded-Host $http_host;
           proxy_set_header X-Real-IP $remote_addr;
           proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
           proxy_set_header X-Forwarded-Proto $scheme;
       }
   }

Souvent, le premier signe que quelqu'un est en train d'espionner vos couches de transport est l'utilisation d'un grand nombre de mots de passe d'utilisateurs volés lors d'attaques ultérieures. Si d'autres données, telles que des informations sur les clients, des dossiers financiers ou des secrets d'entreprise importants, sont volées via une couche de transport non sécurisée, il se peut que vous ne vous rendiez même pas compte que vous avez été compromis.

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

Sécuriser correctement les couches de transport pour une protection totale des données

La meilleure façon de protéger les couches de transport est de le faire pendant la création des applications. Ce processus commence par la mise en place d'une infrastructure dorsale 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 de manière à ce que les requêtes HTTP non sécurisées soient automatiquement acheminées vers l'infrastructure HTTPS.

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

server {
       server_name scw-dev-blog.org;
       listen 8443 ssl;
       ssl_protocols TLSv1.2 TLSv1.3;
       ssl_ciphers EECDH+AESGCM:EDH+AESGCM;
       ssl_prefer_server_ciphers on;
       ssl_certificate /run/secrets/nginx_cert;
       ssl_certificate_key /run/secrets/nginx_key;
       access_log /dev/stdout;
       error_log /dev/stderr;
       location / {
           proxy_pass http://wordpress:8080;
           proxy_set_header Host $http_host;
           proxy_set_header X-Forwarded-Host $http_host;
           proxy_set_header X-Real-IP $remote_addr;
           proxy_set_header X-Forwarded-For $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 de Nginx n'inclut que listen 8443 ssl afin de forcer SSL à protéger les connexions.

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

N'oubliez jamais 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. De cette façon, vous pouvez garantir une protection complète de bout en bout des données, tant en interne que lorsqu'elles sont transmises à des utilisateurs externes autorisés.
Consultez les pages du Secure Code Warrior 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 essayer une démo de la plateforme de formation Secure Code Warrior pour maintenir vos compétences en cybersécurité à jour.

Table des matières

Télécharger le PDF
Voir la ressource
Vous souhaitez en savoir plus ?

Matias Madou est expert en sécurité, chercheur, directeur technique et cofondateur de Secure Code Warrior. Matias a obtenu son doctorat en sécurité des applications à l'université de Gand, en se concentrant sur les solutions d'analyse statique. Il a ensuite rejoint Fortify aux États-Unis, où il s'est rendu compte qu'il ne suffisait pas de détecter les problèmes de code sans aider les développeurs à écrire du code sécurisé. C'est ce qui l'a incité à développer des produits qui aident les développeurs, allègent le fardeau de la sécurité et dépassent les attentes des clients. Lorsqu'il n'est pas à son bureau en tant que membre de l'équipe Awesome, il aime être sur scène pour présenter des conférences, notamment RSA Conference, BlackHat et DefCon.

Secure Code Warrior est là pour vous aider à sécuriser le code tout au long du cycle de vie du développement logiciel et à créer une culture dans laquelle la cybersécurité est une priorité. Que vous soyez responsable AppSec, développeur, CISO ou toute autre personne impliquée dans la sécurité, nous pouvons aider votre organisation à réduire les risques associés à un code non sécurisé.

Réservez une démonstrationTélécharger
Partager sur :
Centre de ressources

Ressources pour vous aider à démarrer

Plus d'articles
Centre de ressources

Ressources pour vous aider à démarrer

Plus d'articles