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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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: [email protected] > > > For additional commands, e-mail: [email protected] > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > 000 > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
