Re: Dealing with an insecure Struts application on Tomcat
Greg, On 10/20/23 11:52, Greg Huber wrote: Remember seeing this, a maintained version of Struts 1. Might be work a look. https://github.com/weblegacy/struts1 This is interesting. I knew about this one: https://github.com/kawasima/struts1-forever But the weblegacy folks look *serious* about this: they even have a Jakarta EE-compatible release. -chris On Thu, 19 Oct 2023 at 17:45, Alan F wrote: I am looking at security steps to mitigate issues with a 1.x Struts based app. I have recommended the following until an upgrade resource is available Remove application from current shared datasource Remediate high risk CVE scored vulnerabilities (x4 with high EPSS rating) Reduce exposure to internal audience. Create new db and instance for above isolated datasource Would you take it further and ensure this runs on it's own separate Tomcat instance? Any other recommendations? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Dealing with an insecure Struts application on Tomcat
Remember seeing this, a maintained version of Struts 1. Might be work a look. https://github.com/weblegacy/struts1 On Thu, 19 Oct 2023 at 17:45, Alan F wrote: > I am looking at security steps to mitigate issues with a 1.x Struts based > app. > > I have recommended the following until an upgrade resource is available > > Remove application from current shared datasource > Remediate high risk CVE scored vulnerabilities (x4 with high EPSS rating) > Reduce exposure to internal audience. > Create new db and instance for above isolated datasource > > Would you take it further and ensure this runs on it's own separate Tomcat > instance? > Any other recommendations? > > > >
Re: [OT] Dealing with an insecure Struts application on Tomcat
Alan, On 10/19/23 12:44, Alan F wrote: I am looking at security steps to mitigate issues with a 1.x Struts based app. Is this from a "Struts 1 is vulnerable" perspective? Because -- on paper -- it is. Vulnerable that is. But that doesn't necessarily mean that your application is vulnerable. I encourage you to read the CVEs associated with Struts 1 to see if they apply to you. I have recommended the following until an upgrade resource is available Remove application from current shared datasource Remediate high risk CVE scored vulnerabilities (x4 with high EPSS rating) Reduce exposure to internal audience. Create new db and instance for above isolated datasource Would you take it further and ensure this runs on it's own separate Tomcat instance? Any other recommendations? This depends upon what your threat model is. If the application seems like it's vulnerable, then isolating it from other applications may make some sense. But if your primary concern is access to the underlying data, then isolating the application won't protect the data. I'm not sure what you mean by "shared data source". If you have a server-defined data source that is being shared by individual applications, then you probably just shouldn't be doing that in general. Note that upgrading from Struts 1 to Struts 2 will probably require a complete rewrite of your application. :/ -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Dealing with an insecure Struts application on Tomcat
I am looking at security steps to mitigate issues with a 1.x Struts based app. I have recommended the following until an upgrade resource is available Remove application from current shared datasource Remediate high risk CVE scored vulnerabilities (x4 with high EPSS rating) Reduce exposure to internal audience. Create new db and instance for above isolated datasource Would you take it further and ensure this runs on it's own separate Tomcat instance? Any other recommendations?
