SCW图标
英雄背景无分隔线
博客

Los programadores conquistan la infraestructura de seguridad como series de códigos: protección insuficiente de la capa de transporte

马蒂亚斯-马杜博士
出版日期: 2020 年 6 月 1 日
最后更新于 2026年3月6日

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.是一位安全专家、研究员和CTO,也是Secure Code Warrior 的联合创始人。Matias在根特大学获得了应用安全的博士学位,主要研究静态分析解决方案。后来他加入了美国的Fortify公司,在那里他意识到,仅仅检测代码问题而不帮助开发人员编写安全代码是不够的。这激发了他开发产品的热情,帮助开发人员,减轻安全的负担,并超越客户的期望。当他不在办公桌前作为Awesome团队的一员时,他喜欢站在舞台上,在包括RSA会议、BlackHat和DefCon等会议上发表演讲。

了解更多

Secure Code Warrior 您的组织在软件开发全生命周期中保护代码安全,并营造将网络安全置于首位的企业文化。无论您是应用安全管理员、开发人员、首席信息安全官,还是任何与安全相关的工作人员,我们都能助力您的组织降低不安全代码带来的风险。

预约演示
分享到:
领英品牌社交x 标志
作者
马蒂亚斯-马杜博士
发表于2020年6月1日

Matias Madou, Ph.D.是一位安全专家、研究员和CTO,也是Secure Code Warrior 的联合创始人。Matias在根特大学获得了应用安全的博士学位,主要研究静态分析解决方案。后来他加入了美国的Fortify公司,在那里他意识到,仅仅检测代码问题而不帮助开发人员编写安全代码是不够的。这激发了他开发产品的热情,帮助开发人员,减轻安全的负担,并超越客户的期望。当他不在办公桌前作为Awesome团队的一员时,他喜欢站在舞台上,在包括RSA会议、BlackHat和DefCon等会议上发表演讲。

马蒂亚斯是一名研究员和开发人员,拥有超过15年的软件安全实践经验。他曾为Fortify Software和他自己的公司Sensei Security等公司开发解决方案。在他的职业生涯中,马蒂亚斯领导了多个应用安全研究项目,并将其转化为商业产品,他拥有超过10项专利。当他离开办公桌时,Matias曾担任高级应用安全培训courses ,并定期在全球会议上发言,包括RSA会议、黑帽、DefCon、BSIMM、OWASP AppSec和BruCon。

马蒂亚斯拥有根特大学的计算机工程博士学位,在那里他研究了通过程序混淆来隐藏应用程序的内部工作的应用安全。

分享到:
领英品牌社交x 标志

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.

查看资源
查看资源

请填写以下表格以下载报告

我们希望获得您的许可,以便向您发送有关我们产品或安全编码相关主题的信息。我们将始终以最高标准谨慎处理您的个人数据,绝不会出于营销目的将其出售给其他公司。

发送
scw 成功图标
SCW 错误图标
要提交表单,请启用「分析」cookie。完成后请随时将其重新禁用。

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.

观看网络研讨会
开始
了解更多

点击下方链接,下载此资源的PDF文件。

Secure Code Warrior 您的组织在软件开发全生命周期中保护代码安全,并营造将网络安全置于首位的企业文化。无论您是应用安全管理员、开发人员、首席信息安全官,还是任何与安全相关的工作人员,我们都能助力您的组织降低不安全代码带来的风险。

查看报告预约演示
查看资源
分享到:
领英品牌社交x 标志
感兴趣了解更多吗?

分享到:
领英品牌社交x 标志
作者
马蒂亚斯-马杜博士
发表于2020年6月1日

Matias Madou, Ph.D.是一位安全专家、研究员和CTO,也是Secure Code Warrior 的联合创始人。Matias在根特大学获得了应用安全的博士学位,主要研究静态分析解决方案。后来他加入了美国的Fortify公司,在那里他意识到,仅仅检测代码问题而不帮助开发人员编写安全代码是不够的。这激发了他开发产品的热情,帮助开发人员,减轻安全的负担,并超越客户的期望。当他不在办公桌前作为Awesome团队的一员时,他喜欢站在舞台上,在包括RSA会议、BlackHat和DefCon等会议上发表演讲。

马蒂亚斯是一名研究员和开发人员,拥有超过15年的软件安全实践经验。他曾为Fortify Software和他自己的公司Sensei Security等公司开发解决方案。在他的职业生涯中,马蒂亚斯领导了多个应用安全研究项目,并将其转化为商业产品,他拥有超过10项专利。当他离开办公桌时,Matias曾担任高级应用安全培训courses ,并定期在全球会议上发言,包括RSA会议、黑帽、DefCon、BSIMM、OWASP AppSec和BruCon。

马蒂亚斯拥有根特大学的计算机工程博士学位,在那里他研究了通过程序混淆来隐藏应用程序的内部工作的应用安全。

分享到:
领英品牌社交x 标志

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.

目录

下载PDF
查看资源
感兴趣了解更多吗?

Matias Madou, Ph.D.是一位安全专家、研究员和CTO,也是Secure Code Warrior 的联合创始人。Matias在根特大学获得了应用安全的博士学位,主要研究静态分析解决方案。后来他加入了美国的Fortify公司,在那里他意识到,仅仅检测代码问题而不帮助开发人员编写安全代码是不够的。这激发了他开发产品的热情,帮助开发人员,减轻安全的负担,并超越客户的期望。当他不在办公桌前作为Awesome团队的一员时,他喜欢站在舞台上,在包括RSA会议、BlackHat和DefCon等会议上发表演讲。

了解更多

Secure Code Warrior 您的组织在软件开发全生命周期中保护代码安全,并营造将网络安全置于首位的企业文化。无论您是应用安全管理员、开发人员、首席信息安全官,还是任何与安全相关的工作人员,我们都能助力您的组织降低不安全代码带来的风险。

预约演示下载
分享到:
领英品牌社交x 标志
资源中心

入门资源

更多出版物
资源中心

入门资源

更多出版物