Software security - is your application secure enough?

Let me start off by saying that there is no such thing as a 100% secure application - unless maybe it is only on a computer that is never turned on and it is the only copy.

I'll qualify that with - I don't have a degree is software security so you may ask why you might pay attention to anything I say? I've been in the software development field for many years and have experienced a number of the failings related to software security. I've worked through mitigating a few instances of those failings and recognize that certain choices make future security failures more likely.

I can't fix your security issues but there is simple advice that *may* help you deliver more secure software. A lot of security advice is pretty standard and I'm hoping to not repeat those items here.  

I'll do a spoiler for this post.

My advice is to at least minimally understand past and current security issues with the technology stack you are considering before fully committing. This doesn't mean read every known possible exploit but you should get to know general types and magnitudes of possible exploits across the stacks you are considering.

What?  Is that all?  How does that help me?

Lets say you have a number of Apache Struts applications as part of your intranet presence.  One day, management decides that there is a need for a great new wiz-bang public facing application.  So far, so good - we'll assume what they are asking for fits a real need and solves some problem.  

You and your team have Apache Struts experience so you decide to just go with Struts as the MVC framework along with other existing and new technology. By templating off of existing internal applications, you produce a nice app very quickly.

Ok, so what is the problem?  When management sees large companies with lots of IT knowledge failing in the area of security - they may ask you what the security implications are for the app. At this point, you become very thoughtful regarding what to say.  You may indicate that you and your developers are following all the best coding practices and therefore the risk is minimal.

This is where I ask - are you missing anything? You may be following all the best coding and deployment practices but in this day and age - nearly every application being built is done so with the help of tons of open source software. Please don't take what I am saying to mean that open source software is bad because it isn't  - but you need to understand each packages' security implications. Most open source software packages contain lots of features you don't need and may never use. Those features may enable attackers a level of unauthorized access to your systems through things like configuration mistakes or oversights. Evaluating current and past security history is a good way to start understanding what general types of things may be found in the future. 

For example, with Apache Struts - if you google for "struts 2 cve" you will likely find a link like:

https://www.cvedetails.com/vulnerability-list/vendor_id-45/product_id-6117/Apache-Struts.html

This site maintains a list of known security vulnerabilities for a large number of software libraries, frameworks, packages, etc.  For Struts you will notice that the list of vulnerabilities is pretty long.

If this was 2015 and you made the decision to use Struts - you would have had the potential to be impacted by the items that WERE found after that - which included quite a few. Since it is now 2018, is Struts secure now? I only noticed 1 or 2 reports in 2018. In the end, you don't know what other security flaws are still unknown but based upon history I would wager that some exist.

Software security management is less about absolutes and more about a level of security and your risk tolerance. Some software is less prone to security issues than other software for various reasons.  Going back to example situation, if instead of struts you had considered JSF and reviewed the CVEs for it:

https://www.cvedetails.com/vulnerability-list/vendor_id-5/product_id-13552/SUN-JSF.html

There is only 1 item - https://www.cvedetails.com/cve/CVE-2008-1285/.  Does that mean that JSF it super secure - not necessarily.  It just means that few security flaws have been reported and show up at the Cvedetails site for this specific Sun JSF implementation.  If you do some googling around further on JSF, you will find additional concerns about JSF implementations regarding view serialization which should be considered. So we can't say that JSF is "secure" but we can say that there is a difference in the known quantity and scope of issues between Struts and JSF.

So what do we get out of this exercise?  Knowing current and past security flaws in potential stacks allows you to select a stack that matches the applications actual security needs. The selection will almost certainly be a trade-off of some sort.  Common trade-offs I have encountered included security, scalability, staff knowledge/experience, ease of use and maintainability.

When someone asks how secure your app is - you can report that the implementation stack and development practices were chosen to meet the actual security need. That doesn't guarantee that an app is secure but hopefully through the choices that were made the app will be less likely to experience a security issue.

In the scenario I described initially - a public facing app, I purposely left out some details to help demonstrate the idea.  If this public facing app was part of a kiosk that runs off a read-only DVD and isn't on a network - do I need to worry hackers on the internet?  No, not really.  Could someone hack a kiosk?  Maybe under some circumstances but is the risk or impact very high?  Doesn't seem like it.  So in this case, something like Struts is probably a fine choice if it meets other functional and soft requirements.  

Now, if the public facing app was related to internet accessible airline reservations with some ties to airline traffic control - I would stick with stacks that have a much smaller list of known security issues and likely significantly different other attributes.

The hard part is making decisions for applications that are in the grey areas. If moderate money, reputation and/or liability is involved - I'd lean towards stacks with fewer security issues unless overridden by stake holders or other requirements. In those cases, document the preferred stack and make note of why something else is chosen. 

Disclaimer: Please note that my example scenarios are intended for demonstration only. 

Thanks for reading.
Scott

Proverbs 19:2 New American Standard Bible (NASB)

Also it is not good for a person to be without knowledge,
And he who hurries [a]his footsteps [b]errs.

Proverbs 14:15 New American Standard Bible (NASB)

The [h]naive believes everything,
But the sensible man considers his steps.