Apache Struts Vulnerabilities Pose ‘Stay or Go’ Question
Table of Contents
There’s never a dull moment with Apache Struts. Aside from ongoing remote code execution vulnerabilities which seem to be announced on an ongoing basis, every year, by recent count, a high-profile vulnerability is publicized that sparks the age-old debate anew: should I continue using Apache Struts or should I migrate to a different framework?
Apache Struts ranked no. 24 with a score of 64 amongst most popular frameworks
https://hotframeworks.com/
In 2017 it was CVE-2017-5638 that brought down credit bureau Equifax, followed by remote execution vulnerability CVE-2017-9805 several months later. In August of this year, it was CVE-2018-11776 that threatened to be even more impactful than its predecessor from the year before.
After 18 years on the market, the Apache Struts project is still widely used by enterprises globally, with estimates suggesting that in 2017 at least 65 percent of the Fortune 100 companies relied on web applications built with the Apache Struts framework. It is estimated that 57 percent of companies continue to expand their use of Apache Struts this year. Failing to ensure Apache Struts vulnerabilities are not present in your code leaves many users at risk of exploitation.
The widespread use of Struts by leading enterprises, along with the proven impact of the vulnerabilities found in it, highlights the very contemplation around the continued use of Struts 2. Stay or go? Migrate to a competing framework or push through. Well, it’s a matter of weighing the benefits against the drawbacks and to help you weed through the debate, we’ve done the legwork and listed the top pros and cons.
Apache Struts Vulnerabilities Suffer from Perils of Age
Struts is a mature and well-maintained project, but its maturity comes at an inevitable cost of calcification. Like most legacy applications out there, Struts is a big, monolithic environment that’s been patched over by many different developers over the years, often times without getting to the root cause of problems and fixing them from the ground up. These issues caused defects that are so long-standing that they basically became product features.
That much has to do with old bugs and their fixes. But what about new development? As Apache Struts vulnerabilities play catch up on fixing issues from the past, the project seems to be falling behind on refreshing with new and innovative versions. By some expert assumptions, it is unlikely that Struts will continue to be prolific in the coming years. Not many new projects have been started on this framework in recent years, at least in comparison with other alternatives out there. This lack of new features may give competitors a significant edge over Struts 2 in years to come.
An alternative to Apache Struts 2 – web framework popularity study.
https://hotframeworks.com/
Apache Struts Vulnerabilities Are Shallow in the Face of a Vibrant Community
The Apache community is a strong and active one, offering ongoing maintenance and fast response rates to security disclosures. Struts’ active community, timely publication of disclosures, and the availability of patches, are huge factors in helping its users maintain more secure applications.
Apache Struts vulnerabilities are subject to longstanding security policies and CVE disclosure processes. While Struts has a history of many CVEs stacked against it, the high number of vulnerabilities is directly related to the fact that the projects’ vulnerabilities are consistently being found and reported. In other projects of this size and popularity lacking the security policies that Struts has, the vulnerabilities are likely there but do not get exposed and reported, leaving users unaware and vulnerable.
And the level of responsiveness Struts is able to give goes beyond the disclosure of vulnerabilities and the publicizing of fixes. It affects the level of support the project is able to offer its user base. Struts, like most Apache projects, is a hub of brainpower with resources being made available to its users to resolve technical issues and integration questions along the way. This is a big one for developers who run into problems and need an attentive, reliable, go-to to help them get over coding humps.
Longstanding Apache Struts Vulnerabilities Still a Threat
The latest CVE-2018-11776 is far from the first time critical vulnerabilities have been found in Struts, and the prospect of old vulnerabilities coming out of the woodwork years after they occurred is not the first of its kind either. Just this past August for instance, another critical remote code-execution vulnerability in Apache Struts 2 was disclosed, also dating back several months and somehow overlooked. It’s no surprise then, to find adamant voices out there calling to stop using Struts altogether.
“My one takeaway, not a joke—stop using Apache Struts. 100% serious,”
Wrote Habitu8 founder and CEO Chad Loder on his Twitter account. He was basing his assertion on “non-public details” he had about past high-profile security breaches over the last decade and a half.
Apache Struts Vulnerabilities in Multiple Versions are Actively Supported
The issue of legacy versions and projects that reach end of life is a painful one for every developer. Namely because the seemingly friendly push to update to the newest version doesn’t take into account the hours of work and possible mishapps involved in migration and reconfiguration. Which is why any developer would prefer using open source libraries from a project that maintains its older versions.
Apache Struts 2 actively supports multiple versions, checking for vulnerabilities and quality bugs across these versions, and maintaining its configurability. When new vulnerabilities are published, the Struts community informs which versions are vulnerable, offering fixes for all vulnerable versions. This is not necessarily the case with all open source projects, some of which do not offer support for a range of their older versions.
Yay or Nay to Apache Struts Vulnerabilities: The Answer is a “Yes BUT”
Responsiveness to security issues is always a good indicator to determine the quality of a project and its community base. This point is slightly different to the more general claim of Apache’s active, vibrant, community. As notoriously buggy as Struts is, its security team is equally famous for taking its job seriously. Apache security efforts have been known to come in with zero-day notifications, announcing vulnerabilities on its security bulletin as well as communicating its security updates on a wide range of outlets to ensure they receive wide reach, and responding with timely fixes.
On the downside, this requires users to continually check their Struts components for disclosed vulnerabilities in an attempt to patch faulty components before hackers exploit them.
An active community that takes security seriously is nothing to turn our collective nose up at. In fact, it is a great deal of what gives users the peace of mind one wants from open source code. But the rate of disclosures and the publication of fixes requires continuous maintenance on the user side if it is to be effective in securing your code. Simply, the fact that Struts does a good job of finding and fixing its security bugs means nothing if it cannot be implemented on the user side. In the face of multiple disclosures in a single month, how can you keep track and ensure you’re covered?
This brings us to the “BUT” part of the answer. Apache Struts is a framework worth holding on to in order to enjoy the benefits of a longstanding and popular framework as well as to avoid the many hassles of migration. But to keep pace with Apache Struts’ publicizing of flaws and to stay on top of fixes, you need to have a clear understanding of which Struts components you are using and proactively monitor them for new security disclosures. Application security tools such as Software Composition Analysis (SCA) are your friend in these matters, as they automatically and continuously work to alert on new vulnerabilities in your code.
On a Practical Note
If you intend to hang in there and not part ways with Apache struts, start by analyzing your codebase to assess your current exposure to Struts 2. This assessment will clearly identify which versions of Struts you are using in your products. Then, trust in the Apache Foundation that their security team is on top of things and that they will alert on vulnerabilities as they are reported. Finally, you will need a response plan to continually monitor published vulnerabilities and implement fixes quickly.
