I find it akin to hiring a librarian who cannot read. Either because they're cheap, or they have the right friends.

People would start to confuse "your" and "you're" or "its" and "it's".

Quite a scary thought.

I am genuinely trying to determine if this is a joke. :) People already do confuse those! I have unfortunately seen many arguments on Facebook over the correct usage.

1. Incompetent contractors

2. Well-meaning non-technical hiring managers with slim budgets

3. Talent that's not lining up to work for the gov't because it's most definitely awful compared to the opportunities available

The story of the US gov't dismal IT infrastructure. In 2017, IT budget is projected to be 90 billion.

https://www.whitehouse.gov/sites/default/files/omb/budget/fy...

How much of that do you estimate is wasteful?

It'd sure be nice to register to vote/get healthcare/etc on my phone.

- Outsourcing offshore to lower costs through a 3PP

- Junior developers with inadequate training

- Sheer incompetence

Incompetence can be extended to management - i.e. a lack of policies and auditing to undertake due diligence.

Sometimes SQLi isn't always obvious even if they are aware of the attack vector if the developer is not thinking defensively. For example inputs from a cookie or HTTP headers such as HTTP referer etc.

Pretty simple: 100% of the time use prepared statements, NEVER build an SQL query yourself.

Tada, 0% SQLi.

I might naively underestimate the amount of pure "naked SQL" code still written, but I suspect that in this age, more SQLi accidents happen in "95% safe" environments. Kind of like the class of accidents we expect from 95% autonomous cars, where an unfocused and out of practice driver is expected to take over the wheel when the robot brain decides that driving is to difficult.

The problem isn't that some people are idiots. The problem is that we, as an industry, don't have great security solutions.

Process that could help mitigate this bugs -

- Security / safe coding training

- Code audits

- Testing - static and dynamic

- Policies that are communicated such as "Always use prepared statements" or "use X framework"

[1] https://www.schneier.com/crypto-gram/archives/2000/0515.html

I’ve had quite a few codebases I’ve worked on where I had to replace naive code [1], and until now, it’s always been easily possible to ensure that the entire space of possible inputs is limited enough to prevent SQL injections.

Sure, there are rare projects where you have to do such very complicated systems, but for 99%, it’s possible to get guaranteed protection from SQL injections.

    ________________________

If something "needs to be secure" then IT is likely up to its ears in reams of policies and reports, Cisco firewalls, VLANs, Group Policies, Symantec antivirus products, Websense, and password complexity regimes. It seems only elite tech companies and the military/intelligence community are making serious steps towards "How can I choose and commission software that is not so likely to contain serious vulnerabilities?" Even obvious ones.

Mainstream IT security practices can, at best, put up a perimeter around the steaming pile of garbage fresh from the lowest bidder so that it can't infect anything else, and only insiders can exploit it, and maybe there will even be a record of them doing things that look like exploit attempts.

Aside from that? It should just be expected that any system that uses a structured query language and can receive user input is vulnerable to injection.

Because third party code review wasn't a requirement in the contract or spec.

How anyone these days accepts code from a vendor, verifies that it works, and then puts it into production and pays the contract baffles me.

They don't think of it as "executable code" because of the limited and monotonous nature of CRUD operations typically associated with data persistence.

They just think of it as yet another inconvenient form of declaritive data already at rest. Perhaps akin to mark-up. Raw data, like XML.

With JSON, some developers innately clue themselves in, because JavaScript, but they don't honestly understand the root of the hazard. They're just thinking FIRE BAD! Then they hack some JSONP into place because it's fun to do that sort of thing.

Most novice developers (my younger self included, tisk tisk) strongly resist protections against even HTML injection, until they see a massacre play itself out in the real world, when someone drops the ball.

https://www.vsecurity.com//download/publications/XMLDTDEntit...

Granted, most modern parsers disable the features that can trigger this by default. But there's still a lot of code out there compiled against libraries that did not, and some of that code is still updated and extended today.

If a raw string is allowed, then the standard facilities - string concatenation, formatting etc - can be used to write injection-vulnerable code.

The only mitigation that does not require educating the end developers is to completely banish strings from the API, and require everything to go through a DSL layer instead. Said layer can then ensure that all values are properly quoted and/or parametrized prepared statements are used as needed.

And Baviaan winked. He knew.

Said the Ethiopian to Baviaan, "Can you tell me the present habitat of the aboriginal Fauna?" (That meant just the same thing, but the Ethiopian always used long words. He was a grown-up.)"

One is that mysql (opposed to oracle or pgsql) is kind of unusual in allowing quotes indiscriminately for all column types, so in order to do this right you have to only do it for string type columns and prevent injection on different types some other way.

Another is that most of the APIs around the more sprintf-style quoting (eg: `query("SELECT * FROM table WHERE x = %", someStr);`) are tied into prepared statements, which carry their own problems that also differ per engine.

It's actually not as simple as you might think. On top of that, php used to have the whole automatic quoting thing that just made a hash out of things.

Prepared statements have been a thing in PHP for a long time, now. Concatenating strings into SQL queries is no longer ever the right answer.