When deploying an application, make sure to use the correct set of configuration settings in your deployment scripts.

Configuration is an essential part of every application. Misconfiguration can happen at any level of the application stack – from code, to web and application servers, to databases and frameworks. Below, I’ve compiled a list of some of the most common scenarios.

Deployment of development configuration to production

Development configuration can include tracing, unencrypted string connections, test accounts with a weak password, descriptive error messaging, and more. A malicious attacker will be able to use tracing or error messaging to gain access to insecure accounts, compromising the application. When deploying an application, make sure to use the correct set of configuration settings in your deployment scripts.

Failure to secure directories

Protected or private directories are directories that are available only to confirmed application users, admins, or to the application’s code. Protected directories might include sensitive information in the form of files and images, or an account control panel.

Third-party applications installed on a production server

A production server that has additional applications installed on it often poses a security risk. Some applications have their own vulnerabilities and known exploits. For example, some applications might need to use a port in the firewall that otherwise might be blocked. Rather than trying to attack your application directly, a clever attacker may fish for known holes in other applications which they guess might reside on your server. You can do everything right, but your server is only as secure as your least secure application.

Web serving source files

A web server that is not configured to run a technology in a desired endpoint might serve the file back to the client instead of executing it. This can include compiled class files, PHP code and more. Once a hacker has access to your source code, they will be able to access any aspect of your application stack.

You should always modify every default account on all applications and servers.

Directory listings enabled

With directory listing enabled, an attacker can view all of the files on your web application. This can lead into sensitive files that are not linked from the application, viewed by the client. Even if the file itself cannot be accessed, the mere presence of that file – or the file’s name – may give the attacker damaging information about you or your site.

Default accounts are not changed

If your default account is admin or test, and you left your password as password, an attacker can easily guess them and log on to the application. You should always modify every default account on all applications and servers.

Misconfigured firewalls

A firewall that allows more ports than necessary to be open, or allows unauthorized hosts to connect to the server, can result in an attacker gaining control over the server. For example, a database server that requires an open port in order to execute queries from the web server may neglect to restrict access to the open port. In that case, any attacker can then connect to that port and attack the database, using brute force techniques.

Missing OS security patches

Neglecting to update your OS will result in an attacker utilizing security holes to gain control over your server. It is recommended to apply critical security patches immediately and have a regular maintenance interval for all OS updates. Regular updates should be tested in development before deployment to production to insure application compatibility. Remember, if your OS or application vendor sends you a security patch, by definition, it’s known to the world. Leaving a security patch un-applied is an invitation for exploitation.

Misconfiguration is a part of the OWASP top 10 most critical applications security risks.

Conclusion

Misconfiguration is a part of the OWASP top 10 most critical applications security risks. Calavista rigorously manages configuration and security on our projects – as all reputable software development shops should. When hiring a software development group, ask them hard questions about how they manage security issues – both during development and in the deployment phase. A good shop should be able to answer that question without hesitation. Beware of the deer-in-the-headlights look.