Hacker News Reader

Comment by bitexploder | Hacker News Reader

I have been finding this vulnerability in apps since I started in infosec 10 years ago. I have seen it go any number of ways:

CSV -> import on web app -> SQLi

Malicious input -> CSV download from web app -> Excel -> formula -> sneaky data exfil

CSV -> JS -> import into web app XSS (in places no other XSS existed because of the data)

CSV import -> weird CSV header -> arbitrary data loading (headers were column names.... Schema injection .. like SQLi only more hilarious

Point is apps and devs can have blind spots (knowledge gaps) or just not think of a CSV import or export like other functionality.

View on HN

We recently went through an external pentest simulating a hostile actor with inside information. We had 2 weeks to prepare and successfully defended against timing attacks, DDoS attempts, identity spoofs, request modifications, script injections etc. Passed with flying colors... except for CSV/Excel injection. Everyone looked at each other with the sheepish embarrassment of being pwned by a script kiddie. This was a total blind spot indeed, even after we reviewed every other user I/O.

Were you generating CSVs or importing them?

Generating CSV/Excel extracts, which included the user's first name and feedback comments verbatim - thus creating 2 injection points for malicious formulas.

>defend against DDoS but not sanitizing user input

>calling a pentested a script kiddie

welp, my work is done here

I wrote "script kiddie" as a way to describe the relative complexity of this attack vector - I was highly impressed with the pentest process, and think it's one of the smartest things we did this quarter.

Filtering user inputs is security 101, yet we missed this while focusing on fancy defense mechanics. This large gap between what the engineering team prepared for, and how they were exposed, is what made the outcome "embarrassing" - hence I agreed with GP that CSV/Excel stuff could be a blind spot even for well-trained people.

for sure, I think i'm just sensitive to the use of script kiddie haha

Atleast you're thinking about it, company I work for definitely prioritizes freedom over security if you know what i mean

"Input is evil" is a pretty good maxim to follow.

Yet, nobody ever expects the CSV to be.

> Yet, nobody ever expects the CSV to be.

That isn't really true. Why does the intended format of the input matter regarding veracity?

Reply on news.ycombinator.com