3 ms·
>Don't rely on input validation. Maybe you missed something. Maybe someone calls your function somewhere else where you didn't originally intend it. Maybe some
by rtpg 10y ago
>Don't rely on input validation. Maybe you missed something. Maybe someone
calls your function somewhere else where you didn't originally intend it.
Maybe someone makes the input validation less restrictive for some reason.
Point is, it's not an excuse to cause a security hole just because input
wasn't what you expected it to be.
This point makes me mad because we have both ways to statically verify that calling conditions are "correct" through the right kind of design, and it should be a zero-cost abstraction but you can't do it in C.
Plus this advice is messy when it comes to things like string escaping. This could easily lead to issues like double encoding. Issues that don't exist if you could set up "proper" type checking in C without having to use things like wrapper structs that incur performance penalties.
Defensive programming is always a bit weird because it always feels un-necessary, but in C it's really necessary because you have so few assurances. Pretty scary
I wonder if there's a tool out there that lets you use Rust-style linear types over C code, and other things that would make some of this advice redundant (because the CI server would check the code). You could still write C, but wrong C would error in the checking step.
- viraptor 10y agoI don't think they meant what you described here. > Plus this advice is messy when it comes to things like string escaping. This could easily lead to issues like double encoding. That's escaping - it's not the same as validation. What they mean is that you shouldn't expect that the invariants you see right now to hold in the future. It still means that you should only escape right before the data sink that requires it. But on the other hand it means: escape it right before the data sink, even if you see that the caller only passes in 2 different static strings - it may change. Or escape even if the current filter before rejects anything apart from digits.
- rtpg 10y agoTheir advice seems to be "do not assume invariants on inputs". In which case you can only assume that your input is unescaped, right? If you could assume escaping, that means you're limiting your input, which seems to go against the advice from my reading. I gave escaping as an example, but one of the primary ways to reduce bugs is to reduce the scope of possible inputs as much as possible (thus reducing the scope of output to manage). The requirements are different depending on the use case, but for application-internal code, not relying on that means that so much more global knowledge about the project is necessary to work on it. And, of course, a greater possibility of mistakes (because your requirements are more vast)