一、背景

        最近我们被安全部门的漏洞扫描工具扫出了一个服务端口的漏洞。这个服务本身是一个Django启动的web服务，并且除了登录页面，其它页面或者接口都需要进行登录授权才能进行访问。

        漏洞扫描信息和提示修复信息如下:

        自然这些漏洞如何修复，很简单，搜索下资料可以先临时替换补丁代码，最后重启服务即可。 但是从我们修复完毕以后，让安全部门继续扫描了几次，还是能扫出这几个漏洞。这十分奇怪。

        这就很奇怪了。  奇怪的第一点就是， 这个安全扫描工具只是通过端口的方式就能知道我后端是用什么编程语言实现的(python)、并且还能知道python的版本信息。心想你一个安全扫描工具再怎么神通广大，也不会猜得这么精准吧。

        由此，我先排查了一下，除了login接口，其它接口都是需要登录授权的，因此页面暴露基本上不存在这种可能性。 那请求页面/接口内容不存在泄露风险，那么只是剩下HTTP响应头的信息了。刷新页面查看HTTP响应头的信息，果不其然，server响应头暴露了关键信息:

     Server: WsGIserver/0.2 cPython/3.9.13

        果不其然，暴露了后端的实现。 WSGI  Python是3.9.13版本。  安全扫描工具应该是基于这个信息，推断， 你的站点存在Python3.9.13之前存在的一些漏洞风险提示。 其实仅仅只是提示，因为安全扫描工具是基于这个信息给出的推断。 所以即使你修复好了补丁，但是这个消息还是暴露，导致它一直判断你没有修复漏洞或者升级Python版本。

二、解决方案

1、安全原则

        基于安全原则， HTTP服务器的响应信息应该屏蔽Server字段， 避免被攻击者扫描出相关后端实现以及版本信息，从而造成安全隐患

2、Django屏蔽Server响应头

         知道了原因我们就能对症下药，屏蔽Server响应头信息即可。这里有2种方式实现, 修改完毕后需要重启服务.

1、Django默认存在Server响应头信息

        默认Django是存在这个Server响应头的:

        

2、修改Lib/wsgiref/handlers.py

修改后查看效果:  

3、新增middleware中间件进行处理

setting.py新增中间件信息

修改后的查看效果:

3、总结

        安全原则再次强调， HTTP响应头信息不要暴露任何后端相关实现以及版本信息，否则会被攻击者进行漏洞扫描或者注入，存在安全隐患!!!  这个一点必须时刻谨记!!!

        这次运气好是安全扫描测试，下次可能就是攻击者利用该漏洞进行破坏了。