Dev Overflow – Part 8

Dev Overflow – Part 8

Dev Overflow – Part 8 840 630 MikhailSudakov

By Mikhail Sudakov, Cyber Security Architect and Analyst, LEO Cyber Security.

Back to Part 7

This is yet another example of why (software) security cannot be just a checkbox. More generally being a way of thinking, here it specifically takes the form of an ongoing process – a process that should have only one possible ending: when an application is discontinued and dismantled. Otherwise, the process should not stop. It must not stop!

A6 – Security Misconfiguration

“Security misconfiguration is the most commonly seen issue. This is commonly a result of insecure default configurations, incomplete or ad hoc configurations, open cloud storage, misconfigured HTTP headers, and verbose error messages containing sensitive information. Not only must all operating systems, frameworks, libraries, and applications be securely configured, but they must be patched and upgraded in a timely fashion.” – (OWASP).

So, our application has been developed, documented, scanned, pen-tested, hardened, and finally put into production. Woot! Checkbox checked, and we are good. Unfortunately, if the process stops there, that would be a recipe for disaster. One thing we all know software does very consistently is being deployed and used without any issues. I hope that got a chuckle or a snort out of you. Alas, besides always having some issues with something, we can always depend on software to change. Patched today? Guess what – outdated tomorrow.

And don’t get me wrong – change is most often good. Nonetheless, constant change needs, nay, requires an ongoing process to make sure that application properties that had been secure at the onset are still secure today. What is truly needed is a well-documented, rigorous, and consistent process that continuously checks our application for existing or new security issues definitely after every patch or update, but hopefully in between as well. And in the perfect world, that is what we’d have. But, security has always been and will always be a cost-benefit trade-off. Without getting too philosophical, I’d argue that in order for something to be perfectly secure, it must not exist today, it must never have existed, and it must never exist in the future.

So, how rigorous you can afford to make your process will depend on many factors, some of which are likely unique to your organization or application. As OWASP suggests, here are some items to check and monitor in your process:

  • Only logic used in an application belongs in the application (i.e. no stale pages, modules, ports open, components, APIs, etc. If it is stale, it has got to go.). This limits the possible attack surface of an application.
  • Patch security updates as soon as possible; patch other updates regularly. But, patch! At a minimum, quarterly patching should be observed in most organizations.
  • Config files matter – pay close attention to them and know what everything means and does. Default configs are most often designed for maximum usability and minimum security.
  • Avoid sending verbose errors to client (e.g. stack traces). Codification should be used instead. Definitely avoid sending software versions!
  • Default accounts – DISABLE them!
  • Constantly check if there are known public vulnerabilities in software packages you are using.
  • Visit OWASP for more!


It is worth noting that scanners often work very well at detecting such misconstructions. Since there are always several free versions available, and it takes very little effort to sweep an app, there is little excuse for not doing that regularly. However, be very careful if running on production instances as many scanners tend to be… noisy to say the least. Reviewing a scanner’s output is likely to reveal some “low-hanging fruit” to get us started hardening our applications and systems.

In the next post, we will take a look at OWASP A7 – Cross-Site Scripting (XSS). Yep, it’s still here and here to stay!