Security Misconfiguration? Sounds like a job for Agent Burt Macklin
- Jen C
- Nov 10
- 3 min read
Updated: 5 days ago
OWASP Topic — “A05:2021 Security Misconfiguration”
“Moving up from #6 in the previous edition, 90% of applications were tested for some form of misconfiguration, with an average incidence rate of 4.%, and over 208k occurrences of a Common Weakness Enumeration (CWE) in this risk category.” -OWASP
What? Security Misconfiguration? Man, this sounds serious!
What exactly is a Security Misconfiguration? They are attacks that exploit weaknesses in configurations found in our web applications. They can occur when we have not maximized security or we have used insecure default security settings. It’s an easy back door into our applications for bad actors!
This is very common and can happen in
any software application, cloud, or network infrastructure, too! However, it’s still a cause of cyberattacks and data breaches, so we must remain vigilant. Security misconfigurations are a highly vulnerable target, easy to detect, and can cause significant damage.
What are some examples of a security misconfiguration?
Storing sensitive data in clear text (we should know by now that’s a no-no after all of these articles). It’s pretty “clear” how to steal the data (#seewutIdidthere)
Software that hasn’t been patched makes the software vulnerable. It’s easy to exploit a known, unpatched bug to execute an attack. How long ago was that last scan? Is there any old or unsecured code?
Or, if recently upgraded/patched, the latest security features may not have been turned on or configured.
Unencrypted or poorly encrypted files leave us vulnerable to data modification or theft.
Unnecessary features are enabled or installed, which can increase the likelihood of a system attack (such as ports, services, pages, accounts, or privileges). Remember code injections? That could be used here to gain access to the system.
Default passwords/configurations are enabled, haven’t been changed, and make it easier to hack on in! (Are you reusing the same credentials for different systems?) Like the sample applications, if we didn’t change the passwords, well...
Sample applications often contain security gaps that bad actors are already aware of. We install them, and we leave the door open. Default installations with common usernames/passwords, backdoor accounts, etc.
Missing appropriate security hardening across any part of the application stack
Improperly configured permissions on cloud services. Don’t keep the default sharing permissions!
Overly informative error messages for users or revealing stack traces. If the error message is too detailed, it can expose the server’s information and flaws, and can be visible through the error message.
The security settings in the application servers, application frameworks, libraries, databases, etc., are not set to secure values
Using open-source code and not verifying default configurations can compromise security.
But how do we prevent and protect against Security Misconfiguration?
We’re in luck! There are some great suggestions for how to prevent and protect against Security Misconfigurations! We have to keep our minds on security and security on our minds with strict policies and procedures. Here’s the caveat, though, we have to do all of the things!
We must have a robust and repeatable process for managing configurations implemented across all our environments. This ensures the application is secure and hardened against attacks.
We have to lock down development, qa, uat, and production environments. They should be configured identically (with different passwords used in each environment).
We have to be vigilant about deploying software updates and patches in a timely manner to EACH environment (development, qa, uat, and production). Gotta patch those vulnerabilities!
We have to have a strong application architecture that separates components.
We have to run period audits/scans to aid us in detecting misconfigurations or missing patches. This should also include reviewing cloud storage permissions.
We have to have a minimal platform with all the unnecessary stuffs (features, components, documentation, samples). Don’t leave them out there! Don’t install them in the first place, or simply remove them. Again, this poses potential security risks, complicates the application, and increases the likelihood of an attack.
Constantly implement the principle of least privilege by reviewing user roles and permissions. We need to limit access to only what is necessary.
We have to protect sensitive information with strong encryption and secure storage mechanisms.
So there you have it. Burt Macklin, FBI, assures us that while this is common and bad, we can bounce back with some tried and true strategies to get back on track.
Comments