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 Monday June 17 2019, @02:47AM
Well, for one thing, mysqli_real_escape_string doesn't fix the bad SQL statement I put (which I am kind of surprised no one pointed out, especially since it sort of proves my point in an ancillary way, since I did it on accident in haste). It is also still vulnerable, even if there were quotes there, because you can still trick mysqli_real_escape_string with a proper single-field payload, through interactions between multiple fields, and through how various sanitizing functions cascade. There are even tools to do it automatically by trying the various inputs when they don't know what your character set is or combination of escaping and other sanitizing. Plain and simple, yes each refinement of the functions make your site safer, but security has to be broken once and then all the automated tools get updated to add the latest generation of attacks. Meanwhile you stay vulnerable, if you don't keep up with the changes in proper functions to use, bug patches, framework changes OR your framework, hosting platform manager, or other vendor doesn't.