19 ms·
The issue is trusting input you're receiving from users or the wild world out there. User data always needs to be sanitized in some way shape or form. Assume ve
by joelhaasnoot 16y ago
The issue is trusting input you're receiving from users or the wild world out there. User data always needs to be sanitized in some way shape or form. Assume very little on the web.
Think of every language as a strictly typed, pure functional programming language, where I/O is the big bad world out there and evil and blocking and complicated. Likewise, on the web you should treat any inputs as being evil... (ok, so the comparison is far from perfect, but the idea holds true)
- tptacek 16y ago"Always validate your inputs" is unfortunately one of the least useful bits of security advice given to developers; it is only epsilon away from "never make mistakes".
- sausagefeet 16y agoI agree with you, but also pointing out a strength of a language that supports phantom types helps this issue quite a bit. You can design your DB API to not allow unquoted queries.
- KaeseEs 16y agoI think you've conflated "not trusting" user data with sanitizing it. To use an analogy from SQL, using prepared statements/parameterized queries doesn't sanitize user data, but it also doesn't trust it (as it doesn't treat data as code). More generally, blacklist sanitizing is a losing game from the outset, whitelist sanitizing is hard, your best bet is to not treat data as code to begin with.