Right now I'm looking at the "defaultStack": .... <interceptor-ref name="actionFileUpload"/> ... <interceptor-ref name="params"/> ...
and escaping/normalising normal form fields doesn't make sense as this will happen in "params" interceptor. What should happen is a better control over file names. czw., 13 lut 2025 o 19:00 Lukasz Lenart <lukaszlen...@apache.org> napisał(a): > > My idea for that was related to what we are doing in > ParametersInterceptor, but looks like this requires a step back and > rethink. I would revert these changes for now if there are no > objections. > > czw., 13 lut 2025 o 09:27 Greg Huber <gregh3...@gmail.com> napisał(a): > > > > Unlikely a sanitizing method might not work for everybody. I have had > > quite a few attempts to sanitize the way I want (first I run the > > Normalizer which removes all sorts of unwanted characters, then I only > > allow alphanumeric and then truncate the length) so to make one that > > fits all will not be easy. > > > > We do not want to be rejecting file uploads with no way of overriding it. > > > > The longer the file name the higher the risk? > > > > On 12/02/2025 20:04, Burton Rhodes wrote: > > > If that’s the case, do you think a sanitize method is more appropriate > > > for this situation? Perhaps one that could live inside an interceptor and > > > possibly even be overridden by those who think they know what they’re > > > doing? This way you wouldn’t have to reject the upload which in my > > > opinion is not a preferred user experience. > > > > > > > > >> On Feb 12, 2025, at 12:56 PM, Brian Andle<brianandle...@gmail.com> wrote: > > >> > > >> Unless I'm mistaken this is to prevent issues when a developer uses the > > >> file name, unsanitized, and potentially other malicious type injection > > >> via > > >> specially crafted file names. > > >> > > >>> On Wed, Feb 12, 2025, 10:05 AM Burton Rhodes<burtonrho...@gmail.com> > > >>> wrote: > > >>> > > >>> I agree with Greg. > > >>> > > >>> IMHO, character validation should be left to the developer which depends > > >>> on their OS and file names supported therein. But if there needs to be > > >>> protection against a buffer overflow attack (I assume that is the > > >>> problem you are trying to solve?), then the length restriction should > > >>> suffice. Or is there another risk I'm not aware of that could threaten > > >>> a system by just having a few malicious characters in a file name? > > >>> > > >>> > > >>> Thanks, > > >>> Burton > > >>> > > >>> > > >>> ------ Original Message ------ > > >>> From "Greg Huber"<gregh3...@gmail.com> > > >>> to...@struts.apache.org > > >>> Date 2/11/2025 2:51:36 AM > > >>> Subject Re: file upload name filtering > > >>> > > >>>> Filename length is a possible good way to go, with an override of the > > >>> length and then truncate or block option. > > >>>> On 11/02/2025 06:21, Lukasz Lenart wrote: > > >>>>> Hm... looks like I must re-think this approach, thanks all for > > >>>>> reporting this issue! > > >>> --------------------------------------------------------------------- > > >>> To unsubscribe, e-mail:dev-unsubscr...@struts.apache.org > > >>> For additional commands, e-mail:dev-h...@struts.apache.org > > >>> > > >>> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
