On 30/01/2020 21:38, Alex Pritchard wrote: > Totally possible. I tried modifying \conf\context.xml, using both > useRelativeRedirects="true" and "false": > > <Context useRelativeRedirects="true"> > <WatchedResource>WEB-INF/web.xml</WatchedResource> > </Context> > > I also tried making the same changes in our > web-app/src/main/resources/meta-inf/context.xml in case that was overriding > somehow.
That looks right to me. Odd. I thought I was on to something. Can we go back to my request for a step-by-step description of what is happening. I am particularly interested in the HTTP request/response headers for the requests between the client and the server. Comparing a set from a working version to a non-working version should be helpful. Mark > > Alex > > > On Thu, Jan 30, 2020 at 3:07 PM Mark Thomas <ma...@apache.org> wrote: > >> On 30/01/2020 19:53, Alex Pritchard wrote: >>> Thanks for the response! >>> >>> I think you're right about identifying the wrong cause. I searched my >>> way through the apache versions and isolated 7.0.79 as being the first >>> version that breaks the redirect. >>> >>> I have tried setting useRelativeRedirects to both explicitly true and >>> false, though it seemed to produce no effect on my outcome. >> >> How did you set it? It may be that the setting didn't take effect and >> you got the default both times. >> >> Mark >> >> >> >>> >>> If there's some other difference between 7.0.78 and 7.0.79 that I'm >>> missing, maybe that would help pin down the problem. Nothing in the >>> changelog jumped out at me and the only CVE listed for 7.0.79 was >>> CVE-2017-7674 Cache Poisoning, which didn't seem related to my issue. >>> >>> >>> >>> I think you have identified the wrong change as the root cause of the >>> problem. RequestUtil still normalizes, it just won't let you traverse >>> outside of the webapp root. The URL above would be fine. >>> >>> It isn't clear to me exactly what is going on here. A step-by-step >>> description of what happens may help us identitfy potential root causes. >>> >>> Given that the annotation uses location and that StrictHttpFirewall is >>> part of Spring Security, I'm wondering if a redirect is involved. If so, >>> maybe something to do with useRelativeRedirects on the Context >>> (introduced in 7.0.67)? >>> >>> Mark >>> >>> >>> On Thu, Jan 30, 2020 at 12:41 PM Alex Pritchard < >> pritchard.a...@gmail.com> >>> wrote: >>> >>>> Hi, >>>> >>>> Trying to drag a legacy app forward and running into a breaking change >>>> based on the fact that we're using struts2 to serve some JSPs from a >>>> directory outside our context root by taking advantage of the >> now-patched >>>> directory traversal exploit. >>>> >>>> Essentially the action class is returning >>>> @Result(location="../../foo.jsp"). Previously this would be flattened >>>> from appName/web-inf/content/../../foo.jsp into appName/foo.jsp (I >> think by >>>> RequestUtil ?) but now it is not, so the StrictHttpFirewall isNormalized >>>> check fails. >>>> >>>> My question is if there's any way to configure our installation in some >>>> way to either identify the alternate directory as a root for these other >>>> jsps (while still functioning for the jsps that are correctly in >>>> web-inf/content) or to allow a specific directory traversal in some >>>> context. >>>> >>>> Appreciate any input! >>>> >>>> Alex >>>> >>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
