A few days ago we posted the first of our free checklist series, a checklist for auditing Web Applications. Over the next two weeks we will provide some high level guidance on how to use that checklist in your organization to test the security of your applications!
While there are plenty of things that can go wrong within the web application code itself, it is still very important to ensure that our application is residing on a firm foundation. This is where the basic configuration of our web service comes in. You may want to follow along with the checklist that we’ve released since that will be the outline of what we will discuss in this series!
The first thing that we need to verify is that all of the default and sample content has been removed. In fact, if you’re using a Microsoft IIS server we would go so far as to recommend that the default site has been disabled and a new site has been created to house your application, which is a best practice recommendation for IIS deployments. The reason for this is that practically every piece of sample code deployed with web services is a perfect example of how to write vulnerable code! This means that our server itself is hosting vulnerabilities which might be used to leverage access into our well written application.
The next thing to check is whether or not directory indexing has been disabled. When directory indexing is enabled (which might be intentional!!! Evaluate the context of where it is used…) the contents of the directory will be displayed rather than a not-authorized or page-not-found message when there is no index.html or default.htm page available.
This may not seem to be a very serious issue, but it actually is. If you notice the sample above you’ll see that the directory indexing might disclose information that should not just be publicly available. In this case, aside from the files (which we will assume should be available), we have all kinds of information disclosed about the web server itself, including version information, plugins, etc.
This option and all other security options available for the particular server that your organization is running need to be compared to the deployment standards within the organization. For instance, what types of code may be hosted on the site? What sorts of configuration options are there for sanitizing the web server headers? Is there a security configuration document available for this server that can be used to create a baseline for the security stance of the server? There are actually some great resources available for both Microsoft and Apache, the top web servers in use today.
Our next step would be to verify that the architecture of the infrastructure actually supports the information security requirements of the data being protected. This is a topic deserving of deep discussion and is something that is often not done well in organizations today. If you need help with this you may want to have a look at this class which goes into depth on how to do this and how to verify that the architecture is correct.
The final step in verifying our basic configuration is to use at least one scanning tool to examine the configuration of the service. Some good tools to consider here on the inexpensive or even free side are things like Nikto or Wikto or perhaps even NStealth.
This is just one of the many topics discussed and taught hands on in David Hoelzer’s class, “Advanced System & Network Auditing”, available through The SANS Institute. David is a Senior Fellow with The SANS Institute and the principal examiner for Enclave Forensics. You can find a variety of topics on his blog.