Is it astonishing? "Don't sanitize your own strings; always use a library" is common advice for handling SQL and HTML, which implies to me that it is in fact pretty hard to do correctly.
What's astonishing is the popularity of the way of thinking that producing the cheapest code possible that still works along happy path (and simply doesn't fail too badly when it does) is is considered not only a valid practice but even some business virtue that needs to be protected.
The more I think about it, the more I like the idea of an EICAR-like records like this SCRIPT one - in the official database. It must be fully benign, of course (in a sense the script source should point to the same agency, and contain only a warning but no harmful code), and it must be well-known - effectively a test case for production systems. Rather than a pinky-swear "company name will should be okay, don't worry" that allows neglect, it's a "hey, this is a special weird case - specially to make sure you're doing things right" friendly guidance.
How about things like parsing strings for serializing to binary storage?
Can everything be an injection attack?
> Can everything be an injection attack?
What does this question even mean? I guess we must say "for any system accepting arbitrary input: yes". Not even sure if the "arbitrary" qualifier is necessary.
It never does, because abstractly speaking, there is no such thing as a secure computing system. This goes double for any computer that is switched on.
Practically speaking, it depends on how critical your application might be. If you're storing values for neurosurgery or automated dispersal of life-saving (or potentially life-ending) medication, you'd better be sanitizing on the way in, validating on the way out, and have some additional layers like audits and comparisons to known good values at rest. Look into defense in depth, and never trust the computer to make a decision, because the computer cannot be held accountable.
If you're storing quiz results for someone's favourite colour, or it's not internet connected, you can probably be a bit less paranoid about it.
> Can everything be an injection attack?
But yeah, anything and everything could be an injection attack if the attacker is determined enough. It's just a matter of how difficult you want to make it for them.
const csv = rows.map(cols => cols.join(','))
.join('\n')
const esc = cell => `"${String(cell).replace(/"/g, '""')}"`
const csv = rows.map(cols => cols.map(esc).join(','))
.join('\n')
I caught myself doing it the other day, Go has a JSON library and here I was too lazy to define a struct,
w.WriteHeader(500)
fmt.Fprintf(w, `{"error": %q}`, err.Error())
But yeah, we are meant to always use a library because we have deadlines and we are willing to compromise a whole lot of quality to deliver on them.
Specifically json and unjson I make globally available in all my projects. If I used csv more often than once in a decade, I’d have csvesc(s) too.
Sometimes you read some stdlib reference and wonder what they were thinking with things like System.out.println and without one-line one-arg readtext(), tojson(), fetch() and so on. It’s like a kitchen with all appliances still in boxes and all utensils in a tight vacuum cover. Everything is there, but preparation friction makes it absolutely unusable.
People think hard things should be easy and with less "friction". If I want to output a string why should I have to know what the difference between stdout and stderr is? If I write CSV to a file why do I need to know the difference between CRLF and LF, and UTF-8 and UTF-16 or what a BOM is? At the end of all of this you end up with a company named 'W""oopWoop;' crashing the banking industry.
So no, you should know all of that, and more or get the fuck out of my industry.
I think the high horse here is a bad point cause it simply claims it must be hard for no good reason. It’s not even complexity-wise hard, you just have to (metaphotically) unpack your instruments every time you use them. That’s bs at all experience levels and it must be obvious to anyone who works in a shop. Ime, the problem isn’t knowledge, but inconvenience.
[0] https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection...
Are we still passing SQL statements and data to the SQL back end as single string instead of passing them separately? Why would you even need to escape SQL data in 2024?