Hacker News new | ask | show | jobs
by tptacek 5682 days ago
There's almost nothing wrong with your second "trick" (when we write recommendations, we usually suggest people never allow users to directly write syntax, and that they structure their app so that the parameters the user sees couldn't possibly land in SQL; use "1" for "ASC" and "0" for "DESC", etc).

But it's not nearly as powerful a statement to say "use parameterized queries and then do everything else right" as it is to say "just use parameterized queries and you won't have this problem", is it?

1 comments

How about "only pass user-sourced data in parameters"? So anything that isn't a parameter is coming from the app, possibly as a response to user data, but not actually from user data. This statement seems just as powerful as the original. Anything misleading about it? Somewhere you can't use parameters and can't simply use app-supplied query pieces?
You see how we're converging on "just use proper input validation", which is the all-time least useful piece of advice in software security?
Because input validation is hard to do. A rule to not pass input EVER (outside of parameters), even in a supposedly validated form, is something different.