Hello, I'm Matt Seil, project co-lead for OWASP's ESAPI-Java-Legacy project.
This email caught my attention. In short, I don't think you're going to get an affirmative answer because the potential use cases are too numerous. I'm totally speaking out of turn here however, there may be something the maintainers are doing that I'm not aware of.
As long as it's an acceptable practice to place formulas in CSV documents, the risk will exist. The parsing library is the wrong part of the data chain to focus on a fix for an issue like this. The decision as to whether or not a formula is valid in a cell is business, industry, and application-specific, so this should be handled in the application.
In this case, it would be in Excel itself where you'd want to focus your attention, as that's where the formula gets executed. If you can't control that, you move up the chain until you reach the part of the data flow you DO have full control over, and you work there. IMHO, you've moved too far up the chain.
On 11/10/2021 11:34 AM, P. Ottlinger wrote:
Hi, I just stumbled upon https://owasp.org/www-community/attacks/CSV_Injection# and asked myself if CommonsCSV provides a means to circumvent these kind of attacks. If the library handles these special characters and prevents attacks from working it should be mentioned on the homepage. If it doesn't handle I'd like to know how customers/users prevent these kind of attacks. Maybe there's a working solution that can easily be integrated into CommonsCSV? Thanks, Phil
--------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
