One of the hackers suspected of being behind the TalkTalk breach, which led to the personal details of at least 150,000 people being stolen, used a vulnerability discovered two years before he was even born.
That method of attack was SQL injection (SQLi), where hackers typically enter malicious commands into forms on a website to make it churn out juicy bits of data. It's been used to steal the personal details of World Health Organization employees, grab data from the Wall Street Journal, and hit the sites of US federal agencies.
"It's the most easy way to hack," the pseudonymous hacker w0rm, who was responsible for the Wall Street Journal hack, told Motherboard. The attack took only a "few hours."
But, for all its simplicity, as well as its effectiveness at siphoning the digital innards of corporations and governments alike, SQLi is relatively easy to defend against.
(Score: 2) by isostatic on Saturday November 28 2015, @02:31AM
How do you do an "in (1,4,7,8,9)" clause in a MySQL prepared statement?
(Score: 2, Informative) by rigrig on Saturday November 28 2015, @02:52AM
UNTRUSTED_PARAMS = [1,4,7,8,9]
SQL := "in (" + repeat("?", count(UNTRUSTED_PARAMS)) + ")"
for (PARAM in UNTRUSTED_PARAMS)
bind(PARAM)
No one remembers the singer.
(Score: 0) by Anonymous Coward on Saturday November 28 2015, @05:55AM
If what's in the "IN" clause are only numbers, I just delete all characters except numbers and then use those numbers. Seems simpler that way. If the query no longer works without error, it probably wasn't valid anyway. If the DB is still exploitable it's probably it's fault for somehow being exploitable with mere numbers and if it's that crap what are the odds that the bind param method would still help?
How often do you really need to do "IN" with unicode params?
(Score: 2) by stormreaver on Saturday November 28 2015, @02:16PM
UNTRUSTED_PARAMS = [1,4,7,8,9]
Or you can add the same to your database library (you are writing and using reusable database libraries, right?) so you only have to write it once. Writing it over and over is almost as bad as not writing it at all. Then it becomes (in pseudo code):
sql = make_in(statement, params);
Where statement is your prepared statement object, and params is your list of parameters.
There is really no acceptable excuse for not using prepared statements. If your 3rd party software doesn't use it, either have your vendor do so, or fire your vendor. Using inline SQL should be grounds to make your vendor personally liable for all SQL injection damages. It's just that fundamental. I cannot even adequately express the rage I feel when I think about the complete and utter incompetence of the highly paid companies writing such shitty software.