Community
Participate
Working Groups
Note: This is not for discussion in public areas. opensource.fortify has identified a potential cross-site scripting issue in StaticResourceServlet.doGet(). Details can be found here. https://opensource.fortify.com/teamserver/welcome.fhtml Username: virgouser Password: @dm1n1str@t0r It looks simple enough to fix, just need to escape the characters before sending them back to the browser for display in the 404 message.
Created attachment 186805 [details] patch proposal Hi, Here is the patch proposal. I'm using escaping utility provided by Tomcat. The other two utilities that I found and can be used are: - org.springframework.web - org.apache.commons.lang What do you think? Which library is more appropriate to be used? Regards Violeta
Make the bug summary bland so we won't give the game away when the bug is imported into Acunote.
The code changes look good, not exactly world changing. The Tomcat library is fine but it will be an additional dependency to remove if anyone ever wants it to run on Jetty though. I don't know how much I care though as this will be a trivial change compared to removing the Gemini web dependency. Go ahead and commit.
(In reply to comment #3) > The code changes look good, not exactly world changing. The Tomcat library is > fine but it will be an additional dependency to remove if anyone ever wants it > to run on Jetty though. I don't know how much I care though as this will be a > trivial change compared to removing the Gemini web dependency. Go ahead and > commit. I think we should take Chris's observation more seriously as it would be a shame to make our lives more difficult in the future if we can avoid it now. Perhaps one of the other two libraries would be more appropriate. If snaps already depends on org.springframework.web, then I would suggest that one.
(In reply to comment #4) I chose the Tomcat's one because "org.eclipse.virgo.snaps.core" bundle already depends on Tomcat. I can see that we already use org.apache.catalina.Lifecycle functionality. What do you think?
Yeah, I suppose we can live with another dependency on Tomcat. If and when we need to support snaps on Virgo Jetty Server, we can make a policy decision on how to handle these dependencies. I was simply trying to nail this one while it is being developed and is fresh in your mind. Please could you at least add a comment to the usage of the Tomcat escaping utility noting the alternatives you considered. That will save time if/when we have to support Jetty.
Tested, committed, pushed.
Thanks for fixing this. Removing target milestone as snaps is unlikely to ship as part of 3.0.0 and very unlikely to ship as part of 3.0.0.M01.
Does this bug need to be restricted to committers only?
(In reply to comment #9) > Does this bug need to be restricted to committers only? No. The fix was actually included in snaps 3.0.0.RELEASE after all. Adding target milestone to make this clear.
(In reply to comment #10) > (In reply to comment #9) > > Does this bug need to be restricted to committers only? > > No. The fix was actually included in snaps 3.0.0.RELEASE after all. Adding > target milestone to make this clear. It's still marked committer-only. Should that restriction be turned off?
(In reply to comment #11) > (In reply to comment #10) > > (In reply to comment #9) > > > Does this bug need to be restricted to committers only? > > > > No. The fix was actually included in snaps 3.0.0.RELEASE after all. Adding > > target milestone to make this clear. > > It's still marked committer-only. Should that restriction be turned off? Ah, yes. Sorry. (I thought that flag didn't count once the bug went to CLOSED. But I'm pleased that it does count.)
The wording "Committer-only group for handling security advisories in a closed fashion, until a fix is available." was what misled me. Hopefully I'm the only one...
