I don't want the server type to be shown in the response headers.
I've tried to add this to httpd.conf, as I saw in many answers:
ServerSignature Off
ServerTokens Prod
But I still see "Server: Apache" in the response:
Can I remove the "Apache" from the response?
Update
Also tried this:
LoadModule headers_module modules/mod_headers.so
Header unset Server
Header unset X-Powered-By
But I got the same response.
You cannot remove the header Server: Apache unless you modify the source code and recompile Apache. And if you do, still it may be not so difficult to find out which server software you are running.
Make a search for "webserver fingerprinting", you will find about HTTP header response ordering, answers to malformed requests and other ways to discover which server you are running. Spend your time securing your application instead of trying to achieve this obfuscation.
From Apache doc:
Setting ServerTokens to less than minimal is not recommended because
it makes it more difficult to debug interoperational problems. Also
note that disabling the Server: header does nothing at all to make
your server more secure.
Related
How to change Apache's Server: header without mod_security?
I do not want to use mod_security because I don't have anything else to do with it. And it is a useless overhead for me.
Instead, what should I change in the Apache's source? I usually use Apache compiled from source.
I am using Apache version 2.4.46.
To change Apache's Server: header, change the following in the source code:
Change the file /path/to/httpd-2.4.46/include/ap_release.h:
Go to the line like:
...
#define AP_SERVER_BASEPROJECT "Apache HTTP Server"
#define AP_SERVER_BASEPRODUCT "Apache"
...
And change it to anything, like:
...
#define AP_SERVER_BASEPROJECT "Apache Something My Server"
#define AP_SERVER_BASEPRODUCT "Apache My Server"
...
And then compile apache, and you are good!
Also, make sure to follow the license that is provided with it. Questions about license here are off-topic.
I understand not using mod_security to change a single header so you may want to give https://github.com/bostrt/mod_serverheader#installation a try. It's under 100 lines of code and runs one hook at startup of Apache HTTPD so very low overhead.
mod_serverheader provides a single directive that lets you completely overwrite the Server header, for example:
LoadModule serverheader_module modules/mod_serverheader.so
ServerHeader my-server
Then, when someone accesses your website they will see:
# curl -I http://example.com/
HTTP/1.1 200 OK
Server: my-server
Content-Length: 8
Content-Type: text/html; charset=iso-8859-1
I am setting Cache-Control in the httpd.conf where i also have Mellon SSO Configuration. I am getting two cache-control included in the response headers. So i have commented out the MellonEnable "info" and restarted the apache. Now my Cache-Control got reflected and now it is only mine. But this is not an exact solution to turn off/override the cache-control, so i find out that there is an option that controls whether the Cache-control header is sent back in responses in Mellon configuration.
So i have given MellonSendCacheControlHeader Off in the conf file, but the apache is throwing issue like "Invalid command 'MellonSendCacheControlHeader', perhaps misspelled or defined by a module not included in the server configuration"
Can someone help ?
Forgot to Update the Answer.
Actually the latest Mellon version 0.13.0 have the fix. Here there is a fix to "Allow disabling the Cache-Control HTTP response header". So the duplicate Cache-Control will be avoided, if we set the MellonSendCacheControlHeader Off in the conf file.
Un-install the older version of Mellon and install the version 0.13.0 and update the conf file with the configuration MellonSendCacheControlHeader Off. Restart the Apache Server once all changes done. It will work.
I've managed to extend TokenAuthentication and I have a working model when using the request session to store my tokens, however when I attempt to pass Authorization as a header parameter as described here, I noticed that my Responses come back without the META variable HTTP_AUTHORIZATION. I also noticed that if I pass "Authorization2" as a header parameter that it is visible in the request:
{
'_content_type': '',
'accepted_media_type': 'application/json',
'_request': <WSGIRequest
path:/api/test_auth/,
GET:<QueryDict: {}>,
POST:<QueryDict: {}>,
COOKIES:{
'MOD_AUTH_CAS_S': 'ba90237b5b6a15017f8ca1d5ef0b95c1',
'csrftoken': 'VswgfoOGHQmbWpCXksGUycj94XlwBwMh',
'sessionid': 'de1f3a8eee48730dd34f6b4d41caa210'
},
META:{
'DOCUMENT_ROOT': '/etc/apache2/htdocs',
'GATEWAY_INTERFACE': 'CGI/1.1',
'HTTPS': '1',
'HTTP_ACCEPT': '*/*',
'HTTP_ACCEPT_CHARSET': 'ISO-8859-1,utf-8;q=0.7,*;q=0.3',
'HTTP_ACCEPT_ENCODING': 'gzip,deflate,sdch',
'HTTP_ACCEPT_LANGUAGE': 'en-US,en;q=0.8',
'HTTP_AUTHORIZATION2': 'Token 9944b09199c62bcf9418ad846dd0e4bbdfc6ee4c',
...
My first guess is that the authorization header is being removed by apache, and I have read a few S/O questions that state that apache will throw out the value if it does not match basic authorization and authenticate, but I have no idea how to allow the Authorization header to 'pass through' to Django and the WSGIRequest. Does anyone know how to solve this problem?
I also use mod_auth_cas and mod_proxy, if that changes anything..
If you are using Apache and mod_wsgi, then I found the easy solution to this in the official Django REST framework website
Apache mod_wsgi specific configuration
Note that if deploying to Apache using mod_wsgi, the authorization header is not passed through to a WSGI application by default, as it is assumed that authentication will be handled by Apache, rather than at an application level.
If you are deploying to Apache, and using any non-session based authentication, you will need to explicitly configure mod_wsgi to pass the required headers through to the application. This can be done by specifying the WSGIPassAuthorization directive in the appropriate context and setting it to 'On'.
# this can go in either server config, virtual host, directory or .htaccess
WSGIPassAuthorization On
Sorry to answer my own question minutes after asking it. But it turns out it was apache2 after all! After crawling the webs and looking through a few search results I found this in a comment:
RewriteEngine on
RewriteCond %{HTTP:Authorization} ^(.*)
RewriteRule .* - [e=HTTP_AUTHORIZATION:%1]
Adding the above lines to my conf file seemed to solve all of my problems! Hopefully this helps users down the road!
It depends on which kind of Django/Apache deployment you did. You need to tell the correct Apache module to allow to pass "Authentication" HTTP header:
Apache/mod_wsgi:
WSGIPassAuthorization On
Apache/mod_fcgid:
FcgidPassHeader Authorization
In other words: many Apache modules filters "Authentication" HTTP header, so Django will not receive it. You have to be sure your Django App is receiving it in request.
See:
django_rest doc and Apache fcgid doc.
NOTE:
After modifying Apache configuration you'll need to restart apache daemon or tell to reload your .cgi file (i.e: touch my_site_fcgifile.fcgi).
The issue is the underscore in the HTTP header HTTP_AUTHORIZATION. Most webservers just ignores the headers with underscores.
Django dev server also exhibits the same, omitting headers with underscores.
This is the reason why Authorization2 works.
A Quick work around is to replace _ underscores in headers with - dashes,
Ex. changing the HTTP_AUTHORIZATION to HTTP-AUTHORIZATION
I'm using NSurlconnect and an NSurlrequest to get the http headers from a static txt file served from an apache server but it does not return the last modified date.
What Apache server configuration directive would prevent this or what could i have the server guys add to the configuration to enable this to show.
FYI I have tried other urls on different servers and i am able to get last-modified from them.
This turned out to be a problem with certificates and the solution was to revise the allowable canAuthentiateAgainstProtectionSpace options.
It caused me some confusion because I received a response and it allowed me to download the file even though the response was a http 401 response. once I fixed the authenificiation problem i started to get the correct 304 and 200 options back from the server along with all the expected headers
I hate to answer my own question but I think that the reason the header is not stowing last=modified is that there are .htaccess files somewhere in the configuration of the server that specify
Header unset last-Modified
or that some other mod or apache2.cnf has some other directive..
if anyone knows better please advise.
so far I developed completey locally, having everything (Apache, Openfire, JSJaC application) on my laptop, running quite fine. Now I want to use remote server for Apache/Openfire. I did basically the same steps, incl. the whole http-bind stuff. I test the setting with simpleclient.html provided by JSJaC.
Now here's the deal, if I use the simpleclient directly on the remote server - e.g., http://here.domain.org/simpleclient.html - it works. If I use it locally - e.g., http://[local_machine]/simpleclient.html - and with the same settings I get an 503 (service unavailable). It seems to be more a network/Apache issue than Openfire/JSJaC one, but I'm not an expert.
My parameters for the simpleclient:
HTTP Base: http://here.domain.org/http-bind/
JabberServer: here.domain.org
So in my apache virtual host conf file I have the lines:
AddDefaultCharset UTF-8
ProxyReqests On
ProxyPass /http-bind/ http://127.0.0.1:7070/http-bind/
So basically the http bind works since I can connect when the simpleclient.html resides on the server. What I tried so far:
checked if 7070 open from extern: yes
checked etc/hosts - here the relevant lines
127.0.0.1 localhost
123.123.123.123 here.domain.org here
checked Apache conf for restrictions: can't find any, basically i have an "Allow from all" everywhere (but I'm not completely sure where to look at)
By the way, with,e.g., Pidgin I can connect from my laptop to the remote server. Just the JSJaC simpleclient won't do. So I assume it's the http-bind that causes the trouble. I would understand if port 7070 weren't open, but it is.
Any hints or help are much appreciated!
Christian
Ok, I got it. It was a cross-domain scripting issue. I started looking into the JSJaC library and noticed that it makes XmlHttpRequests which by default won't work across different domains. I therefore had to allow this with Apache on the Openfire-Server. I added the follwing entries in the VirtualHost conf file:
Header always set Access-Control-Allow-Origin "*"
Header always set Access-Control-Methods "POST, GET, OPTIIONS"
Header always set Access-Control-Allow-Credentials true
Header always set Access-Control-Allow-Headers "Content-Type, *"
Of course the mod_headers module must be loaded for this.
I'm not sure which entries are actually required, I didn't try every combinations. I think the always is needed since the request to the http-bind address is a proxy thingy.