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]
