Re: FilenameWithVersionResourceCachingStrategy accepts (almost) any string as a version
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 > >
Re: FilenameWithVersionResourceCachingStrategy accepts (almost) any string as a version
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
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
Re: FilenameWithVersionResourceCachingStrategy accepts (almost) any string as a version
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
FilenameWithVersionResourceCachingStrategy accepts (almost) any string as a version
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