"don't trust user input", or revolves around "validate user input". That principle has been the core of software security strategy for going on 20 years, and has bought us very little. In the real world, we have to start by acknowledging that the verb "trust" is situational, and that in some circumstances virtually all user input is "trusted" somehow. You could phrase this less tactfully as "Validate user input? No shit? Now what?" - Thomas Ptacek Source: https://news.ycombinator.com/item?id=3940286
CSV files • Then when a spreadsheet program like Excel, OpenOffice, or Google Spreadsheets opens the file, the payload executes • First published discovery: – Jan 2013 • Most recent work: – Oct 2017 Source: https://www.owasp.org/index.php/CSV_Injection
the brain after only the second exposure to a warning, with further decreases with subsequent exposures Source: https://neurosecurity.byu.edu/chi_fmri_habituation/
are in the best position to fix or that would have sufficient impact on our users or products security Source: https://sites.google.com/site/bughunteruniversity/nonvuln/csv-excel-formula-injection
bypassable) – Create a strict whitelist • Strip exports aggressively (whitelist) – Input validation blacklists may not be robust – Easier/Cheaper/Better to support bugs (legit use cases) than compromised users • If you have to: ^\W.+\(.+\) Source: https://www.slideshare.net/exploresecurity/camsec-sept-2016-tricks-to-improve-web-app-excel-export-attacks
http://georgemauer.net/2017/10/07/csv-injection.html • DDE – System that allows CSV injection to work – https://sensepost.com/blog/2016/powershell-c-sharp-and-dde-the-power-within/ – https://msdn.microsoft.com/en-us/library/windows/desktop/ms648774(v=vs.85).aspx
get the parser to execute a malicious payload resulting in information disclosure, or service disruption. Source: https://www.owasp.org/index.php/XML_External_Entity_(XXE)_Processing