Hackers frequently use publicized security vulnerabilities, especially zero-day vulnerabilities—security flaws that have been made public in the last 24 hours. When someone publishes a zero-day vulnerability for a software component, hackers will immediately scan for web servers running the vulnerable software in order to exploit the security hole.
To protect yourself from such threats, you should ensure that your web server doesn’t leak information about the type of software stack you’re running on. If you inadvertently advertise your server technology, you’re making yourself a target.
In this article, you’ll learn some common ways web servers leak information about your technology choices and how to mitigate each of these risks.
Mitigation 1: Disable Server Headers
Make sure to disable any HTTP response headers in your web server configuration that reveal the server technology, language, and version you’re running. By default, web servers usually send a Server header back with each response, describing which software is running on the server side.
This is great advertising for the web server vendor, but the browser doesn’t use it. It simply tells an attacker which vulnerabilities they can probe for. Make sure your web server configuration disables this Server header.
Mitigation 2: Use Clean URLs
When you design your website, avoid telltale file suffixes in URLs, such as .php, .asp, and .jsp. Implement clean URLs instead—URLs that do not give away implementation details. URLs with file extensions are common in older web servers, which explicitly reference template filenames. Make sure to avoid such extensions.
Mitigation 3: Use Generic Cookie Parameters
The name of the cookie your web server uses to store session state frequently reveals your server-side technology. For instance, Java web servers usually store the session ID under a cookie named JSESSIONID. Attackers can check these kinds of session cookie names to identify servers.
Note that the Metasploit code checks the name of the session cookie. Make sure that your web server sends nothing back in cookies that give clues about your technology stack. Change your configuration to use generic names for the session cookie (for example, session).
Mitigation 4: Disable Client-Side Error Reporting
Most web servers support client-side error reporting, which allows the server to print stack traces and routing information in the HTML of the error page. Client-side error reporting is really useful when debugging errors in test environments.
However, stack traces and error logs also tell an attacker which modules or libraries you’re using, helping them pick out security vulnerabilities to target. Errors occurring in your data access layer can even reveal details about the structure of your database, which is a major security hazard!
You must disable error reporting on the client side in your production environment. You should keep the error page your users see completely generic. At most, users should know that an unexpected error occurred and that someone is looking into the problem.
Detailed error reports should be kept in production logs and error reporting tools, which only administrators can access. Consult your web server’s documentation on how to disable client-side error reporting.
A related tool is an obfuscator, which replaces method and function names with short, meaningless tokens without changing any behavior in the code, deliberately making the code less readable. The popular UglifyJS utility has both capabilities, and can be invoked directly from the command line with the syntax uglifyjs [input files], which makes it straightforward to plug into your build process.
Suggested Read: A to Z – Web Vulnerabilities Index – OWASP Standard
Mitigation 6: Sanitize Your Client-Side Files
This is often a first port of call when a hacker is attempting to compromise your website.
Stay on Top of Security Advisories
Even with all your security settings locked down, a sophisticated hacker can still make a good guess about the technology you’re running. Web servers have telltale behaviors in the way they respond to specific edge cases: deliberately corrupted HTTP requests or requests with unusual HTTP verbs, for example.
Hackers can use these unique server-technology fingerprints to identify the server-side technology stack. Even when you follow best practices regarding information leakage, it’s important to stay on top of security advisories for the technology you use and deploy patches in a prompt manner.
You should ensure that your web server doesn’t leak information about the type of software stack you’re running on, because hackers will use this information against you when trying to figure out how to compromise your website. Make sure your configuration disables telltale headers and uses a generic session cookie name in the HTTP response.