On Tue, May 26, 2020 at 11:59 AM Daniel Stoch
wrote:
> I know that and for me this is not an issue either ;).
> But this "issue" is reported by some security scanners which checks
> for obsolete and backup files by adding "_old", "_bak", "_backup"
> suffix to filename of selected resource (css, js). And our Wicket
> application is serving such files as if indeed such old copies were
> available.
> So I'm only loudly thinking is it really no problem that we serve
> files with any text attached on the end of file name.
>
This is by design.
If it is not desired then you can use a custom strategy.
>
> --
> Daniel
>
>
> pon., 25 maj 2020 o 21:14 Carl-Eric Menzel
> napisał(a):
> >
> > Sorry, didn't mean to sound dismissive. It's a valid point, just I'm
> > not seeing that anybody could get to anything otherwise unavailable.
> >
> > On Mon, 25 May 2020 21:02:08 +0200
> > Carl-Eric Menzel wrote:
> >
> > > I think the point of this version decoration is not to ensure a
> > > particular version is requested, because typically only one version of
> > > a file is available in the application.
> > >
> > > The point is instead to defeat any caching, both in the browser and by
> > > proxies, which might serve the user an outdated version. So I don't
> > > think there needs to be any checking of that string.
> > >
> > > Or is there an actual security impact that I'm missing?
> > >
> > > Carl-Eric
> > >
> > > On Mon, 25 May 2020 20:47:36 +0200
> > > Daniel Stoch wrote:
> > >
> > > > Hi,
> > > >
> > > > Each resource in Wicket is decorated using a version string in a
> > > > file name by default. It is implemented in
> > > > FilenameWithVersionResourceCachingStrategy. Depending on DEVELOPMENT
> > > > or DEPLOYMENT mode it looks like:
> > > > jquery-ver-1590158412000.css
> > > > jquery-ver-F334A4E46CB37347CAB42E2B1A45897C.css
> > > >
> > > > There is a small security issue, that this strategy does not check
> > > > if this version is correctly calculated for specific resource and
> > > > accepts any string as a version identifier, eg.:
> > > > jquery-ver-F334A4E46CB37347CAB42E2B1A45897C_old.css
> > > > jquery-ver-F334A4E46CB37347CAB42E2B1A45897C_bakup.css
> > > > jquery-ver-XYZABCDEF.css
> > > > etc.
> > > >
> > > > Maybe we should add a check if version passed in request is correct?
> > > > There is partially such check done in decorateResponse() method. So
> > > > maybe it is enough to add else block here and raise some exception?
> > > >
> > > > @Override
> > > > public void decorateResponse(AbstractResource.ResourceResponse
> > > > response, IStaticCacheableResource resource) {
> > > > String requestedVersion =
> > > > RequestCycle.get().getMetaData(URL_VERSION); String
> > > > calculatedVersion = this.resourceVersion.getVersion(resource); if
> > > > (calculatedVersion != null &&
> > > > calculatedVersion.equals(requestedVersion))
> > > > { response.setCacheDurationToMaximum();
> > > > response.setCacheScope(WebResponse.CacheScope.PUBLIC); } }
> > > >
> > > > --
> > > > Best regards,
> > > > Daniel Stoch
> > > >
> > > > -
> > > > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> > > > For additional commands, e-mail: users-h...@wicket.apache.org
> > > >
> > >
> > >
> > > -
> > > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> > > For additional commands, e-mail: users-h...@wicket.apache.org
> > >
> >
> > 000
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> > For additional commands, e-mail: users-h...@wicket.apache.org
> >
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>