Nginx directive server_tokens don't hide Server header with information about Nginx and Passenger version.

What steps will reproduce the problem? 1. Install nginx use passenger-install-nginx-module 2. Insert directive "server_tokens off;" to nginx.conf (http section) 3. Restart nginx 4. Open page in FF (+FireBug) and check Server header

What is the expected output? What do you see instead? Now I see:

Server: nginx/0.6.36 + Phusion Passenger 2.2.2 (mod_rails/mod_rack)

I don't want everyone to see that information.

What version of Phusion Passenger are you using? Which version of Rails? On what operating system?

OS: Ubuntu Server 8.10 Rails 2.2.2 Passenger 2.2.2 Ruby: ruby 1.8.6 (2008-08-11 patchlevel 287) [i686-linux] Ruby Enterprise Edition 20090421

Please provide any additional information below.

Also I want to hide X-Powered-By header, I known what I can hide it in Apache, but I don't known how to hide that header in nginx.

This is still an issue with the more current version 2.2.11, I haven't tried the last version, but since this issue didn't show up in the changelogs, I'm assuming it's an issue there too,

OS: Debian 5.0 Rails: 2.3.8 Passenger: 2.2.11 Ruby: ruby 1.8.7 (2009-12-24 patchlevel 248) [x86_64-linux], MBARI 0x6770, Ruby Enterprise Edition 2010.01 nginx: 0.7.65

Same issue, can't hide nor modify the server output string. Passenger totally ignores custom strings even when nginx is built from source as well as the server_tokens off; directive. I guess advertising the project is more important than security, since this defect is so lowly prioritized and nothing has been done about it for some time.

OS: Ubuntu 10.04 LTS Rails: 2.3.8 Passenger: 2.2.15 Ruby: ruby 1.8.7 (2010-01-10 patchlevel 249) [i486-linux] nginx: 0.7.67

I cannot understand why phusion guys don't fix it? Are you crazy or what? The solution for other people who do not want to show that info:

Just install 3rd party ngx_headers_more: http://github.com/agentzh/headers-more-nginx-module (you have to rebuild it from source). Add to your config (I created /etc/nginx/conf.d/security.conf for it): server_tokens off; more_clear_headers 'Server' 'X-Powered-By' 'X-Runtime';

And your headers don't appear anymore.

Btw, many sites still exposes it's nginx and passenger version. It's not secure and the blame goes to phusion guys (sorry but it's true).

Examples:

$ curl -I http://www.soup.io/ | grep -i 'server\|x-powered' $ curl -I http://www.scribd.com/ | grep -i 'server\|x-powered' $ curl -I http://www.shopify.com/ | grep -i 'server\|x-powered' $ curl -I http://gist.com/ | grep -i 'server\|x-powered'

radek, we have never said that we aren't willing to fix it. Nor are we crazy. If there are security flaws then we are committed to fixing them quickly, in which case users should upgrade as soon as possible. Hiding the version number is security through obscurity. It does not give you any kind of real security: any potential exploit will still exist irregardless of the display of this header, and a committed attacker can ignore the header and still try to execute the exploit on your website. Being able to see the version number might be an extra incentive for users to upgrade ASAP instead of sticking to the old version. Given this perspective, it's not hard to see that hiding the version number might easily give one a false sense of security.

That said, Phusion Passenger 3 (Nginx version) will provide a configuration option passenger_show_version_in_header which you can turn off to hide the version number. However we still strongly suggest that you upgrade ASAP instead of relying on this hiding ability as a real security feature.

P.S. In the 2.5 years that Phusion Passenger has existed nobody has found a critical security flaw in Phusion Passenger...

Hi Hongli,

Leaving aside the security argument (I agree), many of us would like to shut off the Passenger announcements altogether. It seems you're really committed to advertising Passenger in the headers. :) Nonetheless, can you add an option to eliminate them, not just hide the version?

thanks.

Comment deleted

radek.bulat: you might want to stop using a browser as well if you truly belief that. Between you and me, it unveils its user agent and version number as well by default. Even though some browsers like firefox allow you to edit it, I think very few people actually do. I'm pretty sure that the security issues concerning browsers are not really related to the user_agent string though but more with the users using the browser.

jeremywohl: To answer your question: you can easily do this yourself by grepping on the header string and removing the occurrences. Having said that, why would you want to remove it? Does it affect your website in any way? No one seems to have yet given a rational answer to this. From our perspective however, we believe its part of the branding of the product and don't intend on removing it unless it truly poses threat in some way. From a security point of view however, as Hongli explained, we don't believe it makes it any safer by removing it. Hope that answers your question.

Actually, branding is exactly why I want these headers removed, rather than a technical argument. I'm trying to shape and brand my service precisely and I don't want your advertising on my port. :)

Why would you stand in the way of 25 users watching this bug and the "off" equivalent available in every web server?

(Yes, I currently munge the headers, after the fact, but I'd appreciate an off option.)

I have to chime in with my 2 cents as one of the 25 users watching this bug (and I am watching it simply out of curiousity; I used to want the feature but now I am indifferent).

Quite simply, this is open source software and I think the authors do deserve some branding. If it matters that much to one, one can do the little bit of coding it takes to remove the header. It's much better than the alternative which is to code a whole VM had the authors not released their work for free.

This absolutely should be able to be turned off. I don't agree with anybody that says it's appropriate for branding. This is absolutely considered information leakage. This also causes pentest failures on a variety of tools. I'm not sure how anybody can consider this to not be serious? Perfect example: the nginx security flaw noted here: http://nginx.org/en/security_advisories.html

As as customer of passenger enterprise, this is an absolute must-fix as due to the level of security, compliance, and audits involved with our business we are unable to use passenger enterprise in production.

Such flaws are defined in:

CWE-526: http://cwe.mitre.org/data/definitions/526.html

OWASP: IE-004: https://www.owasp.org/index.php/Testing_for_Web_Application_Fingerprint

WASC-14: http://projects.webappsec.org/w/page/13246959/Server%20Misconfiguration