Using a straight PHP-level substitution like that performs the substitution before the SQL parser sees it. It’s also super dangerous if you’re not absolutely sure there’s no path for an untrusted agent to inject the name you’re selecting on.
> But anyone writing software that runs in a web server,
> or that otherwise interacts with untrusted data, has to
> pay attention to basic security practices.
> And a fundamental one is that you don’t run code that
> some untrusted person sent you.
But most people do this all the time. Just using a web browser has your machine executing god only knows what code generated by god only knows who doing god only knows what to your computer. Unless you have disabled that, of course. But that makes the web almost completely unuseable because it is full of stupid sluggard Johhny-cum-lately web designers who pull in third-party crap from god only knows where (since only their victims run it, they do not run it themselves). There is a very small subset of people who take action against such stupidity. I used to complain but these people are utter morons with abysmal IQs and do not grok the problem -- so there is not much point in that. Now I simply refuse to deal with companies that pull such shenanigans and tell them why I will never do business with them.
> Anyone who doesn’t hear alarm bells going off when
> they see code like
> “UPDATE students set name=$FORM_DATA …”
> really shouldn’t be writing this sort of software.
And people who use squirrily quotes should fix their email client ...
> (And it gets worse than this. A major attack on Wordpress
> and other PHP apps about ten years ago, that caused a lot
> of damage worldwide, was triggered by some bozo using PHP’s
> “eval()” function inside an XMLRPC library.)
You don't need to look that far. I am sure there was at least ten new vulnerabilities discovered yesterday that fall into this category. And just for WordPress.