"In fact they're not injection protection mechanisms at all"
What?! Parameterized queries (in any competent implementation) ARE, in fact, injection protection mechanisms. Escaping != Parameterization.
Ruby on Rails is a poor example to use here - it's a trendy web language that (judging by your comment) does not use proper database practices.
Properly implemented parameterized queries offer protection against SQL injection because they seperate data from instruction - none of the data points in a query are executed, ever.
Gluing SQL instruction strings together with data from users is incredibly stupid and you should never, ever do that.
Use a framework that supports proper parameterized queries.
If parameterized queries guaranteed a total separation between user input and query structure, you'd be right. But they don't. They guarantee a separation between some user inputs and query structure.
I'm failing to see how ASC and DESC would apply here, unless someone is simply passing them on directly from a URL or input form into the SQL, which is almost the equivalent of just letting the user type in the SQL directly. Also, the worst thing that can happen to an extension like LIMIT is that more rows show up than expected, but that wouldn't change the context of the original query to return data that wasn't originally intended to be shown. Plus, it would be very difficult to tag on more SQL to a direct LIMIT number being passed in unless the back-end application was totally brain-dead about how it converted strings to integers.
One other thing - extensions like LIMIT can be parameterized also (shameless plug: our product ElevateDB can do it with its RANGE clause). It's a nice way of getting rid of this type of issue, and allows for easier pagination without having to force the database engine to constantly re-prepare the same query over and over again.
IMHO choosing between ASC and DESC isn't exposing an input into the query in the same way that accepting arbitrary text (escaped or not) into the query is, but thanks for clarifying.
And with regard to LIMIT, it's a bad idea to allow the user to pass in any values without validation, even if you restrict it to integers.
Parametrized queries help resolve the most common kinds of SQL injection, all the "yes but..." argue that it's not a blanket instrument that instantly should make you feel safe and no longer think about security/robustness. That's also true. Such a thing doesn't exist anyway.
What?! Parameterized queries (in any competent implementation) ARE, in fact, injection protection mechanisms. Escaping != Parameterization.
Ruby on Rails is a poor example to use here - it's a trendy web language that (judging by your comment) does not use proper database practices.
Properly implemented parameterized queries offer protection against SQL injection because they seperate data from instruction - none of the data points in a query are executed, ever.
Gluing SQL instruction strings together with data from users is incredibly stupid and you should never, ever do that.
Use a framework that supports proper parameterized queries.