SoylentNews is people
SoylentNews
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: 0) by Anonymous Coward on Saturday November 28 2015, @12:56AM
prepared statements do a lot towards thwarting almost sql injection attacks
though there is a lot of legacy code to be reworked before the world can be rid of it, there are no excuses for anyone implementing a new web application
the real problem is a lack of accountability for managing personal data, and you can have all the laws you like but unless they are enforced they aren't worth the paper they're written on
users also need to take some responsibility, though there needs to be increased awareness of the lack of security of websites generally; assume that whatever you submit to the web is fair game, even when dealing with supposedly reputable companies and government agencies
(Score: 3, Insightful) by stormreaver on Saturday November 28 2015, @01:02AM
prepared statements do a lot towards thwarting almost sql injection attacks
Prepared statements completely eliminate
all SQL injection attacks. Not using them should be grounds for immediate termination, because the idiot who refuses to use them has no place being within a thousand miles of a database insertion.
(Score: 1, Interesting) by Anonymous Coward on Saturday November 28 2015, @01:34AM
i'm generally of that opinion, and i was thinking about writing that in my original comment, but the problem with anything related to computers and security is there's always some smarty pants that eventually comes along and figures out a way :p
(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.
(Score: 1) by rigrig on Saturday November 28 2015, @03:09AM
Nobody "refuses" to use prepared statements.
Lots of people are still using ancient software which happens to handle all their thousands of edge cases correctly but fails to validate a few inputs.
No one remembers the singer.
(Score: 2) by mhajicek on Saturday November 28 2015, @04:23AM
I bet there's also pressure from management to "just make it work, and make it work now!" with no time allocated later to go back and fix things.
The spacelike surfaces of time foliations can have a cusp at the surface of discontinuity. - P. Hajicek
(Score: 0) by Anonymous Coward on Saturday November 28 2015, @05:32AM
Thing is, for languages/databases that support prepared statements, development time for implementing a prepared statement should not be more than developing time for a "build a string query and pass that to the database"-solution. These days even, prepared statements get optimized by modern databases before execution, which results in faster DB action compared to the "quick and dirty" method.
(Score: 2) by stormreaver on Saturday November 28 2015, @02:05PM
I bet there's also pressure from management to "just make it work, and make it work now!"
That's just making excuses, as it barely takes any more programming time to do a prepared statement than to do inline SQL.
(Score: 0) by Anonymous Coward on Saturday November 28 2015, @01:05AM
prepared statements do a lot towards thwarting almost sql injection attacks
Hear, hear! At some point (maybe 5-7 years ago?) it became easier to use prepared statements (or an ORM) for your database interaction needs.
Since that point, if you still insist on using string operations to build your SQL queries, you're just being a jerk.