
Los programadores conquistan la infraestructura de seguridad como series de códigos: protección insuficiente de la capa de transporte
Si es un desarrollador que desea obtener más información sobre los pasos que puede seguir para comenzar a implementar una infraestructura segura como código (IaC) en su organización, ha venido al lugar correcto. Este es el siguiente capítulo de nuestra serie IaC, diseñada para mejorar tus prácticas de seguridad en iAC.
Antes de empezar, ¿cómo te fue con el desafío de la última entrega? Si dominas la criptografía insegura, veamos cómo te va si la protección de la capa de transporte es insuficiente antes de entrar en detalles:
¿Quieres obtener más información y lograr una puntuación perfecta? Sigue leyendo:
En nuestro último artículo, hablamos sobre la importancia de tener una criptografía segura para proteger cualquier dato importante o personal almacenado por aplicaciones y programas. Si tiene un cifrado sólido, actúa como una última línea de defensa perfecta. Incluso si un atacante es capaz de robar esos datos, si están fuertemente cifrados, la información guardada en esos archivos sigue estando protegida.
Sin embargo, proteger los datos en reposo es solo una parte de una defensa completa de los datos. Siempre que los usuarios válidos necesiten acceder a los datos protegidos, se les deben enviar. En ocasiones, las aplicaciones también comparten datos con otros programas como parte de una carga de trabajo general. A menos que la capa de transporte esté protegida, es vulnerable tanto a la intromisión externa como a la visualización interna no autorizada. Por lo tanto, tener una protección insuficiente en la capa de transporte puede causar problemas graves.
Es un problema común. La organización de seguridad OWASP incluso mantiene una página completa sobre protección insuficiente de la capa de transporte.
¿Por qué es peligrosa una protección insuficiente de la capa de transporte?
Si no proteges suficientemente tus capas de transporte, es relativamente fácil para los piratas informáticos expertos interceptar la información que fluye entre tus usuarios y tus aplicaciones mediante técnicas como los ataques intermediarios. Probablemente el aspecto más peligroso de este tipo de espionaje es que es casi completamente invisible para cualquier plataforma o análisis de ciberseguridad interno, ya que se produce fuera de la red y de su control.
Por ejemplo, en un entorno Docker que implementa un servicio de Nginx:
servicios:
nginx:
imagen: localhost: 5000/scw_nginx
construir:. /nginx
secretos:
- nginx_cert
- nginx_key
volúmenes:
- tipo: encuadernar
fuente:. /nginx/nginx.conf
objetivo: /etc/nginx/nginx.conf
read_only: sí
puertos:
- 80:8443
redes:
- interfaz
implementar:
restart_policy: *default-restart_policy
recursos: *default-resources_policy
La configuración del servicio de Nginx no cifrará ni protegerá la conexión, lo que hace que toda la información que se intercambie a través del enlace sea vulnerable a diversos ataques o intromisiones.
servidor {
nombre_servidor scw-dev-blog.org;
escucha 8443;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers EECDH+AESGCM: EDH+AESGCM;
ssl_prefer_server_ciphers activado;
ssl_certificate /run/secrets/nginx_cert;
ssl_certificate_key /run/secrets/nginx_key;
access_log /dev/stdout;
error_log /dev/stderr;
ubicación/{
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-Para $proxy_add_x_forwarded_for;
esquema proxy_set_header X-Forwarded-Proto $;
}
}
Muchas veces, la primera señal de que alguien puede estar husmeando en tus capas de transporte es cuando se utiliza una gran cantidad de contraseñas de usuario robadas en ataques posteriores. Si otros datos, como la información de los clientes, los registros financieros o los secretos importantes de la empresa, son robados a través de una capa de transporte insegura, es posible que ni siquiera se dé cuenta de que se ha visto comprometida su información.
Y no es solo la capa de transporte entre los usuarios y las aplicaciones la que requiere protección. En el backend, muchas aplicaciones se comunican entre sí y con los servidores que se encuentran más avanzados en la cadena de flujo de trabajo. Si bien estas comunicaciones internas no suelen ser vulnerables a la intromisión externa, pueden exponer los datos a usuarios que pueden acceder a la red pero no están autorizados a ver cierta información confidencial o altamente protegida.
Proteger adecuadamente las capas de transporte para una protección total de los datos
La protección de las capas de transporte se realiza mejor mientras se crean las aplicaciones. Este proceso comienza con tener una infraestructura de back-end segura. En el caso de los sitios web, todo debe hacerse mediante HTTPS. Nunca mezcle la infraestructura HTTP y HTTPS. Incluso deberías configurar tus sitios para que dirijan automáticamente las solicitudes HTTP no seguras a la infraestructura HTTPS.
En el ejemplo anterior, un método apropiado para proteger la capa de transporte sería:
servidor {
nombre_servidor scw-dev-blog.org;
escucha 8443 ssl;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers EECDH+AESGCM: EDH+AESGCM;
ssl_prefer_server_ciphers activado;
ssl_certificate /run/secrets/nginx_cert;
ssl_certificate_key /run/secrets/nginx_key;
access_log /dev/stdout;
error_log /dev/stderr;
ubicación/{
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-Para $proxy_add_x_forwarded_for;
esquema proxy_set_header X-Forwarded-Proto $;
}
}
En ese ejemplo, todas las conexiones con el servicio Nginx están fuertemente cifradas. La sección de servidor de la configuración de Nginx solo incluye escuchar 8443 ssl para forzar el SSL para proteger las conexiones.
Para proteger sus datos de las amenazas internas, los desarrolladores deben emplear un protocolo de cifrado de capa de transporte sólido, como TLS 1.2. Una vez que tengas instalado el TLS 1.2 o su equivalente, los protocolos más débiles, como el SSL v2, deberían eliminarse por completo de tu infraestructura y prohibirse automáticamente su uso.
Y tenga siempre en cuenta que la protección de una aplicación no está completamente completa hasta que tanto los datos en reposo como las capas de transporte estén suficientemente protegidos. De este modo, puede garantizar una protección completa e integral de los datos, tanto internos como cuando se transfieren a usuarios externos autorizados.
Eche un vistazo a la Secure Code Warrior páginas de blog para obtener más información sobre esta vulnerabilidad y sobre cómo proteger a su organización y a sus clientes de los estragos de otras fallas de seguridad. También puedes prueba una demo de la plataforma de formación Secure Code Warrior para mantener todas sus habilidades de ciberseguridad perfeccionadas y actualizadas.


En ocasiones, las aplicaciones también compartirán datos con otros programas como parte de una carga de trabajo general. A menos que la capa de transporte esté protegida, es vulnerable tanto a la intromisión externa como a la visualización interna no autorizada.
Matias Madou, Ph.D., ist Sicherheitsexperte, Forscher, CTO und Mitbegründer von Secure Code Warrior. Matias promovierte an der Universität Gent im Bereich Anwendungssicherheit und konzentrierte sich dabei auf statische Analyselösungen. Später wechselte er zu Fortify in den USA, wo er erkannte, dass es nicht ausreicht, nur Codeprobleme zu erkennen, ohne den Entwicklern beim Schreiben von sicherem Code zu helfen. Dies inspirierte ihn dazu, Produkte zu entwickeln, die Entwickler unterstützen, den Aufwand für die Sicherheit verringern und die Erwartungen der Kunden übertreffen. Wenn er nicht an seinem Schreibtisch im Team Awesome sitzt, steht er gerne auf der Bühne und hält Vorträge auf Konferenzen wie der RSA Conference, BlackHat und DefCon.

Secure Code Warrior hier, um Ihrem Unternehmen dabei zu helfen, den Code während des gesamten Lebenszyklus der Softwareentwicklung zu schützen und eine Kultur zu schaffen, in der Cybersicherheit oberste Priorität hat. Ganz gleich, ob Sie AppSec-Administrator, Entwickler, CISO oder in einem anderen Bereich der Sicherheit tätig sind – wir können Ihrem Unternehmen dabei helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Eine Vorführung buchenMatias Madou, Ph.D., ist Sicherheitsexperte, Forscher, CTO und Mitbegründer von Secure Code Warrior. Matias promovierte an der Universität Gent im Bereich Anwendungssicherheit und konzentrierte sich dabei auf statische Analyselösungen. Später wechselte er zu Fortify in den USA, wo er erkannte, dass es nicht ausreicht, nur Codeprobleme zu erkennen, ohne den Entwicklern beim Schreiben von sicherem Code zu helfen. Dies inspirierte ihn dazu, Produkte zu entwickeln, die Entwickler unterstützen, den Aufwand für die Sicherheit verringern und die Erwartungen der Kunden übertreffen. Wenn er nicht an seinem Schreibtisch im Team Awesome sitzt, steht er gerne auf der Bühne und hält Vorträge auf Konferenzen wie der RSA Conference, BlackHat und DefCon.
Matias ist ein Forscher und Entwickler mit mehr als 15 Jahren praktischer Erfahrung im Bereich der Softwaresicherheit. Er hat Lösungen für Unternehmen wie Fortify Software und sein eigenes Unternehmen Sensei Security entwickelt. Im Laufe seiner Karriere hat Matias mehrere Forschungsprojekte zur Anwendungssicherheit geleitet, die zu kommerziellen Produkten geführt haben, und kann auf über 10 Patente verweisen. Wenn er nicht am Schreibtisch sitzt, ist Matias als Ausbilder für fortgeschrittene Anwendungssicherheitstrainings courses tätig und hält regelmäßig Vorträge auf globalen Konferenzen wie RSA Conference, Black Hat, DefCon, BSIMM, OWASP AppSec und BruCon.
Matias hat einen Doktortitel in Computertechnik von der Universität Gent, wo er die Sicherheit von Anwendungen durch Programmverschleierung untersuchte, um die innere Funktionsweise einer Anwendung zu verbergen.


Si es un desarrollador que desea obtener más información sobre los pasos que puede seguir para comenzar a implementar una infraestructura segura como código (IaC) en su organización, ha venido al lugar correcto. Este es el siguiente capítulo de nuestra serie IaC, diseñada para mejorar tus prácticas de seguridad en iAC.
Antes de empezar, ¿cómo te fue con el desafío de la última entrega? Si dominas la criptografía insegura, veamos cómo te va si la protección de la capa de transporte es insuficiente antes de entrar en detalles:
¿Quieres obtener más información y lograr una puntuación perfecta? Sigue leyendo:
En nuestro último artículo, hablamos sobre la importancia de tener una criptografía segura para proteger cualquier dato importante o personal almacenado por aplicaciones y programas. Si tiene un cifrado sólido, actúa como una última línea de defensa perfecta. Incluso si un atacante es capaz de robar esos datos, si están fuertemente cifrados, la información guardada en esos archivos sigue estando protegida.
Sin embargo, proteger los datos en reposo es solo una parte de una defensa completa de los datos. Siempre que los usuarios válidos necesiten acceder a los datos protegidos, se les deben enviar. En ocasiones, las aplicaciones también comparten datos con otros programas como parte de una carga de trabajo general. A menos que la capa de transporte esté protegida, es vulnerable tanto a la intromisión externa como a la visualización interna no autorizada. Por lo tanto, tener una protección insuficiente en la capa de transporte puede causar problemas graves.
Es un problema común. La organización de seguridad OWASP incluso mantiene una página completa sobre protección insuficiente de la capa de transporte.
¿Por qué es peligrosa una protección insuficiente de la capa de transporte?
Si no proteges suficientemente tus capas de transporte, es relativamente fácil para los piratas informáticos expertos interceptar la información que fluye entre tus usuarios y tus aplicaciones mediante técnicas como los ataques intermediarios. Probablemente el aspecto más peligroso de este tipo de espionaje es que es casi completamente invisible para cualquier plataforma o análisis de ciberseguridad interno, ya que se produce fuera de la red y de su control.
Por ejemplo, en un entorno Docker que implementa un servicio de Nginx:
servicios:
nginx:
imagen: localhost: 5000/scw_nginx
construir:. /nginx
secretos:
- nginx_cert
- nginx_key
volúmenes:
- tipo: encuadernar
fuente:. /nginx/nginx.conf
objetivo: /etc/nginx/nginx.conf
read_only: sí
puertos:
- 80:8443
redes:
- interfaz
implementar:
restart_policy: *default-restart_policy
recursos: *default-resources_policy
La configuración del servicio de Nginx no cifrará ni protegerá la conexión, lo que hace que toda la información que se intercambie a través del enlace sea vulnerable a diversos ataques o intromisiones.
servidor {
nombre_servidor scw-dev-blog.org;
escucha 8443;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers EECDH+AESGCM: EDH+AESGCM;
ssl_prefer_server_ciphers activado;
ssl_certificate /run/secrets/nginx_cert;
ssl_certificate_key /run/secrets/nginx_key;
access_log /dev/stdout;
error_log /dev/stderr;
ubicación/{
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-Para $proxy_add_x_forwarded_for;
esquema proxy_set_header X-Forwarded-Proto $;
}
}
Muchas veces, la primera señal de que alguien puede estar husmeando en tus capas de transporte es cuando se utiliza una gran cantidad de contraseñas de usuario robadas en ataques posteriores. Si otros datos, como la información de los clientes, los registros financieros o los secretos importantes de la empresa, son robados a través de una capa de transporte insegura, es posible que ni siquiera se dé cuenta de que se ha visto comprometida su información.
Y no es solo la capa de transporte entre los usuarios y las aplicaciones la que requiere protección. En el backend, muchas aplicaciones se comunican entre sí y con los servidores que se encuentran más avanzados en la cadena de flujo de trabajo. Si bien estas comunicaciones internas no suelen ser vulnerables a la intromisión externa, pueden exponer los datos a usuarios que pueden acceder a la red pero no están autorizados a ver cierta información confidencial o altamente protegida.
Proteger adecuadamente las capas de transporte para una protección total de los datos
La protección de las capas de transporte se realiza mejor mientras se crean las aplicaciones. Este proceso comienza con tener una infraestructura de back-end segura. En el caso de los sitios web, todo debe hacerse mediante HTTPS. Nunca mezcle la infraestructura HTTP y HTTPS. Incluso deberías configurar tus sitios para que dirijan automáticamente las solicitudes HTTP no seguras a la infraestructura HTTPS.
En el ejemplo anterior, un método apropiado para proteger la capa de transporte sería:
servidor {
nombre_servidor scw-dev-blog.org;
escucha 8443 ssl;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers EECDH+AESGCM: EDH+AESGCM;
ssl_prefer_server_ciphers activado;
ssl_certificate /run/secrets/nginx_cert;
ssl_certificate_key /run/secrets/nginx_key;
access_log /dev/stdout;
error_log /dev/stderr;
ubicación/{
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-Para $proxy_add_x_forwarded_for;
esquema proxy_set_header X-Forwarded-Proto $;
}
}
En ese ejemplo, todas las conexiones con el servicio Nginx están fuertemente cifradas. La sección de servidor de la configuración de Nginx solo incluye escuchar 8443 ssl para forzar el SSL para proteger las conexiones.
Para proteger sus datos de las amenazas internas, los desarrolladores deben emplear un protocolo de cifrado de capa de transporte sólido, como TLS 1.2. Una vez que tengas instalado el TLS 1.2 o su equivalente, los protocolos más débiles, como el SSL v2, deberían eliminarse por completo de tu infraestructura y prohibirse automáticamente su uso.
Y tenga siempre en cuenta que la protección de una aplicación no está completamente completa hasta que tanto los datos en reposo como las capas de transporte estén suficientemente protegidos. De este modo, puede garantizar una protección completa e integral de los datos, tanto internos como cuando se transfieren a usuarios externos autorizados.
Eche un vistazo a la Secure Code Warrior páginas de blog para obtener más información sobre esta vulnerabilidad y sobre cómo proteger a su organización y a sus clientes de los estragos de otras fallas de seguridad. También puedes prueba una demo de la plataforma de formación Secure Code Warrior para mantener todas sus habilidades de ciberseguridad perfeccionadas y actualizadas.

Si es un desarrollador que desea obtener más información sobre los pasos que puede seguir para comenzar a implementar una infraestructura segura como código (IaC) en su organización, ha venido al lugar correcto. Este es el siguiente capítulo de nuestra serie IaC, diseñada para mejorar tus prácticas de seguridad en iAC.
Antes de empezar, ¿cómo te fue con el desafío de la última entrega? Si dominas la criptografía insegura, veamos cómo te va si la protección de la capa de transporte es insuficiente antes de entrar en detalles:
¿Quieres obtener más información y lograr una puntuación perfecta? Sigue leyendo:
En nuestro último artículo, hablamos sobre la importancia de tener una criptografía segura para proteger cualquier dato importante o personal almacenado por aplicaciones y programas. Si tiene un cifrado sólido, actúa como una última línea de defensa perfecta. Incluso si un atacante es capaz de robar esos datos, si están fuertemente cifrados, la información guardada en esos archivos sigue estando protegida.
Sin embargo, proteger los datos en reposo es solo una parte de una defensa completa de los datos. Siempre que los usuarios válidos necesiten acceder a los datos protegidos, se les deben enviar. En ocasiones, las aplicaciones también comparten datos con otros programas como parte de una carga de trabajo general. A menos que la capa de transporte esté protegida, es vulnerable tanto a la intromisión externa como a la visualización interna no autorizada. Por lo tanto, tener una protección insuficiente en la capa de transporte puede causar problemas graves.
Es un problema común. La organización de seguridad OWASP incluso mantiene una página completa sobre protección insuficiente de la capa de transporte.
¿Por qué es peligrosa una protección insuficiente de la capa de transporte?
Si no proteges suficientemente tus capas de transporte, es relativamente fácil para los piratas informáticos expertos interceptar la información que fluye entre tus usuarios y tus aplicaciones mediante técnicas como los ataques intermediarios. Probablemente el aspecto más peligroso de este tipo de espionaje es que es casi completamente invisible para cualquier plataforma o análisis de ciberseguridad interno, ya que se produce fuera de la red y de su control.
Por ejemplo, en un entorno Docker que implementa un servicio de Nginx:
servicios:
nginx:
imagen: localhost: 5000/scw_nginx
construir:. /nginx
secretos:
- nginx_cert
- nginx_key
volúmenes:
- tipo: encuadernar
fuente:. /nginx/nginx.conf
objetivo: /etc/nginx/nginx.conf
read_only: sí
puertos:
- 80:8443
redes:
- interfaz
implementar:
restart_policy: *default-restart_policy
recursos: *default-resources_policy
La configuración del servicio de Nginx no cifrará ni protegerá la conexión, lo que hace que toda la información que se intercambie a través del enlace sea vulnerable a diversos ataques o intromisiones.
servidor {
nombre_servidor scw-dev-blog.org;
escucha 8443;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers EECDH+AESGCM: EDH+AESGCM;
ssl_prefer_server_ciphers activado;
ssl_certificate /run/secrets/nginx_cert;
ssl_certificate_key /run/secrets/nginx_key;
access_log /dev/stdout;
error_log /dev/stderr;
ubicación/{
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-Para $proxy_add_x_forwarded_for;
esquema proxy_set_header X-Forwarded-Proto $;
}
}
Muchas veces, la primera señal de que alguien puede estar husmeando en tus capas de transporte es cuando se utiliza una gran cantidad de contraseñas de usuario robadas en ataques posteriores. Si otros datos, como la información de los clientes, los registros financieros o los secretos importantes de la empresa, son robados a través de una capa de transporte insegura, es posible que ni siquiera se dé cuenta de que se ha visto comprometida su información.
Y no es solo la capa de transporte entre los usuarios y las aplicaciones la que requiere protección. En el backend, muchas aplicaciones se comunican entre sí y con los servidores que se encuentran más avanzados en la cadena de flujo de trabajo. Si bien estas comunicaciones internas no suelen ser vulnerables a la intromisión externa, pueden exponer los datos a usuarios que pueden acceder a la red pero no están autorizados a ver cierta información confidencial o altamente protegida.
Proteger adecuadamente las capas de transporte para una protección total de los datos
La protección de las capas de transporte se realiza mejor mientras se crean las aplicaciones. Este proceso comienza con tener una infraestructura de back-end segura. En el caso de los sitios web, todo debe hacerse mediante HTTPS. Nunca mezcle la infraestructura HTTP y HTTPS. Incluso deberías configurar tus sitios para que dirijan automáticamente las solicitudes HTTP no seguras a la infraestructura HTTPS.
En el ejemplo anterior, un método apropiado para proteger la capa de transporte sería:
servidor {
nombre_servidor scw-dev-blog.org;
escucha 8443 ssl;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers EECDH+AESGCM: EDH+AESGCM;
ssl_prefer_server_ciphers activado;
ssl_certificate /run/secrets/nginx_cert;
ssl_certificate_key /run/secrets/nginx_key;
access_log /dev/stdout;
error_log /dev/stderr;
ubicación/{
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-Para $proxy_add_x_forwarded_for;
esquema proxy_set_header X-Forwarded-Proto $;
}
}
En ese ejemplo, todas las conexiones con el servicio Nginx están fuertemente cifradas. La sección de servidor de la configuración de Nginx solo incluye escuchar 8443 ssl para forzar el SSL para proteger las conexiones.
Para proteger sus datos de las amenazas internas, los desarrolladores deben emplear un protocolo de cifrado de capa de transporte sólido, como TLS 1.2. Una vez que tengas instalado el TLS 1.2 o su equivalente, los protocolos más débiles, como el SSL v2, deberían eliminarse por completo de tu infraestructura y prohibirse automáticamente su uso.
Y tenga siempre en cuenta que la protección de una aplicación no está completamente completa hasta que tanto los datos en reposo como las capas de transporte estén suficientemente protegidos. De este modo, puede garantizar una protección completa e integral de los datos, tanto internos como cuando se transfieren a usuarios externos autorizados.
Eche un vistazo a la Secure Code Warrior páginas de blog para obtener más información sobre esta vulnerabilidad y sobre cómo proteger a su organización y a sus clientes de los estragos de otras fallas de seguridad. También puedes prueba una demo de la plataforma de formación Secure Code Warrior para mantener todas sus habilidades de ciberseguridad perfeccionadas y actualizadas.

Klicken Sie auf den untenstehenden Link und laden Sie die PDF-Datei dieser Ressource herunter.
Secure Code Warrior hier, um Ihrem Unternehmen dabei zu helfen, den Code während des gesamten Lebenszyklus der Softwareentwicklung zu schützen und eine Kultur zu schaffen, in der Cybersicherheit oberste Priorität hat. Ganz gleich, ob Sie AppSec-Administrator, Entwickler, CISO oder in einem anderen Bereich der Sicherheit tätig sind – wir können Ihrem Unternehmen dabei helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Bericht anzeigenEine Vorführung buchenMatias Madou, Ph.D., ist Sicherheitsexperte, Forscher, CTO und Mitbegründer von Secure Code Warrior. Matias promovierte an der Universität Gent im Bereich Anwendungssicherheit und konzentrierte sich dabei auf statische Analyselösungen. Später wechselte er zu Fortify in den USA, wo er erkannte, dass es nicht ausreicht, nur Codeprobleme zu erkennen, ohne den Entwicklern beim Schreiben von sicherem Code zu helfen. Dies inspirierte ihn dazu, Produkte zu entwickeln, die Entwickler unterstützen, den Aufwand für die Sicherheit verringern und die Erwartungen der Kunden übertreffen. Wenn er nicht an seinem Schreibtisch im Team Awesome sitzt, steht er gerne auf der Bühne und hält Vorträge auf Konferenzen wie der RSA Conference, BlackHat und DefCon.
Matias ist ein Forscher und Entwickler mit mehr als 15 Jahren praktischer Erfahrung im Bereich der Softwaresicherheit. Er hat Lösungen für Unternehmen wie Fortify Software und sein eigenes Unternehmen Sensei Security entwickelt. Im Laufe seiner Karriere hat Matias mehrere Forschungsprojekte zur Anwendungssicherheit geleitet, die zu kommerziellen Produkten geführt haben, und kann auf über 10 Patente verweisen. Wenn er nicht am Schreibtisch sitzt, ist Matias als Ausbilder für fortgeschrittene Anwendungssicherheitstrainings courses tätig und hält regelmäßig Vorträge auf globalen Konferenzen wie RSA Conference, Black Hat, DefCon, BSIMM, OWASP AppSec und BruCon.
Matias hat einen Doktortitel in Computertechnik von der Universität Gent, wo er die Sicherheit von Anwendungen durch Programmverschleierung untersuchte, um die innere Funktionsweise einer Anwendung zu verbergen.
Si es un desarrollador que desea obtener más información sobre los pasos que puede seguir para comenzar a implementar una infraestructura segura como código (IaC) en su organización, ha venido al lugar correcto. Este es el siguiente capítulo de nuestra serie IaC, diseñada para mejorar tus prácticas de seguridad en iAC.
Antes de empezar, ¿cómo te fue con el desafío de la última entrega? Si dominas la criptografía insegura, veamos cómo te va si la protección de la capa de transporte es insuficiente antes de entrar en detalles:
¿Quieres obtener más información y lograr una puntuación perfecta? Sigue leyendo:
En nuestro último artículo, hablamos sobre la importancia de tener una criptografía segura para proteger cualquier dato importante o personal almacenado por aplicaciones y programas. Si tiene un cifrado sólido, actúa como una última línea de defensa perfecta. Incluso si un atacante es capaz de robar esos datos, si están fuertemente cifrados, la información guardada en esos archivos sigue estando protegida.
Sin embargo, proteger los datos en reposo es solo una parte de una defensa completa de los datos. Siempre que los usuarios válidos necesiten acceder a los datos protegidos, se les deben enviar. En ocasiones, las aplicaciones también comparten datos con otros programas como parte de una carga de trabajo general. A menos que la capa de transporte esté protegida, es vulnerable tanto a la intromisión externa como a la visualización interna no autorizada. Por lo tanto, tener una protección insuficiente en la capa de transporte puede causar problemas graves.
Es un problema común. La organización de seguridad OWASP incluso mantiene una página completa sobre protección insuficiente de la capa de transporte.
¿Por qué es peligrosa una protección insuficiente de la capa de transporte?
Si no proteges suficientemente tus capas de transporte, es relativamente fácil para los piratas informáticos expertos interceptar la información que fluye entre tus usuarios y tus aplicaciones mediante técnicas como los ataques intermediarios. Probablemente el aspecto más peligroso de este tipo de espionaje es que es casi completamente invisible para cualquier plataforma o análisis de ciberseguridad interno, ya que se produce fuera de la red y de su control.
Por ejemplo, en un entorno Docker que implementa un servicio de Nginx:
servicios:
nginx:
imagen: localhost: 5000/scw_nginx
construir:. /nginx
secretos:
- nginx_cert
- nginx_key
volúmenes:
- tipo: encuadernar
fuente:. /nginx/nginx.conf
objetivo: /etc/nginx/nginx.conf
read_only: sí
puertos:
- 80:8443
redes:
- interfaz
implementar:
restart_policy: *default-restart_policy
recursos: *default-resources_policy
La configuración del servicio de Nginx no cifrará ni protegerá la conexión, lo que hace que toda la información que se intercambie a través del enlace sea vulnerable a diversos ataques o intromisiones.
servidor {
nombre_servidor scw-dev-blog.org;
escucha 8443;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers EECDH+AESGCM: EDH+AESGCM;
ssl_prefer_server_ciphers activado;
ssl_certificate /run/secrets/nginx_cert;
ssl_certificate_key /run/secrets/nginx_key;
access_log /dev/stdout;
error_log /dev/stderr;
ubicación/{
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-Para $proxy_add_x_forwarded_for;
esquema proxy_set_header X-Forwarded-Proto $;
}
}
Muchas veces, la primera señal de que alguien puede estar husmeando en tus capas de transporte es cuando se utiliza una gran cantidad de contraseñas de usuario robadas en ataques posteriores. Si otros datos, como la información de los clientes, los registros financieros o los secretos importantes de la empresa, son robados a través de una capa de transporte insegura, es posible que ni siquiera se dé cuenta de que se ha visto comprometida su información.
Y no es solo la capa de transporte entre los usuarios y las aplicaciones la que requiere protección. En el backend, muchas aplicaciones se comunican entre sí y con los servidores que se encuentran más avanzados en la cadena de flujo de trabajo. Si bien estas comunicaciones internas no suelen ser vulnerables a la intromisión externa, pueden exponer los datos a usuarios que pueden acceder a la red pero no están autorizados a ver cierta información confidencial o altamente protegida.
Proteger adecuadamente las capas de transporte para una protección total de los datos
La protección de las capas de transporte se realiza mejor mientras se crean las aplicaciones. Este proceso comienza con tener una infraestructura de back-end segura. En el caso de los sitios web, todo debe hacerse mediante HTTPS. Nunca mezcle la infraestructura HTTP y HTTPS. Incluso deberías configurar tus sitios para que dirijan automáticamente las solicitudes HTTP no seguras a la infraestructura HTTPS.
En el ejemplo anterior, un método apropiado para proteger la capa de transporte sería:
servidor {
nombre_servidor scw-dev-blog.org;
escucha 8443 ssl;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers EECDH+AESGCM: EDH+AESGCM;
ssl_prefer_server_ciphers activado;
ssl_certificate /run/secrets/nginx_cert;
ssl_certificate_key /run/secrets/nginx_key;
access_log /dev/stdout;
error_log /dev/stderr;
ubicación/{
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-Para $proxy_add_x_forwarded_for;
esquema proxy_set_header X-Forwarded-Proto $;
}
}
En ese ejemplo, todas las conexiones con el servicio Nginx están fuertemente cifradas. La sección de servidor de la configuración de Nginx solo incluye escuchar 8443 ssl para forzar el SSL para proteger las conexiones.
Para proteger sus datos de las amenazas internas, los desarrolladores deben emplear un protocolo de cifrado de capa de transporte sólido, como TLS 1.2. Una vez que tengas instalado el TLS 1.2 o su equivalente, los protocolos más débiles, como el SSL v2, deberían eliminarse por completo de tu infraestructura y prohibirse automáticamente su uso.
Y tenga siempre en cuenta que la protección de una aplicación no está completamente completa hasta que tanto los datos en reposo como las capas de transporte estén suficientemente protegidos. De este modo, puede garantizar una protección completa e integral de los datos, tanto internos como cuando se transfieren a usuarios externos autorizados.
Eche un vistazo a la Secure Code Warrior páginas de blog para obtener más información sobre esta vulnerabilidad y sobre cómo proteger a su organización y a sus clientes de los estragos de otras fallas de seguridad. También puedes prueba una demo de la plataforma de formación Secure Code Warrior para mantener todas sus habilidades de ciberseguridad perfeccionadas y actualizadas.
Inhaltsverzeichnis
Matias Madou, Ph.D., ist Sicherheitsexperte, Forscher, CTO und Mitbegründer von Secure Code Warrior. Matias promovierte an der Universität Gent im Bereich Anwendungssicherheit und konzentrierte sich dabei auf statische Analyselösungen. Später wechselte er zu Fortify in den USA, wo er erkannte, dass es nicht ausreicht, nur Codeprobleme zu erkennen, ohne den Entwicklern beim Schreiben von sicherem Code zu helfen. Dies inspirierte ihn dazu, Produkte zu entwickeln, die Entwickler unterstützen, den Aufwand für die Sicherheit verringern und die Erwartungen der Kunden übertreffen. Wenn er nicht an seinem Schreibtisch im Team Awesome sitzt, steht er gerne auf der Bühne und hält Vorträge auf Konferenzen wie der RSA Conference, BlackHat und DefCon.

Secure Code Warrior hier, um Ihrem Unternehmen dabei zu helfen, den Code während des gesamten Lebenszyklus der Softwareentwicklung zu schützen und eine Kultur zu schaffen, in der Cybersicherheit oberste Priorität hat. Ganz gleich, ob Sie AppSec-Administrator, Entwickler, CISO oder in einem anderen Bereich der Sicherheit tätig sind – wir können Ihrem Unternehmen dabei helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Eine Vorführung buchenHerunterladenRessourcen für den Einstieg
Themen und Inhalte der Schulung zum Thema sicherer Code
Unsere branchenführenden Inhalte werden ständig weiterentwickelt, um sich an die sich wandelnde Landschaft der Softwareentwicklung anzupassen und dabei Ihre Rolle zu berücksichtigen. Es werden Themen angeboten, die von KI bis hin zu XQuery-Injektion reichen und sich an verschiedene Positionen richten, von Architekten und Ingenieuren bis hin zu Produktmanagern und Qualitätskontrolleuren. Verschaffen Sie sich einen Überblick über unser Angebot an Inhalten nach Thema und Funktion.
Die Kamer van Koophandel setzt Maßstäbe für entwicklergesteuerte Sicherheit in großem Maßstab
Die Kamer van Koophandel berichtet, wie sie sicheres Codieren durch rollenbasierte Zertifizierungen, Trust Score-Benchmarking und eine Kultur der gemeinsamen Verantwortung für Sicherheit in die tägliche Entwicklungsarbeit integriert hat.
Bedrohungsmodellierung mit KI: So wird jeder Entwickler zum Bedrohungsmodellierer
Sie werden besser gerüstet sein, um Entwicklern dabei zu helfen, Ideen und Techniken zur Bedrohungsmodellierung mit den KI-Tools zu kombinieren, die sie bereits verwenden, um die Sicherheit zu erhöhen, die Zusammenarbeit zu verbessern und von Anfang an widerstandsfähigere Software zu entwickeln.
Ressourcen für den Einstieg
Cybermon ist zurück: Die KI-Missionen von Beat the Boss sind jetzt auf Abruf verfügbar.
Cybermon 2025 Beat the Boss ist jetzt das ganze Jahr über bei SCW verfügbar. Implementieren Sie fortschrittliche KI- und LLM-Sicherheitsherausforderungen, um die sichere Entwicklung von KI in großem Maßstab zu stärken.
Erläuterung des Gesetzes zur Cyberresilienz: Was bedeutet es für die Entwicklung sicherer Software?
Entdecken Sie, was das EU-Gesetz zur Cyberresilienz (CRA) verlangt, für wen es gilt und wie sich Ingenieurteams mit sicheren Designpraktiken, der Vermeidung von Schwachstellen und der Entwicklung von Fähigkeiten für Entwickler darauf vorbereiten können.
SCW feiert sein 11-jähriges Bestehen: eine Lektion in Echtzeit über Anpassungsfähigkeit und kontinuierliche Verbesserung
2025 war ein großartiges Jahr für KI, Cybersicherheit und SCW. Ich gehe mit ruhiger Zuversicht und dem Optimismus, den nur harte und lohnende Arbeit mit sich bringen kann, auf das Jahr 2026 zu.




%20(1).avif)
.avif)
