Top Ten Web Security Risks: Security Misconfiguration (#5)

Security mechanisms will backfire if misconfigured

Today we are going to look at number five on the Open Web Application Security Project (OWASP) top ten list, security misconfiguration. Gone are the days of monolithic software applications. Modern web applications have layers of complexity in addition to distributed systems – including the platform, web server, app server, database, web services, APIs, frameworks, plugins, custom extensions… the list goes on and on. And, the more layers there are, the larger the surface area of attack. Each layer must be secured individually. Luckily for us, most of the hard work is usually already done with default security mechanisms. However, a security mechanism doesn’t protect you unless it’s configured and being used. It’s like listening for a secret knock, and opening the door when someone rings the doorbell.

Defining the Problem

The term security misconfiguration seems pretty broad, but it specifically refers to selecting settings in the built-in security mechanisms for “production-ready” software. Tasks such as setting up firewall rules/exceptions, denying access by default, requiring passwords where appropriate, changing default passwords, and making sure the latest security updates/patches have been downloaded and installed.

Below is the OWASP cheat-sheet on security misconfiguration:

Detection & Prevention

OWASP accurately categorizes this attack vector’s exploitability as “easy.” This is primarily because the same openly available literature on how to secure these mechanisms can be applied to exploit them. As an analogy, a football player may ask the doctor how he can heal up his bad knee faster, and a less than scrupulous opposing team may hear the same request and target the player’s bad knee.

The good news is that it’s typically as easy to detect this type of vulnerability as it is to exploit.  Simply run the same scans the script kiddies use against your own system to find vulnerabilities, then patch and configure as necessary.

It’s even better though, if you can be proactive. Make sure to install the latest security updates. Remove any unnecessary features or plugins – you don’t want to end up like Wile E. Coyote and have your tool used against you. Change the passwords and usernames for any default accounts. Don’t present stack traces to users. If your framework has security settings make sure to read the documentation to set them to appropriate values. These processes should be automated as much as possible, since you’ll need to repeat them with each update to your application.

Summary

Modern software is increasingly complex and as such, has an increased attack surface area. The good news is that most “production-ready” software comes pre-baked with security mechanisms. The bad news is that there are tons of settings and many organizations don’t take the appropriate time to properly configure these systems. Part of this is because the sheer number of configurations. Also, it can be time consuming and expensive to read up on security documentation, especially if you don’t have experience with a specific technology.

Credera has a security team that is well versed in the detection and prevention of security holes and application vulnerabilities. If you would like to discuss any of the materials you have read or have a particular need for testing or secure application development, please email us at SecurityTeam@credera.com.

• OWASP
• Web Security Risks
• Open Web Application Security Project
• Security Misconfiguration