SoylentNews is people
SoylentNews
SQL Injection Attacks Represent Two-Third of All Web App Attacks
For its "State of the Internet" report, Akamai analyzed data gathered from users of its Web application firewall technology between November 2017 and March 2019. The exercise shows that SQL injection (SQLi) now represents nearly two-thirds (65.1%) of all Web application attacks. That's up sharply from the 44% of Web application layer attacks that SQLi represented just two years ago.
Local File Inclusion (LFI) attacks, which, like SQLi, are also enabled by a Web application's failure to properly validate user input, accounted for another 24.7% of attacks. Together, SQLi and LFI attacks represented 89.8% of all attacks at the Web application layer over the 17-month period of Akamai's study.
[...] SQL injection errors and cross-site scripting (XSS) errors have topped, or nearly topped, the Open Web Application Security Project's (OWASP) list of top 10 Web vulnerabilities for more than a decade. Just this week, in fact, HackerOne published a report showing XSS errors to be by far the most common security vulnerability in Web apps across organizations. Both XSS and SQLi are well understood, and many researchers have catalogued the dangers associated with them for years.
The fact that so many Web apps still have them reflects the relatively scant attention paid to security in the application development stage, says Andy Ellis, chief security officer at Akamai. "It is not that the developers are making errors," he says. "It is system that we put them into that is dangerous."
[...] Akamai's data[pdf] shows most Web application attacks originate from inside the US and most targets are US-based as well. Of the nearly 4 billion application-layer attacks that Akamai counted over the 17-month period, some 2.7 billion targeted US organizations. Companies in the UK, Germany, Brazil, and India were also relatively heavily targeted. though nowhere nearly as much as US companies.
(Score: 0) by Anonymous Coward on Saturday June 15 2019, @07:41PM (2 children)
I'm the "prepared statements" AC.
I don't disagree with either of you regarding "the bad examples greatly outnumber the good examples". The "copy from a website" programming culture is resulting in an enormous amount of poorly written and insecure legacy code in many projects. This will only get worse as outsourcing becomes even more common and more cost competitive.
Poor (or nonexistent) security, combined with the lack of accountability relating to data breaches, guarantees that things will not improve. If security isn't part of the foundation of a project then it is only a matter of time before things will go badly.
(Score: 0) by Anonymous Coward on Sunday June 16 2019, @12:36AM (1 child)
Bind them helps so much! Also make sure your framework really does an odbcbindclol on the bottom of it and not just catting things together and running exec on it and calling it good. You may laugh but I have seen it. You think you are binding but really under the covers it just does a string cat and hides it from you.
https://docs.microsoft.com/en-us/sql/odbc/reference/syntax/sqlbindcol-function?view=sql-server-2017 [microsoft.com]
https://docs.microsoft.com/en-us/sql/odbc/reference/syntax/sqlbindparameter-function?view=sql-server-2017 [microsoft.com]
If your code is using this you are just waiting for a SQL injection attack. It works great in a quick and dirty cheap never to use again app. But anything where you expect security avoid it as much as you can.
https://docs.microsoft.com/en-us/sql/odbc/reference/syntax/sqlexecdirect-function?view=sql-server-2017 [microsoft.com]
(Score: 0) by Anonymous Coward on Sunday June 16 2019, @05:41AM
That's basically what I said in this response [soylentnews.org] earlier in this thread.
Fortunately I've written our own wrapper to DB calls that always prepares and binds, and any queries that are used often are written as stored procedures (which are called via prepare and passed bound parameters).