You think SQLi was bad? You should spend some time thinking about the numerous attack vectors available today in nearly every GraphQL implementation where programmers can't move fast enough in adding it to their stack. Data exfiltration is no longer a flaw but a feature.
It is very very easy to write sloppy PHP, definitely easier than in many other languages and default frameworks.
> You're not acknowledging all of the gaping security flaws in contemporary web-development frameworks. P
I'm very aware of them, basically none have (had) as many high-impact vulns as PHP-based stuff does.
> Yet somehow, Python, Ruby and NodeJS have all had numerous CVEs despite those attack vectors being well known at the time a given framework was written.
You're not acknowledging the orders of magnitudes difference between the impact of an usual PHP vuln and those you listed.
> You think SQLi was bad? You should spend some time thinking about the numerous attack vectors available today in nearly every GraphQL implementation
The flaws in others are a very poor excuse for flaws in a thing itself.
I disagree, mostly on the grounds that string concatenation isn't very convenient, so it tends to be easier to do things "the right way" instead of hacking things together. Yes, you can do string concatenation using something like `format!(...)`, but at that point it's really similar to the correct solution that it's not really what you'd reach for by default.
And yeah, the community here is a huge part of it, and IMO languages can and should be judged by their communities. If a language's community promotes insecure solutions, that's a language that I don't want to use at my company because I don't want my employees following that example.
Where's your proof? Modern PHP frameworks are secure by default.
Symfony Laravel CodeIgniter CakePHP Yii Zend Slim
All of these can (and recommend) using either PDO with named parameters, or a full ORM for SQL work. Most came packaged with a PDO (Doctrine, mostly) by default but have always supported whatever you wanted to use.
Write shit code, win shit prizes.
While there are some web-focussed languages (vs frameworks) that deliberately make it hard for you to write that sort of code, barely anyone uses them.
- it is not "input" must be treated, but, so to say - output. It's the destination that matters, not the source. By the time you get the input, you have no idea how and where it will be used. You can tell it right before the output (or, rather, better to call it "use") only. Say, you've got some input that didn't pass the verification and you will have to display it back in the HTML form. And if you already "escaped" it for SQL, it will be malformed. And vice-versa. Moreover, any data must be formatted properly before use, not just something that you tagged as "input".
- the word treated above is for a reason. Because the term "escaping" suggests some certain routine in PHP, which is the actual reason for numerous SQL injections.
I'm working on comprehensive taint analysis for PHP[0], and I'm spending a bunch of time thinking about how to automatically detect those dirty strings.
[0] https://psalm.dev/articles/psalm-3-and-a-half#taint-analysis
Not trying call you out on this point, more it made me laugh. Our lead developer strips out characters that break his XML importer (lets just say they are standard common characters, heck, he changes chr(13) to a string so he can switch it back later because he doesn't know how to handle multiple lines in an XML value). People who don't know how to escape inputs / actually handle data properly are in every language. We cringe on a daily basis.