原文来自：https://www.nginx.com/blog/nginx-app-protect-1-0-released/进行数字化转型的公司有明确的业务需求。其中包括改善现代业务应用程序的客户体验，采用敏捷实践以超越市场竞争对手，以及利用市场优势来推动新的收入来源。支持这些工作的是新的应用程序体系结构，这些体系结构可提高开发效率并结合了容器，微服务和API。对于现代应用程序，敏捷性和上市时间至关重要。安全通常是次要的考虑因素，或者被完全忽略。为什么？传统应用程序的安全控制并不总是能很好地映射到业务需求。例如，通常由SecOps团队配置和操作的那种复杂的Web应用程序防火墙（WAF）通常不太适合由DevOps团队支持特定业务线部署的敏捷应用程序。结果可能是安全性不足或配置错误，上市时间延迟以及不良的用户体验。推出NGINXAppProtectNGINXAppProtect是一种新的应用程序安全解决方案，它将先进的F5WAF技术的功效与NGINXPlus的敏捷性和性能相结合。该解决方案在NGINXPlus上本地运行，并解决了现代DevOps环境面临的一些最困难的挑战：将

由于NGINXPlus在MQTT客户端与Broker的交互过程中处于一个核心代理的位置，我们可以很容易的在其原生的代理功能基础之上加入安全访问控制功能。0x01为什么需要访问控制对于一些MQTT的客户端，不管是消息的发布者还是订阅者，都有可能会使用贪婪模式，频繁的与MQTTBroker进行通信，并发布或获取大量数据。此时，MQTTBroker的通信信道会被这种客户端应用占用，导致服务降级。遇到这种类型的客户端，由于MQTTBroker原生并没有很好地限制机制，从而需要借助在NginxPlus的代理上面，进行配置，识别并限制过度的数据访问。0x02如何进行访问控制使用NginxPlus进行访问控制很简单，和HTTP协议的访问控制类似。0x03访问日志处理使用NginxPlus还可以自定义日志格式，通过与告警平台和自动化平台对接，可以有效识别异常客户端的通信，可以进行自动化的IP封禁以及限连和限流操作。至此，我们4节NGINXPlus在IoT场景中的应用已经告一段段落，希望大家喜欢本次的分享。参考：https://dzone.com/articles/mq

最近有朋友给我发来一个漏洞扫描报告，其中有一项是“Nginx头部攻击漏洞”在绿盟的报告中，可以看到，头部攻击是指，httphostheader头中的HTTP_HOST不可靠，所以，如果后端开发代码中，通过类似PHP中的_SERVER["HTTP_HOST"]来获取host信息，那可能获取到的不是自己站点的host信息，这里简单做个复现环境：NginxPHPBrupsuite复现方法很简单，在Nginx中配置一个虚拟主机站点，用php-fpm处理php，在php中写一小段代码，通过_SERVER['HTTP_HOST']获取host并打印，用Brupsuite篡改host信息，环境搭建信息这里就不多说了，直接看Brupsuite过程，PHP代码如下：接着启动Brupsuite，配置代理浏览器设置代理到burp接着通过浏览器请求上面nginx配置的server，在burp抓包，接着action——SendtoRepeater，我们先看正常的返回接着，通过burp改header中的host，模拟攻击，看结果可以看到，php拿到的就不是我们自己的host信息，所以，这里会把恶意代码传过