OWASP Top Ten Series: Security Misconfiguration

OWASPSecurity Misconfiguration 

Modern web applications are built from many different parts. There are front end components such as a web browser, a desktop application with embedded web viewer, or increasingly mobile apps to access web application functionality. There are middleware framework libraries that provide functionality that developers can use and customise, back-end database engines and file based storage repositories, plus there can be custom written code at all levels in this stack. Add in the various infrastructure needed such as web, application and database servers, plus firewalls and load balancers and you can see that there are many parts to a web application.

In the same way that a complex machine needs all of its parts to function correctly in order for it to work, the security of web applications need all component parts to be secure if overall security is to be maintained. The multiple components provide many opportunities for security misconfiguration to occur.

What is a Security Misconfiguration vulnerability? 

When any of the many components that make up a web application are not security hardened, or are configured badly, then there is a target for attackers. In order to provide a secure deployment all the component parts of a web application need to be configured correctly. Not having configuration done correctly might actually be worse than not making any changes to default settings. You’ll think a site is protected, when it actually isn’t.

Given the large number of components that are combined to deploy a web application, and the intrinsic complexity of most of these components, it won’t be a surprise that there are many ways that misconfiguration can lead to security vulnerabilities. All of which can lead to application hijacking, data loss, reputational damage, and expensive downtime.

How to protect against Security Misconfiguration vulnerabilities?

The points below outline some of the areas that should be considered when analysing your web application for potential security misconfiguration. This list is not exhaustive. Each deployment will have some unique characteristics.

  • Install latest updates and security patches. Have an easy to manage updating process with test environments to check updates before deploying to production environments. Security vulnerabilities and bugs are constantly being discovered and fixed. Operating system software, development frameworks, content delivery systems and backend systems should be kept up to date. As should Firewalls, content checkers, anti-malware systems and Load Balancers. The KEMP Web Application Firewall Pack (AFP) for LoadMaster detects and counters known vulnerabilities, including those outlined by OWASP. The AFP pack is updated constantly by KEMP security experts so that vulnerabilities developers and system administrators may not have heard about are countered.
  • Remove sample applications that ship with content delivery systems and web frameworks. Most tools that help build web applications include demo and sample code to help teach developers how to use the tools and get you started. These samples and demos should be removed. They provide a known target for anyone attempting to compromise web application security.
  • Remove unused features, plugins and web pages. Only include the parts of web applications that you need to provide your service to end users. Remove any plugins or functionality that you are not using. This reduces the target footprint for vulnerabilities.
  • Turn off access to setup and configuration pages. Don’t leave the setup and configuration pages available for users to use. Popular web application systems will be known to anyone who might want to attack your site. If they can get access to your administration console or other configuration settings they could badly compromise the site.
  • Change usernames, passwords and ports for default accounts. Web application frameworks and libraries often ship with default administration names, passwords and access ports enabled. Everyone knows these. Change all these to non standard usernames, passwords and ports.
  • Don’t share passwords between accounts on Dev, Test and Production systems. Related to the point above. Don’t use the same administration accounts and settings across your Dev, Test and Production systems. Doing so means that if one system is compromised they all are. Also don’t use the same accounts and passwords for different systems. For the same reasons.
  • Don’t rely on one layer in a web application providing security for layers lower down in the stack. Secure all layers individually. Security should be applied at all levels within an application. Don’t just assume that an authenticated user has the rights to access any data available to the web application. Always check access permissions before any data access. See the OWASP Series: Insecure Direct Object References article for more on this.
  • Make sure different teams talk to each other about security. If system administrators think that something developers are doing compromises security then this should be flagged. And vice versa of course. Everyone has a responsibility to ensure secure systems are deployed. In many deployments there will be different people from different teams who control and manage different parts of the stack that delivers the application. It’s vital that there is communication between these teams.
  • Turn off debugging so that internal info isn’t sent back in response to test queries or errors. Excessive debugging information can be used to glean information about a web applications configuration. This could be used to compromise security. Possibly by way of a code injection attack.
  • Disable directory browsing. Some versions of popular web server software have Enable Directory Browsing on by default. This allows URLs to be manually changed and the directory structure of the web server to be viewed. This should not be allowed.
  • Make sure folder permissions are set correctly on the server that host the components of the application. Related to the point above. Make sure that file and directory permissions are set so that users can’t access the files if they do gain access to the file system.
  • Principle of least privilege should be used whenever possible. The starting position for security should be that everything is off by default. Only turn on the features that are needed for the application to work. And only give access to those accounts that need it.
  • Role misconfiguration. Don’t give rights in role based permission models beyond what the basic need is in order to perform the role. The principle of least privilege should be used for roles too.
  • Use the many tools available to scan for common security misconfigurations. Do regular scans and audits of web application software and infrastructure. Especially after any system updates or changes.
  • Engage a professional external penetration test company. In addition to doing your own internal scans and audits, the use of professional external security penetration testers should be considered. They are experts in finding security vulnerabilities due to common misconfigurations.
  • Ensure developers and administrators stay up to date with latest best security practice. There are many ways to do this by subscribing to popular security site RSS feeds, following security experts on social media, and attending security conferences and seminars.

 

Maurice McMullin
Maurice McMullin

Maurice McMullin is a Principal Product Marketing Manager in Kemp with too many years of experience in the development and marketing of networking and security products. He has worked in organizations of all sizes ranging from two person startups through to multinationals in roles as varied as programmer and CTO.