CERN hosts hundreds of web servers, thousands of websites and more than a million webpages. Most of them work and have a well-defined purpose, many are sleek and well done, modern or fancy, some are a bit 90s style, and some are outdated or obsolete. While the aesthetics can be discussed, disputed and depend strongly on subjective tastes, there are certain ground rules that all web servers, websites and webpages should follow – not on the surface but more “under the hood”. Some beauty is also appreciated there.

So, to all you webmasters here at CERN, think of your favourite webpage that you manage and maintain. Does your webpage’s name make sense and is it sufficiently short and meaningful? What if I use the associated IP address instead – do I get the same content? And if I browse to a subpage, any subpage, do I get some meaningful content even if I misspelled the full URL (the webpage’s full path)? Does your webpage catch errors appropriately and redirect accordingly (e.g. no pages that don’t exist, requiring authentication or where access is plainly forbidden)? What about certificate errors? Or any other error or debugging message? Do you redirect to HTTPS, in particular when hosting sensitive and access-protected content?

If you answered “no”, “don’t know”, “dunno”, “???”, or if you shrug, facepalm or twitch, the time has come to check! Make sure that you have a proper landing page or, if you don’t think that you can have one, make sure that you redirect to, e.g., cern.ch. Configure the standard 401, 403 and 404 error messages in order to avoid disclosing error or debug information. If your page runs JavaScript, PHP or any other web content management software, catch any other error messages and make sure that they are not displayed to the end user. Similarly, remove all default information like Apache default pages or Tomcat default webapps, webinfo pages and other modules and options that are not necessary to provide the intended content. Redirect from HTTP (port 80/tcp) to HTTPS (port 443/tcp) to make sure that confidentiality and integrity are preserved. Make sure that the server doesn’t support outdated encryption protocols like SSL or TLS versions older than version 1.2. Make sure that the site’s certificate is valid, trusted and not expired. And don’t forget the software running on the server. It should be developed with care and work with the server settings providing the required security features, like proper logging and error handling.

While overlooking any of these settings is not security-critical by itself, attackers might still get the impression that the overall set up is sub-optimal or mediocre and decide it’s worth poking deeper (see our article on a “Digital Broken Windows Theory”. It also shows a lack of professionalism and puts CERN in a bad light. Hence, check your web server, website or webpage once more, and pimp it up. Fix those issues. Beautify it, also under the hood. Take advantage of external guidance. For example, CIS offers free benchmarks to harden not only the underlying operating system, but also several web server software and versions. Qualys SSL Labs provides a few SSL/TLS configuration analyses. And you can also check out the OWASP cheat sheet series for more specific hands-on guidance on web development. Finally, have a look, too, at our more general recommendations for software developers and webmasters. Or, as always, reach out to us for help or advice or to request an independent look and security check: Computer.Security@cern.ch.   

Do you want to learn more about computer security incidents and issues at CERN? Follow our Monthly Report. For further information, questions or help, check our website or contact us at Computer.Security@cern.ch.