有一个Java,Spring,Tomcat的webapp,其中一部分负责用生成的activationUrls向新创建的用户发送激活邮件(由唯一的令牌组成)。电子邮件是从Freemarker模板创建的,在电子邮件发送给用户之前,激活URL被替换。一旦用户在浏览器中打开激活URL,(重定向到)用户激活页面,在那里他们需要提供密码等。
问题是,浏览器挂起“正在处理...”,前端什么也没有发生。在后端,我们可以看到这个堆栈跟踪:
13-Dec-2023 15:48:17.595 SEVERE [http-nio-8080-exec-9] org.apache.catalina.core.StandardWrapperValve.invoke Servlet.service() for servlet [default] in context with path [/ui] threw exception
org.springframework.security.web.firewall.RequestRejectedException: The request was rejected because the URL contained a potentially malicious String ";"
at org.springframework.security.web.firewall.StrictHttpFirewall.rejectedBlacklistedUrls(StrictHttpFirewall.java:288)
at org.springframework.security.web.firewall.StrictHttpFirewall.getFirewalledRequest(StrictHttpFirewall.java:267)
at org.springframework.security.web.FilterChainProxy.doFilterInternal(FilterChainProxy.java:193)
at org.springframework.security.web.FilterChainProxy.doFilter(FilterChainProxy.java:177)
at org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:346)
at org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:262)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:178)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:153)
at org.tuckey.web.filters.urlrewrite.RuleChain.handleRewrite(RuleChain.java:176)
at org.tuckey.web.filters.urlrewrite.RuleChain.doRules(RuleChain.java:145)
at org.tuckey.web.filters.urlrewrite.UrlRewriter.processRequest(UrlRewriter.java:92)
at org.tuckey.web.filters.urlrewrite.UrlRewriteFilter.doFilter(UrlRewriteFilter.java:394)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:178)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:153)
at org.springframework.orm.jpa.support.OpenEntityManagerInViewFilter.doFilterInternal(OpenEntityManagerInViewFilter.java:178)
字符串
通过电子邮件生成和接收的activationUrl看起来像:http://localhost:8080/ui/activate-account?tokenId=3&token=1462
(它已经被简化了,但关键在于,它有两个由(“&”)和字符分隔的url参数,它被“翻译”成'&'
,其中包含潜在的恶意字符串“;"。
我们使用tuckey.org UrlRewrite 4.0.3
我们为此指定了一个规则:
<rule>
<name>RULE: redirect security urls to index</name>
<from>/(forgot-password|forgot-username|activate-account|reset-password|signout|locked-account|sso-error|ird-access-token)([\?\&\=a-z0-9-]*)</from>
<to last="true">/security/index.zul?function=$1</to>
</rule>
型
请注意,和号(url参数分隔符)在规则中的表示方式。
我的怀疑是,处理规则会导致?param1=xxxx¶m2=yyyy
转换为?param1=xxxx&param2=yyyy
,从而导致抛出异常。
从urlrewrite手册中,我无法找出任何类型的属性可以应用于to
元素。比如escapeBackReference
(重写URL中的反向引用是否应该被转义)或encodeUrl
属性,它指定重写URL是否应该被编码。
有办法解决吗?
FYI:当重新加载页面在浏览器中被触发时,然后重新加载页面并处理URL并显示正确的激活页面。这可以通过将URL粘贴到任何浏览器的私人/隐身窗口中来可靠地重现(Edge、Chrome、FF)。从正常浏览器会话或甚至从相同的隐身模式重复尝试不会导致此问题,并将按预期工作。然而,每个新用户在没有连接到我们的服务器之前都会有一个新的“新”浏览器,所以他们每个人都会体验它。
1条答案
按热度按时间bqucvtff1#
适当的URL编码应该将符号
&
转换为%26
,而不是转换为&
--这是没有意义的--如果符号&
是非法的,那么它的替换不应该包含符号&
本身。