Re: FilenameWithVersionResourceCachingStrategy accepts (almost) any string as a version

2020-05-26 Thread Daniel Stoch
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.

--
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



Re: FilenameWithVersionResourceCachingStrategy accepts (almost) any string as a version

2020-05-26 Thread Martin Grigorov
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
>
>