On Thu, 11 Nov 2021 at 22:00, Bruno P. Kinoshita <brunodepau...@yahoo.com.br.invalid> wrote: > > Maybe we could provide a flag that disables the characters mentioned in the > OWASP page about CSV Injection [1]
No, please no. > Normally I suggest going secure by default, but in this case I think the flag > should be disabled by default, as filtering cells that start with "equals to" > could break in cases where it was used for a legit formula for > excel/openoffice/libreoffice/etc. Or maybe the CSV contains data for another application that requires these meta-characters. Or maybe there is another application that blows up when accents are used. Etc. It is just not the right place to implement such checks. > The OWASP page also acknowledges the difficulty of this issue I think: > > This attack is difficult to mitigate, and explicitly disallowed fromquite a > > few bug bounty programs. > Just my 0.02 cents. > Bruno Yes, it is difficult (if not impossible) to mitigate, especially at the level of a component like Commons CSV. We don't know the context of how CSV will be used. Do we even want to take responsibility for guaranteeing that Commons CSV prevents all CSV injection attacks? Even if we were able to release a perfect solution, it would not prevent injection attacks via direct access to CSV files, which is surely the main vector. Seems to me we should just update the Javadoc to mention the issue, and let the application handle it. > [1] https://owasp.org/www-community/attacks/CSV_Injection > On Friday, 12 November 2021, 04:29:42 am NZDT, Bernd Eckenfels > <e...@zusammenkunft.net> wrote: > > Hello, > > I don’t really agree, a generic CSV tool should have a flag to protect > against this, since it is a very common requirement. The situation is very > unfortunate, this is why there is no good solution by default, but I can > asume many software vendors working in the area of windows based enterprise > desktops and exporting files with CSV downloads want to enable this. > > Having said that, not sure if actually quoting is enough and all should > prefer xml based office formats anyway. > > I won’t mind to accept a tester patch for such an option. Maybe even > unsafe-pass-default/quote-injection/reject-injection enum. > > Gruss > Bernd > > > -- > http://bernd.eckenfels.net > ________________________________ > Von: sebb <seb...@gmail.com> > Gesendet: Thursday, November 11, 2021 3:42:08 PM > An: Commons Users List <user@commons.apache.org> > Cc: Gary Gregory <garydgreg...@gmail.com>; ms...@acm.org <ms...@acm.org> > Betreff: Re: [csv] Does the library provide means to circumvent CSV injection > > On Thu, 11 Nov 2021 at 11:36, P. Ottlinger <pottlin...@apache.org> wrote: > > > > Hi guys, > > > > thanks for your reply. > > > > Maybe I'm misinterpreting something but I thought that it could be made > > possible to configure CSVFormat-object when writing the CSV data in a > > way that any data with possibly corrupting values (as shown on the OWASP > > page) will mask the whole contents of the cell. > > > > Thus a library such as commons-csv would be able to lower the risk for > > CSV injection and not every client/customer would have to manually > > create this protecting logic. > > > > To my mind it's a simple parser for "dangerous" tokens that quotes the > > given data with additional " .... as we do not need to write > > functioning Excel formulas into CSV. > > > > WDYT? > > As the others have said, this is the wrong place to be looking to fix > the problem. > > CSV files are used for lots of things other than spreadsheets, so what > is dangerous in one application might be essential in another. > > Besides, not all CSV files will be processed by Commons CSV on their > route to a spreadsheet app. > > Such checks need to be made at the input to the application that processes it. > > > Cheers, > > Phil > > > > Am 10.11.21 um 20:53 schrieb Gary Gregory: > > > I agree with Matt. CSV is just a container, it doesn't know or care what > > > the concept of a "formula" is. > > > > > > Gary > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: user-unsubscr...@commons.apache.org > For additional commands, e-mail: user-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
