Stories
Slash Boxes
Comments

SoylentNews is people

posted by CoolHand on Friday November 27 2015, @11:12PM   Printer-friendly
from the injection-infection dept.

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.


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 2) by mhajicek on Saturday November 28 2015, @04:23AM

    by mhajicek (51) on Saturday November 28 2015, @04:23AM (#268980)

    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
    Starting Score:    1  point
    Karma-Bonus Modifier   +1  

    Total Score:   2  
  • (Score: 0) by Anonymous Coward on Saturday November 28 2015, @05:32AM

    by Anonymous Coward on Saturday November 28 2015, @05:32AM (#269004)

    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

    by stormreaver (5101) on Saturday November 28 2015, @02:05PM (#269103)

    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.