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.


> 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

Reply via email to