编码员征服安全基础设施即代码系列。传输层保护不充分
如果你是一名开发人员,想了解更多关于在你的组织中开始部署安全的基础设施即代码(IaC)的步骤,那么你就来对地方了。这是我们IaC系列的下一章,旨在提高你的IaC安全最佳实践水平。
在我们开始之前,你在上一期的挑战中表现得如何?如果你已经掌握了不安全的加密技术,在我们深入讨论细节之前,让我们看看你在传输层保护不足的情况下是如何进行的。
想了解更多并取得满分吗?请继续阅读。
在上一篇文章中,我们谈到了拥有安全加密技术以保护应用程序和程序所存储的任何重要或个人数据的重要性。如果你有强大的加密技术,它就可以作为一个完美的最后一道防线。即使攻击者能够窃取这些数据,如果它是强加密的,那么锁定在这些文件中的信息仍然受到保护。
然而,保护静止的数据只是完整的数据防御的一部分。每当有效的用户需要访问受保护的数据时,必须将其发送给他们。有时,应用程序也会与其他程序共享数据,作为整个工作负载的一部分。除非传输层受到保护,否则会使其容易受到外部窥探和未经授权的内部查看。因此,传输层保护不足会导致严重的问题。
这是一个常见的问题。OWASP安全组织甚至维护了一个关于传输层保护不足的完整页面。
为什么传输层保护不足是危险的?
如果你没有充分保护你的传输层,那么熟练的黑客就很容易使用中间人攻击等技术截获你的用户和你的应用程序之间流动的信息。这种窥探最危险的方面可能是,它几乎完全看不到任何内部网络安全平台或扫描,因为它发生在你的网络和你的控制之外。
例如,在Docker环境中部署一个Nginx服务。
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:*default-resources_policy
Nginx服务配置不会对连接进行加密或保护,使得通过该链接交换的所有信息容易受到各种攻击或窥探。
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;
}
}
很多时候,有人可能通过你的传输层进行窥探的第一个信号是,大量被盗的用户密码被用于后续攻击。如果其他数据,如客户信息、财务记录或重要的公司机密通过不安全的传输层被盗,你甚至可能永远不会意识到你已经被破坏了。
而且,需要保护的不仅仅是用户和应用程序之间的传输层。在后端,许多应用程序彼此之间以及与工作流程中更远的服务器进行通信。虽然这些内部通信通常不容易被外界窥探,但它会将数据暴露给那些可能被允许进入网络但未被授权查看某些高度保护或敏感信息的用户。
妥善保护传输层,实现全面数据保护
保护传输层最好是在创建应用程序时进行。这个过程从拥有一个安全的后端基础设施开始。对于网站来说,一切都应该使用HTTPS来完成。切勿混合使用HTTP和HTTPS基础设施。你甚至应该将你的网站设置为自动将不安全的HTTP请求转到HTTPS基础设施上。
在上面的例子中,保护传输层的正确方法是。
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;
}
}
在这个例子中,所有与Nginx服务的连接都是强加密的。Nginx配置的服务器部分只包括listen 8443 ssl ,以便强迫SSL保护连接。
为了保护你的数据免受内部威胁,开发人员应该采用强大的传输层加密协议,如TLS 1.2。一旦你有了TLS 1.2或其等同物,像SSL v2这样较弱的协议应从你的基础设施中完全删除,并自动禁止使用。
并始终牢记,只有在静态数据和传输层得到充分保护时,才能确保应用程序的安全。这样,你就可以保证对内部数据和流向授权外部用户的数据进行完整的端对端保护。
。 Secure Code Warrior博客页面,了解有关这一漏洞的更多见解,以及如何保护你的组织和客户免受其他安全缺陷的蹂躏。你也可以尝试演示一下Secure Code Warrior 培训平台,以保持你所有的网络安全技能得到磨练和更新。
Matias Madou, Ph.D.是一位安全专家、研究员和CTO,也是Secure Code Warrior 的联合创始人。Matias在根特大学获得了应用安全的博士学位,主要研究静态分析解决方案。后来他加入了美国的Fortify公司,在那里他意识到,仅仅检测代码问题而不帮助开发人员编写安全代码是不够的。这激发了他开发产品的热情,帮助开发人员,减轻安全的负担,并超越客户的期望。当他不在办公桌前作为Awesome团队的一员时,他喜欢站在舞台上,在包括RSA会议、BlackHat和DefCon等会议上发表演讲。
Secure Code Warrior 我们在这里为您的组织提供服务,帮助您在整个软件开发生命周期中确保代码安全,并创造一种将网络安全放在首位的文化。无论您是应用安全经理、开发人员、CISO或任何涉及安全的人,我们都可以帮助您的组织减少与不安全代码有关的风险。
预定一个演示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。
马蒂亚斯拥有根特大学的计算机工程博士学位,在那里他研究了通过程序混淆来隐藏应用程序的内部工作的应用安全。
如果你是一名开发人员,想了解更多关于在你的组织中开始部署安全的基础设施即代码(IaC)的步骤,那么你就来对地方了。这是我们IaC系列的下一章,旨在提高你的IaC安全最佳实践水平。
在我们开始之前,你在上一期的挑战中表现得如何?如果你已经掌握了不安全的加密技术,在我们深入讨论细节之前,让我们看看你在传输层保护不足的情况下是如何进行的。
想了解更多并取得满分吗?请继续阅读。
在上一篇文章中,我们谈到了拥有安全加密技术以保护应用程序和程序所存储的任何重要或个人数据的重要性。如果你有强大的加密技术,它就可以作为一个完美的最后一道防线。即使攻击者能够窃取这些数据,如果它是强加密的,那么锁定在这些文件中的信息仍然受到保护。
然而,保护静止的数据只是完整的数据防御的一部分。每当有效的用户需要访问受保护的数据时,必须将其发送给他们。有时,应用程序也会与其他程序共享数据,作为整个工作负载的一部分。除非传输层受到保护,否则会使其容易受到外部窥探和未经授权的内部查看。因此,传输层保护不足会导致严重的问题。
这是一个常见的问题。OWASP安全组织甚至维护了一个关于传输层保护不足的完整页面。
为什么传输层保护不足是危险的?
如果你没有充分保护你的传输层,那么熟练的黑客就很容易使用中间人攻击等技术截获你的用户和你的应用程序之间流动的信息。这种窥探最危险的方面可能是,它几乎完全看不到任何内部网络安全平台或扫描,因为它发生在你的网络和你的控制之外。
例如,在Docker环境中部署一个Nginx服务。
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:*default-resources_policy
Nginx服务配置不会对连接进行加密或保护,使得通过该链接交换的所有信息容易受到各种攻击或窥探。
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;
}
}
很多时候,有人可能通过你的传输层进行窥探的第一个信号是,大量被盗的用户密码被用于后续攻击。如果其他数据,如客户信息、财务记录或重要的公司机密通过不安全的传输层被盗,你甚至可能永远不会意识到你已经被破坏了。
而且,需要保护的不仅仅是用户和应用程序之间的传输层。在后端,许多应用程序彼此之间以及与工作流程中更远的服务器进行通信。虽然这些内部通信通常不容易被外界窥探,但它会将数据暴露给那些可能被允许进入网络但未被授权查看某些高度保护或敏感信息的用户。
妥善保护传输层,实现全面数据保护
保护传输层最好是在创建应用程序时进行。这个过程从拥有一个安全的后端基础设施开始。对于网站来说,一切都应该使用HTTPS来完成。切勿混合使用HTTP和HTTPS基础设施。你甚至应该将你的网站设置为自动将不安全的HTTP请求转到HTTPS基础设施上。
在上面的例子中,保护传输层的正确方法是。
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;
}
}
在这个例子中,所有与Nginx服务的连接都是强加密的。Nginx配置的服务器部分只包括listen 8443 ssl ,以便强迫SSL保护连接。
为了保护你的数据免受内部威胁,开发人员应该采用强大的传输层加密协议,如TLS 1.2。一旦你有了TLS 1.2或其等同物,像SSL v2这样较弱的协议应从你的基础设施中完全删除,并自动禁止使用。
并始终牢记,只有在静态数据和传输层得到充分保护时,才能确保应用程序的安全。这样,你就可以保证对内部数据和流向授权外部用户的数据进行完整的端对端保护。
。 Secure Code Warrior博客页面,了解有关这一漏洞的更多见解,以及如何保护你的组织和客户免受其他安全缺陷的蹂躏。你也可以尝试演示一下Secure Code Warrior 培训平台,以保持你所有的网络安全技能得到磨练和更新。
如果你是一名开发人员,想了解更多关于在你的组织中开始部署安全的基础设施即代码(IaC)的步骤,那么你就来对地方了。这是我们IaC系列的下一章,旨在提高你的IaC安全最佳实践水平。
在我们开始之前,你在上一期的挑战中表现得如何?如果你已经掌握了不安全的加密技术,在我们深入讨论细节之前,让我们看看你在传输层保护不足的情况下是如何进行的。
想了解更多并取得满分吗?请继续阅读。
在上一篇文章中,我们谈到了拥有安全加密技术以保护应用程序和程序所存储的任何重要或个人数据的重要性。如果你有强大的加密技术,它就可以作为一个完美的最后一道防线。即使攻击者能够窃取这些数据,如果它是强加密的,那么锁定在这些文件中的信息仍然受到保护。
然而,保护静止的数据只是完整的数据防御的一部分。每当有效的用户需要访问受保护的数据时,必须将其发送给他们。有时,应用程序也会与其他程序共享数据,作为整个工作负载的一部分。除非传输层受到保护,否则会使其容易受到外部窥探和未经授权的内部查看。因此,传输层保护不足会导致严重的问题。
这是一个常见的问题。OWASP安全组织甚至维护了一个关于传输层保护不足的完整页面。
为什么传输层保护不足是危险的?
如果你没有充分保护你的传输层,那么熟练的黑客就很容易使用中间人攻击等技术截获你的用户和你的应用程序之间流动的信息。这种窥探最危险的方面可能是,它几乎完全看不到任何内部网络安全平台或扫描,因为它发生在你的网络和你的控制之外。
例如,在Docker环境中部署一个Nginx服务。
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:*default-resources_policy
Nginx服务配置不会对连接进行加密或保护,使得通过该链接交换的所有信息容易受到各种攻击或窥探。
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;
}
}
很多时候,有人可能通过你的传输层进行窥探的第一个信号是,大量被盗的用户密码被用于后续攻击。如果其他数据,如客户信息、财务记录或重要的公司机密通过不安全的传输层被盗,你甚至可能永远不会意识到你已经被破坏了。
而且,需要保护的不仅仅是用户和应用程序之间的传输层。在后端,许多应用程序彼此之间以及与工作流程中更远的服务器进行通信。虽然这些内部通信通常不容易被外界窥探,但它会将数据暴露给那些可能被允许进入网络但未被授权查看某些高度保护或敏感信息的用户。
妥善保护传输层,实现全面数据保护
保护传输层最好是在创建应用程序时进行。这个过程从拥有一个安全的后端基础设施开始。对于网站来说,一切都应该使用HTTPS来完成。切勿混合使用HTTP和HTTPS基础设施。你甚至应该将你的网站设置为自动将不安全的HTTP请求转到HTTPS基础设施上。
在上面的例子中,保护传输层的正确方法是。
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;
}
}
在这个例子中,所有与Nginx服务的连接都是强加密的。Nginx配置的服务器部分只包括listen 8443 ssl ,以便强迫SSL保护连接。
为了保护你的数据免受内部威胁,开发人员应该采用强大的传输层加密协议,如TLS 1.2。一旦你有了TLS 1.2或其等同物,像SSL v2这样较弱的协议应从你的基础设施中完全删除,并自动禁止使用。
并始终牢记,只有在静态数据和传输层得到充分保护时,才能确保应用程序的安全。这样,你就可以保证对内部数据和流向授权外部用户的数据进行完整的端对端保护。
。 Secure Code Warrior博客页面,了解有关这一漏洞的更多见解,以及如何保护你的组织和客户免受其他安全缺陷的蹂躏。你也可以尝试演示一下Secure Code Warrior 培训平台,以保持你所有的网络安全技能得到磨练和更新。
Matias Madou, Ph.D.是一位安全专家、研究员和CTO,也是Secure Code Warrior 的联合创始人。Matias在根特大学获得了应用安全的博士学位,主要研究静态分析解决方案。后来他加入了美国的Fortify公司,在那里他意识到,仅仅检测代码问题而不帮助开发人员编写安全代码是不够的。这激发了他开发产品的热情,帮助开发人员,减轻安全的负担,并超越客户的期望。当他不在办公桌前作为Awesome团队的一员时,他喜欢站在舞台上,在包括RSA会议、BlackHat和DefCon等会议上发表演讲。
点击下面的链接,下载 PDF 格式的单页资料。
下载Secure Code Warrior 我们在这里为您的组织提供服务,帮助您在整个软件开发生命周期中确保代码安全,并创造一种将网络安全放在首位的文化。无论您是应用安全经理、开发人员、CISO或任何涉及安全的人,我们都可以帮助您的组织减少与不安全代码有关的风险。
查看报告预定一个演示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。
马蒂亚斯拥有根特大学的计算机工程博士学位,在那里他研究了通过程序混淆来隐藏应用程序的内部工作的应用安全。
如果你是一名开发人员,想了解更多关于在你的组织中开始部署安全的基础设施即代码(IaC)的步骤,那么你就来对地方了。这是我们IaC系列的下一章,旨在提高你的IaC安全最佳实践水平。
在我们开始之前,你在上一期的挑战中表现得如何?如果你已经掌握了不安全的加密技术,在我们深入讨论细节之前,让我们看看你在传输层保护不足的情况下是如何进行的。
想了解更多并取得满分吗?请继续阅读。
在上一篇文章中,我们谈到了拥有安全加密技术以保护应用程序和程序所存储的任何重要或个人数据的重要性。如果你有强大的加密技术,它就可以作为一个完美的最后一道防线。即使攻击者能够窃取这些数据,如果它是强加密的,那么锁定在这些文件中的信息仍然受到保护。
然而,保护静止的数据只是完整的数据防御的一部分。每当有效的用户需要访问受保护的数据时,必须将其发送给他们。有时,应用程序也会与其他程序共享数据,作为整个工作负载的一部分。除非传输层受到保护,否则会使其容易受到外部窥探和未经授权的内部查看。因此,传输层保护不足会导致严重的问题。
这是一个常见的问题。OWASP安全组织甚至维护了一个关于传输层保护不足的完整页面。
为什么传输层保护不足是危险的?
如果你没有充分保护你的传输层,那么熟练的黑客就很容易使用中间人攻击等技术截获你的用户和你的应用程序之间流动的信息。这种窥探最危险的方面可能是,它几乎完全看不到任何内部网络安全平台或扫描,因为它发生在你的网络和你的控制之外。
例如,在Docker环境中部署一个Nginx服务。
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:*default-resources_policy
Nginx服务配置不会对连接进行加密或保护,使得通过该链接交换的所有信息容易受到各种攻击或窥探。
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;
}
}
很多时候,有人可能通过你的传输层进行窥探的第一个信号是,大量被盗的用户密码被用于后续攻击。如果其他数据,如客户信息、财务记录或重要的公司机密通过不安全的传输层被盗,你甚至可能永远不会意识到你已经被破坏了。
而且,需要保护的不仅仅是用户和应用程序之间的传输层。在后端,许多应用程序彼此之间以及与工作流程中更远的服务器进行通信。虽然这些内部通信通常不容易被外界窥探,但它会将数据暴露给那些可能被允许进入网络但未被授权查看某些高度保护或敏感信息的用户。
妥善保护传输层,实现全面数据保护
保护传输层最好是在创建应用程序时进行。这个过程从拥有一个安全的后端基础设施开始。对于网站来说,一切都应该使用HTTPS来完成。切勿混合使用HTTP和HTTPS基础设施。你甚至应该将你的网站设置为自动将不安全的HTTP请求转到HTTPS基础设施上。
在上面的例子中,保护传输层的正确方法是。
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;
}
}
在这个例子中,所有与Nginx服务的连接都是强加密的。Nginx配置的服务器部分只包括listen 8443 ssl ,以便强迫SSL保护连接。
为了保护你的数据免受内部威胁,开发人员应该采用强大的传输层加密协议,如TLS 1.2。一旦你有了TLS 1.2或其等同物,像SSL v2这样较弱的协议应从你的基础设施中完全删除,并自动禁止使用。
并始终牢记,只有在静态数据和传输层得到充分保护时,才能确保应用程序的安全。这样,你就可以保证对内部数据和流向授权外部用户的数据进行完整的端对端保护。
。 Secure Code Warrior博客页面,了解有关这一漏洞的更多见解,以及如何保护你的组织和客户免受其他安全缺陷的蹂躏。你也可以尝试演示一下Secure Code Warrior 培训平台,以保持你所有的网络安全技能得到磨练和更新。
目录
Matias Madou, Ph.D.是一位安全专家、研究员和CTO,也是Secure Code Warrior 的联合创始人。Matias在根特大学获得了应用安全的博士学位,主要研究静态分析解决方案。后来他加入了美国的Fortify公司,在那里他意识到,仅仅检测代码问题而不帮助开发人员编写安全代码是不够的。这激发了他开发产品的热情,帮助开发人员,减轻安全的负担,并超越客户的期望。当他不在办公桌前作为Awesome团队的一员时,他喜欢站在舞台上,在包括RSA会议、BlackHat和DefCon等会议上发表演讲。
Secure Code Warrior 我们在这里为您的组织提供服务,帮助您在整个软件开发生命周期中确保代码安全,并创造一种将网络安全放在首位的文化。无论您是应用安全经理、开发人员、CISO或任何涉及安全的人,我们都可以帮助您的组织减少与不安全代码有关的风险。
预定一个演示下载