Something as simple as forcing mysql_query to accept only literal strings, forbidding dynamically constructed strings, would change it from an API so unsafe by design that PHP deprecated it - and then removed it - into something relatively safe.
See also: Perl has a "taint mode" [1] which marks all variables receiving external data as "tainted" and disallows their usage in sensitive contexts. PHP has an inactive proposal to implement it as well [2].
I haven't the foggiest idea what people do today in php but if they don't used cached templates everywhere I will be sad.
Even back then we serialized into and "rehydrated" out of memcached and the database (which memcached pulled from on cache misses). It's honestly more of a pain in the ass NOT to use serialized data structures in the long run. It's a good habit that is hard to break once established :-)
As far as AST manipulation. Heh. Betcha 9 out of 10 front end programmers have never written a compiler in their life. Again a good habit (somehow this topic always loops around to either lisp or Parsec) but a bit harder to establish. Template metaprogramming is a great way to get in a logit of trouble fast unless you know exactly what you're doing, IMHO.
(asterisk) wrote and sold a website in php. I don't judge people by their tools. But a lot of things about php sucked, at least 10 years ago when I stopped needing to write it.
This is an old and deep idea in computer security.
DoD was (is?) interested in systems where, i.e. if a process reads a Top Secret document, then the OS enforces that it can longer write to merely Secret or Unclassified files/IO devices. That way, even a fully compromised process dealing in Top Secret files can't exfiltrate them to a less secure place.
It turns out that in systems designed around this "taint" (they call it "label") construct, everything tends to collect the taint/labels, so things having taint can't be restricted very much or the program can't do anything useful.
I'm in the middle of this security engineering textbook [0] and I love it.
[0] https://www.safaribooksonline.com/library/view/security-engi...
I remember being scolded while working my first "real" programming job becaused I used `eval` in a Ruby on Rails codebase (I don't remember the specifics; I think I was trying to hack something together because the controller setup was weird and I was struggling with the "Rails Way™"). Using a quick `eval` to generate the intended code on-the-fly seemed reasonable to me, having previously been intimiately familiar with Perl (where the dangers of `eval` are mostly mitigated thanks to tainting).
I subsequently learned to embrace Ruby's more robust metaprogramming facilities, and have since come to appreciate the value (and danger) of macros in languages like Lisp and Elixir, but I still found it interesting that features like tainting aren't more widespread (or if they are, they're not advertised very well).
Implemented in secure systems like Trusted Solaris: https://en.wikipedia.org/wiki/Trusted_Solaris
Eventually everything interesting gets tainted. Hence the suggestion never to run anything with any more ACLs than necessary in production systems that touch non-secured bits
Sadly you missed out on the major advances that happened in the PHP ecosystem, like properly namespaced code, massive performance gains since PHP 5.3, Composer, modern frameworks, the PSR initiative (even though one might not agree with all their "standards") and so much more. So I would not judge PHP's evolution by that one proposal ;) A lot more were accepted, implemented and released, from type annotations to the spacechip operator. Personally I'm thankful that nobody further pursued the idea of tainted strings for PHP.
Works for me! :3
Now, your standard parameterized query API would presumably accept dynamically constructed strings for input parameters (since it's clear from the API that those should be unconditionally escaped, and it can internally do the right thing (tm)) but not the query.
On the minus side, being a complete SQL scrub, I'm not sure if this works for specifying sort fields dynamically. Although, I'm already imagining a defcon talk on performing timing attacks against a query that sorts a password field... am I paranoid enough yet?
A string type for query could look like its making a copy but just steal the pointers to the buffers the original had, then modify the query part of the underlying buffer. It would cost several more pointer copies than doing it the insecure way a smart compiler would probably optimize those away.