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: 3, Interesting) by bradley13 on Saturday June 15 2019, @05:54PM (13 children)
I teach my students about SQL injection in their second semester. Injection attacks of all types are trivial to avoid; SQL injection is probably the simplest of all.
This is simple incompetence.
Everyone is somebody else's weirdo.
(Score: 1, Interesting) by Anonymous Coward on Saturday June 15 2019, @06:52PM (7 children)
Never trust your inputs. Even from a 'trusted' source output. None of them are trusted. Escape everything. Even the output fields from a DB.
(Score: 2) by stormreaver on Sunday June 16 2019, @01:15AM (4 children)
If you find yourself escaping/unescaping, you've already lost. Use prepared statements and solve the problem. Everything else is sabotaging yourself, your coworkers, and your customers.
(Score: 0) by Anonymous Coward on Sunday June 16 2019, @03:23AM
That only fixes it at the SQL level. I can turn my outputs into HTML/JS/whatever then use that code to jump back in somewhere else into the megabytes of other functions you have conveniently linked in for me. May take me a couple of jumps but I can find the hole. Never trust your inputs even if from a secure source. Make sure they stay the type you expect at your output level. Otherwise I can jump your implicit sandbox, and rather easily. I can also abuse your stored procs to do my bidding. with_reocmpile is my buddy too :)
(Score: 2, Funny) by Ethanol-fueled on Sunday June 16 2019, @05:21AM
Real N.I.G.G.A.Z. use LabVIEW [jkitchtech.com] for SQL sheeit. Not only is it much more safe, but more easy to read.
(Score: 2) by edIII on Thursday June 20 2019, @10:22PM (1 child)
Don't be so sure :)
How does the prepared statement with parameterized queries work again? Look into the code and you will find they run a standard escape function against it. The only difference between escaping it yourself, and the function, is that the function will produce the same output all the time.
If your data abstraction layer is playing those same escape games, then you've just received a heapin' helping of false confidence. Escaping things properly is a bitch. Why try when you can regex the single quotes and semi-colons out of the string entirely. Only a few use cases require dealing with that, and if it doesn't require searchability, then BASE64 encoding annihilates SQLi. If searchability is important, you can still remove those characters from the search input as well as the DB, or convert them to HTML entity codes. Super paranoid, you could create a field that stored positional data on where to put them back, and use that in an export functions.
The single quote and semi-colon are your enemies, and you should only trust your own regex code that you can see yourself. The vast majority of all use cases survive their complete removal.
Technically, lunchtime is at any moment. It's just a wave function.
(Score: 2) by stormreaver on Friday June 21 2019, @12:41AM
Any database that implements parameterized queries using escapes and unescapes is fundamentally broken. PostgreSQL, for example, bypasses the parser entirely for prepared statement parameters (as it should). I could easily see MySQL escaping and unescaping, though. But that's because MySQL is fundamentally broken on a number of levels.
(Score: 1) by webnut77 on Sunday June 16 2019, @01:34AM (1 child)
You've got to handle data like:
"Invoice Date" with an answer of "Thursday"
"Invoice Amount" with an answer of "Blue"
Not all users are idiots. Some are just multi-tasking trying to get they're job done.
I recently fixed a problem where Stop_Datetime was earlier that Start_Datetime.
(Score: 1, Funny) by Anonymous Coward on Sunday June 16 2019, @02:27PM
A QA guy walks into a bar and orders a beer. Orders two beers. Orders infinity beers. Orders negative one beers. Orders a monkey.
(Score: 0) by Anonymous Coward on Saturday June 15 2019, @08:54PM
Yes, but those people get hired. And with extreme flattening of hierarchies, and no accountability for cock ups, that incompetence turns into state of the art reality.
(Score: 1, Insightful) by Anonymous Coward on Sunday June 16 2019, @12:39AM (3 children)
This is simple incompetence.
Only if you tell them a better way and they ignore you.
Do not confuse incompetence with lack of knowledge. They do look the same and some people argue they are the same. But I would rather have a dev who can make a mistake and go 'doh here is how to fix it' than 'doh who cares I will just leave it and do it again when you are not looking'.
(Score: 2, Disagree) by darkfeline on Sunday June 16 2019, @04:26AM (2 children)
Lack of knowledge is incompetence.
Competent == able to do the job effectively.
Incompetent == not able to do the job effectively, whether due to lack of training, knowledge, or head mass.
Or more specifically, if you need to have pointed out to you by someone else that you are ignorant and what you are doing is a security problem, you are incompetent. Someone who is competent would at least know that they are ignorant and obtain the proper knowledge, training, or counsel before attempting to hack together sensitive infrastructure.
Join the SDF Public Access UNIX System today!
(Score: 1, Touché) by Anonymous Coward on Sunday June 16 2019, @05:31AM (1 child)
Yep as soon as you learn about a tech you know 100% how that thing works. You do not need anyone telling you any better at that point.
Someone who is competent would at least know that they are ignorant and obtain the proper knowledge, training, or counsel before attempting to hack together sensitive infrastructure
Mistakes happen. It is how you deal with them that matters. People do not always have 100% knowledge on something. It takes years to acquire good training. That is from code reviews and being humble. Spouting off that someone is incompetent has implications in a business environment. But you should know that or else you are incompetent (by your own definition).
(Score: 2) by darkfeline on Monday June 17 2019, @06:44AM
>Yep as soon as you learn about a tech you know 100% how that thing works. You do not need anyone telling you any better at that point.
I don't know what the point of this statement is. It sounds like you're implying that I said you need 100% knowledge to be competent. I said no such thing. It also sounds like you're implying that I said that someone who is competent has no room to improve. I also said no such thing.
>Mistakes happen. It is how you deal with them that matters.
That's what I said. Even if you are ignorant, the way you handle a task may allow you to qualify as competent. You even quoted the sentence where I stated that.
>Spouting off that someone is incompetent has implications in a business environment
Er, yes? There are many uncomfortable facts that you should not voice in a modern professional environment. Whether or not someone is incompetent is one such fact that's best left unstated, at least during work; off-hours, you might sympathize with a close friend. I also have no idea how this addresses my claim. It's yet another non sequitur "argument".
>But you should know that or else you are incompetent (by your own definition).
Ah! An ad hominem! A clear indicator that one does not have a strong argument.
I'll say it again:
If you cannot do your job, whether due to lack of knowledge, skills, or anything else, you are incompetent by definition. Note that this does not preclude someone who is incompetent at some job later becoming competent.at said job.
Here, this is the definition of competent from a dictionary:
adjective
having the necessary ability, knowledge, or skill to do something successfully.
Join the SDF Public Access UNIX System today!