On Tue, May 26, 2020 at 11:59 AM Daniel Stoch <[email protected]> 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 <[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] > >
