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: 1, Interesting) by Anonymous Coward on Saturday June 15 2019, @05:24PM (10 children)
Because all of the examples and some frameworks out there show doing things like this.
myrunstring = "SELECT " + " yourcolumn.tostring() + " FROM " + yourtable.tostring()"
Then using some form of exec on it unesscapped. Attack any portion of that string and you in like Flynn. Then on top of that have a poor security model on the server side which lets people run whatever as locked down is "hard".
So yeah it is "solved" but not easy to get right.
SQL's security model is borked from the beginning as the ODBC layer does not assume anything other than I trust you. You can poke pretty much whatever you want in through it if you know how.
You pretty much have to get the whole stack right for SQL injection to not work correctly. As its default is a model of trust not of 'non trust'. All the way from inputs from the user all the way down to it running on the server and back. Never trust your inputs.
I used to do bounce back attacks through the SQL server to get more privilege on the client to mess with my fellow devs. Basically put SQL/HTML/JS commands in the data fields and see what mayhem I could cause on the other end. Never trust your inputs even from a trusted source. Took a bit of work but not much. As maybe you escaped going in but not on the read side and then I could run more commands. I was a right bastard in my list of things I would put into all the fields to mess things up.
Like I said its tough to get right.
(Score: 0) by Anonymous Coward on Saturday June 15 2019, @05:33PM (5 children)
Prepared statements and parameterized queries are the best defense against SQLi attacks. They take a few more minutes to code, but aren't difficult and they are effective.
(Score: 1, Informative) by Anonymous Coward on Saturday June 15 2019, @05:58PM (4 children)
Doesn't help when the readily available examples online are outdated copypasta from 2 decades ago recycled for the nth time.
(Score: 1, Interesting) by Anonymous Coward on Saturday June 15 2019, @06:48PM (3 children)
Oh they are right it is what I call a good start for that sort of thing. But yeah mine and your point was there are *many* bad examples out there. Guess I got onto rant and forgot to square in on that point. Also the anti pattern many of these shops follow of 'got it to work' then massive copy and paste endeavor. Where they had 1 security issue now they have hundreds. c+p my old frenemy. But yeah bind your params bashes out most of the 'easy to exploit' stuff. You also pretty much have to hide the DB behind some sort of service to pull that off correctly.
Even *if* you bind your bind your params you need to watch what is coming back up out of the DB. As I can create a two stage SQL injection attack. As I can put junk in from one point make it look like valid HTML/JS/whatever on the other and break out of the box. So you have to be careful on your strings from that side too. The trust surface on SQL is not good for security. Great for getting shit done though. Even worse if you have more than one way to get into a DB. Do not assume all of your data is sanitized or you could have a bad time of it.
(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).
(Score: 2) by Common Joe on Saturday June 15 2019, @08:16PM (3 children)
I just can't even. Only under very specific circumstances is that ok. Like less than 0.1% of the circumstances that I can think of. 99.9% of the time, this is... ugh. I'm preaching to the choir.
Grumble, grumble. And they say my skills are out of date. Grumble, grumble.
(Score: 2, Informative) by Anonymous Coward on Saturday June 15 2019, @11:31PM (2 children)
To me, those examples are not the worst, because it is quick and easy to explain why it is wrong to someone. It is the examples that do something like:
People see that, you complain and then they don't understand what is wrong because they are escaping. But then, they finally read the docs or something and then switch to mysql_real_escape_string. Except you complain because that still has vulnerabilities, which are unfixed because that function is deprecated, and it begins again.
(Score: 2) by digitalaudiorock on Sunday June 16 2019, @07:46PM (1 child)
I'm not sure I understand the point you're trying to make given that the entire mysql extension (as apposed to mysqli) in php has been completely removed. The mysqli_real_escape_string on the other hand is very much still valid. In any case I've never coded any database access via PHP without using the PHP ADOdb abstraction layer:
https://adodb.org/dokuwiki/doku.php [adodb.org]
That takes care of the proper escaping...in the case of the mysqli driver using mysqli_real_escape_string. That's extremely lightweight as well, unlike others. As I recall for example, the Pear DB stuff (at least when I tried it years ago) hammered performance my orders of magnitude just by including it.
(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.