Information Gathering and Configuration Management

This is the second post of the series about the checklists for web application pentests. In the previous post, we share the checklist to learn the application in detail. In this time, the checklist we share is about gathering more information on the application and trying to find out the weaknesses and vulnerabilities on the configurations of the application.

Most of the time the configurations of the web application and the server are being into the second plan. The application and the server is configured once to get the application commissioned, and never reconfigured for the security purposes. Wrong configurations may cause information leakages or access violations as well.

Here is the checklist for information gathering and configuration management controls:

1. Minimum Information Principle Tests:
   • The application should provide minimum information, especially in warning messages. For example
     • The message should be “Invalid username and password” instead of “Invalid username” or “Your password should be 6 characters length”.
   • Not only the messages but also the message pages should provide the minimum information. A few bad examples are as follows:
     • http://www.foo.com/err.jsp?User=baduser&Error=0
     • http://www.foo.com/err.jsp?User=badpassword&Error=2
   • Examine hidden fields carefully if they have sensitive data.
   • Examine responses of the application if they include the information about the technology used. There might be some headers into the responses like
     • X-Powered-By: ASP.NET
     • X-AspNet-Version: 2.0.50727
2. Help pages:
   • Member-specific help pages have to be shown only for the registered users. These pages may contain sensitive data.
3. SSL Usage:
   • Applications which have user interaction should serve over SSL.
   • Server SSL certificate has to be approved by a registered certificate authority.
   • The previous versions of SSL 3.1 and TLS 1.1 have known vulnerabilities, so to connect with previous versions shouldn’t be allowed by server.
4. HTML comment lines:
   • Comment lines may contain sensitive data and should be checked carefully. For example, developer may put a credential inside the code for testing and he may comment out the credential info instead of deleting it before the application goes live.
5. Restriction of server data:
   • Most of the time information about the server is given especially in the error pages (the pages with the response codes of 400s or 500s) which doesn’t comply with the minimum information principle.
   • Check if there are “server” headers in responses.
6. Backup and forgotten files:
   • Developers want to backup the files before a major update. Because these kinds of files are created in development phase, they may contain critical information. Find out these files and examine it carefully.
7. Management Console Access:
   • Examine if there are pages such as
     • http://theSite.com/admin
     • http://theSite.com/manager. Because these kinds of pages are high-privileged pages, they have to be scanned carefully.
   • Management consoles and the links to access them can be served in a different port. Try different port as well.
8. Supported HTTP methods and XST vulnerability:
   • There are different HTTP request methods such as ADD or UPDATE. These methods are dangerous for the application. Use OPTION method to find out the methods supported by the server. If the OPTIONS method restricted, use TELNET or automatic scanning tools to find out the supported methods.
9. Known vulnerabilities:
   • Application server, programming language, frameworks, technologies should be searched according to their versions if there are known vulnerabilities for them. If there are, related component has to be updated immediately.
10. Collecting emails:
    • Directly added email addresses are collected by automated tools to use in spam email lists. To avoid this, email addresses should be given in a different format such as “abc at gmail dot com”.

The next post for web application pentest checklists will be about the authentication mechanism.