nginx 自定义 header

$http_HEADER
The value of the HTTP request header HEADER when converted to lowercase and with 'dashes' converted to 'underscores', e.g. $http_user_agent, $http_referer...;


地址:http://wiki.nginx.org/HttpCoreModule#.24sent_http_HEADER


原文地址:http://blog.csdn.net/rubenyu/article/details/6721910







上周末收到安全组童鞋的邮件,说是输出的时候有安全缺陷. 表现是在IE8之下,如果内容中有脚本的话,就会被直接执行掉,那么如果有攻击代码,这就杯具了…. 之所以会在IE8之下出现这个问题,是因为IE8似乎支持个什么mhtml.可以直接解读一些base64之后的内容,同时还能解读邮件头,导致邮件头不能被显示.

查了下google的实现,是加入了如下的三个header:

X-Content-Type-Options nosniff;

X-XSS-Protection “1; mode=block”;

X-Frame-Options SAMEORIGIN;

于是我就想加到我们的webpy中去….刷新,没反应,再刷新,还是没反应….

没刷几下,hoho,下班喽…

早上来了之后,开始追flup的源码,发现flup中的response都是正常的.

对了,这里还有两个tips需要记下来备忘:

1. 在我们的包里面flup是个egg,想玩,肯定得将它解开,于是unzip一下egg,可以得到一个可以debug的文件夹.这时候最好删除egg,我没测试这时候到底是谁生效.

2. 我们的组合是webpy+flup,使用的是flup的WSGIServer,读了部分WSGIServer的源码之后,里面有debug开关.打开的方法是:

from flup.server import fcgi_base

fcgi_base.DEBUG = 9

然后,在那个打开的包里面就可以用 _debug([0-9], msg) 这样的格式输出了.

默认情况下,log放在/tmp/fcgi.log中. 我放的DEBUG是9,貌似是里面最大的数字了,当然,越大信息越详细啦.

言归正传,我追阿追阿追,就是查不到原因,问了master dy,大师让我干脆给nginx.conf加配置,于是出现了这段:

[python] view plaincopyprint?
location ~ /downloads/ { 
            add_header XContent-Type-Options nosniff; 
            add_header X-XSS-Protection "1; mode=block"; 
            add_header X-Frame-Options SAMEORIGIN; 
            root blablabla; 
            internal; 
        } 
这样是可以解决问题了.

但是为啥nginx就不肯输出呢?于是追阿追阿追 发现在nginx源码中有这么一个filter(src/http/ngx_http_header_filter_module.c):

存在一个:ngx_http_header_filter方法,里面是重新构造的header从441行开始,一点一点的加…. 到了576行,似乎是要加入用户自定义的header了.但是,通过debug,再次发现思路不对.

最终的解决方案还是add_header(感谢宋老师陪我查了一上午).

我猜这个杯具的原因应该是因为nginx想让输出更加标准和安全些,最安全的方法就是”白名单”…

猜你喜欢

转载自wangxiaoxu.iteye.com/blog/2116551