Maybe we could provide a flag that disables the characters mentioned in the OWASP page about CSV Injection [1] 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. 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
[1] https://owasp.org/www-community/attacks/CSV_Injection On Friday, 12 November 2021, 04:29:42 am NZDT, Bernd Eckenfels <[email protected]> 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 <[email protected]> Gesendet: Thursday, November 11, 2021 3:42:08 PM An: Commons Users List <[email protected]> Cc: Gary Gregory <[email protected]>; [email protected] <[email protected]> Betreff: Re: [csv] Does the library provide means to circumvent CSV injection On Thu, 11 Nov 2021 at 11:36, P. Ottlinger <[email protected]> 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: [email protected] For additional commands, e-mail: [email protected]
