Slashdot Mirror
The Rise of Everyday Hackers
An anonymous reader writes "Research suggests there will be a rise in everyday hackers. A simple Google search for 'SQL injection hack' provides 1.74 million results, including videos with explicit instructions on how to exploit SQL injection vulnerabilities. The ready availability of this information makes it possible for less technically skilled hackers to take advantage of this common flaw. Although SQL injection flaws are easy to identify and fix, Veracode found that 32 percent of web applications are still affected by SQL injection vulnerabilities. As a result, as many as 30 percent of breaches in 2013 will be from SQL injection attacks. The research also concluded that the leading cause of security breaches and data loss for organizations is insecure software. The report found that 70 percent of software failed to comply with enterprise security policies on their first submission for security testing."
Really /. of all the places I'd not expect this particular stupidity.
https://en.wikipedia.org/wiki/Hacker_(term)
But a person without broad systematized technical knowledge don't know what they're doing and so can't do anything useful. It's the way it's always been.
remove this article
If this is what passes for research nowadays, I got some more data. Check out these Google queries and the results... (something, something, think of the children, something).
"make a bomb" 557,000,000 results
"rape sister" 99,000,000 results
"kill mother" 274,000,000 results (funny how "kill mother in law" turns up on Google's autocomplete thingy)
"cheat taxes" 59,700,000 results
I guess I'm wondering what the definition of "everyday hacker" is. Just less technically sophisticated?
My research suggests there will be a rise of everyday cooks. A simple Google search for "How to Cook" returns over 1 Billion links and videos describing how to cook! This is original news...
so must be true
script kiddie = script kiddie and is a ( less then )hacker albeit not a skilled one.
As a result, as many as 30 percent of breaches in 2013 will be from SQL injection attacks. The research also concluded that the leading cause of security breaches and data loss for organizations is insecure software. The report found that 70 percent of software failed to comply with enterprise security policies on their first submission for security testing.
No!
Email Spear phishing is the leading cause of security breaches, you can patch software all you want, but patching an idiotic user? Good luck on that!
And 70% sounds a little low, on an intense enough audit (there's many levels), it would look more like 95%.
After setting off every TLA alert system to make a point on slashdot, user "rodrigoandrade" received a midnight visit and was never heard of again.
Wow, a recent google search revealed a search for sql injection netted over 7 million hits and even shows how to do this. This has been well known for at least the last 6 years, next you'll be telling me to beware of Belarc because it will post my serial keys in some hidden page.
I am Bennett Haselton! I am Bennett Haselton!
Leaping to faulty conclusions from spotty data is basically my day job, but it seems these people take it to a new level.
30% of breaches will be from SQL injections, because that's the percent they found to be vulnerable?
A certain type of attack will increase because they googled some shit?
What the actual fuck is this?
sic transit gloria mundi
This is what passes as news on slashdot now? Let's see what's that brady bunch phrase?? oh yeah..... jumped the shark.
This reminds me of JK Rowling's "A Casual Vacancy" since this kind of casual hack figures into the plot.
Lost at C:>. Found at C.
Not so funny now eh, funny man?
"'Little Bobby Tables', we call him..."
I think that most comments are missing the fact that this is an article on a security web site which will be used to sell CEOs on the latest in security platforms. It's pure marketing, which means that it doesn't have to be logical or adhere to real world facts.
I agree that it should have never made it to Slashdot. However, it is interesting to read silly articles like this from time to time to remind ourselves where management gets their ideas about security.
I think the solution is to ban Google! Google is clearly facilitating terrorists!
half of those are blogs with no content and linkspam. another chunk is what im guessing are wordfiles for cracking passwords. another chunk will not have the search term anywhere on the page for some reason. even tho it showed it in the summary.
much better.
Insecure software is insecure
Korma: Good
"A simple Google search for 'SQL injection hack' provides 1.74 million results, including videos with explicit instructions on how to exploit SQL injection vulnerabilities."
Which means that people could be searching to learn what that means because they read or heard it somewhere, or because they want to prevent SQL injection hacks on their site. There are two alternative explanations that don't involve cracking, and I'm sure you can come up with more.
"Although SQL injection flaws are easy to identify and fix, Veracode found that 32 percent of web applications are still affected by SQL injection vulnerabilities. As a result, as many as 30 percent of breaches in 2013 will be from SQL injection attacks."
The quoted statistic does not prove the subsequent claim. This violates basic principles of logic, and anyone who's taken a statistics course (as all reporters should) would see the problem here. Just because 1/3 of web apps are vulnerable to a given attack does not mean that 1/3 of web apps will subsequently fall victim to said attack. The less horrible way to phrase this would be to say that there's a 1 in 3 probability that future attacks will involve SQL injection, and even that's not born out by the statistic.
Here's an analogy (non-automotive): 15% of college basketball players are talented enough to be drafted into the NBA, let's say. This does not mean that 15% of college basketball players WILL be drafted into the NBA, nor does it mean, and this is the kicker, that 85% of new NBA players will be talented players coming from somewhere other than college teams. Or, 1/4 of all homes being vulnerable to electrical fires does not mean that 1/4 of all home fires will be electrical.
This unbiased moderation brought to you by the Porcine Aviation Group!
Is there a database of SQL injection hacks?
I'd recommend counseling for all the insecure software out there. Might do wonders.
And my take on that is the news and Internet itself.
With news indicating "how easy is to find how to make a bomb online" or even running an article explaining it , and on the other hand, geeks making references to little Bobby tables, what do you expect, but people going around and confirm by themselves?
Then again, as you said, there's plenty of documentation online. Now, how is being used? Despite of just satisfying curiosity, is how Google or Wikipedia searches make no sense as metric or indication of anything.
Since when have script kiddies been elevated to everyday hackers?
Whenever a player quits EVE to go play WoW, the Average IQ of both games increase.
And how much is Veracode paying Dice?
no, just censor it. Wait for it, it's coming.
It's ridiculous that SQL injections keep popping up all the time when it's ridiculously simple to avoid them, just don't append random variables with data coming from the user to your SQL queries. Use parameter binding, cast numeric values to integers, etc. .. it is so trivial to avoid these that all stupid code examples on the internet should be removed immediately and anyone posting such examples should be publicly ridiculed.
Common programming forums and pages like PHP.net should also perma-ban and ridicule everyone posting examples or comments that have code/comments/etc. with SQL injections in them. More importantly, all examples should be complete enough to actually describe ways to enter your parameters in the queries in a sane way instead of just using a hard-coded ID number so they can just encapsulate it in a single string, since most "SQL newbie" programmers will never learn of parameter binding etc. that way.
Attitudes towards potentially dangerous material are often contradictory. For example, in an episode of Mythbusters the team required thermite for an experiment. They made this themselves, in a procedure not shown. The ingredients bottles were blurred out to hide the labels. Jamie sarcastically warned viewers never to mix 'blur' and 'blur.' So clearly, someone at the studio considered this information to be too dangerous to reveal to the audience - either because it could be used to create a weapon, or because of the risk someone would experiment with it and then sue the studio after they burned their hand off. And yet, this material that so scared the studio is widely known. Not only can it be looked up with ease on the internet, but it's the textbook example of a redox reaction - quite literally the textbook example. When I studied chemistry in a perfectly ordinary public school it was the example in the textbooks, including not just the ingredients but instruction in how to calculate the correct ratio and, thanks to a practical demonstration given by the teacher, instruction in the importance of particle size, correct safe preperation method and means of ignition. Does that mean the school chemistry text is a terrorism handbook?
You probably could use thermite for terrorism too. If it's used to weld rails, it can be used to sever them too. Sever a rail, derail a train. Could kill hundreds of people if you time it right.
Using Google to search for "SQL injection hack" WITH QUOTES results in 138,000 hits. If you search for SQL injection hack without quotes (meaning Google will count pages that have those words anywhere on the page), then you get the 1.74m hits reported.
That's the only way to be truly secure. Pay attention to every aspect of your setup.
Having what amounts to dynamically generated code, that also includes information from the end user, being interpreted by the database (a SQL command) was, is, and will always be a terrible terrible idea. The database paradigm should have always had input provided in a different context from the code. And that's saying if code was at all necessary in the first place (which it wasn't, as NoSQL shows).
Furthermore, front-end developers will always prioritize client relations (regardless of whether its an internal client or external client) over code quality, thus it is expected that they suck at security. The only way to ensure that these developers follow secure practices is for the systems they use to reduce their workload to automatically provide these good security practices. I am a huge proponent of server side web frameworks because they ensure a majority of a dev's security bases are covered. They also marginally increase productivity, but that's just a bonus for me personally.
XKCD
They can take my LifeAlert pendant when they pry it from my cold dead fingers.
*Knock knock*
:)
"Who's There?"
"The FBI"
Congratulations - I hope you don't plan on leaving the country any time soon.
Your research results seem to indicate that people are an order of magnitude more interested in killing their mother than cheating on their taxes. This is deeply disturbing and warrants further study.
Will a $1,000,000 suffice?
Coming?
"If you have nothing to hide, you have nothing to fear." - Every fascist, ever
"I gave at the office"
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
Cracker means you're a stupid white person. Chris Rock isn't talking about geeks.
http://en.wikipedia.org/wiki/Cracker_(pejorative)
It's actually simple, and it's amazing that so many people don't bothers to follow it: Every input must be sanitized. User input as well as data input from a source outside your system. A good example for the latter may be the original animated cursor exploit where MS was stupid enough to actually trust the file's claim how big its data area is going to be (and store it on the stack... don't ask, it boggles the mind). ANY Input you allow into your system may include some kind of attack. And the easiest way out is to simply put every input through a filter that only lets "sane" values pass.
That also means that "one size fits all" blanket sanitation is in most circumstances a bit weak. Why let alphanumeric input pass on to the routine if only numbers should be entered? Have the filter toss out EVERYTHING that is not part of the possible result set. If you are expecting a "price", filter everything but decimal numbers with up to two decimal places. No letters, no "special characters", nothing but UTF-8 (or no Unicode (a) that satisfies a&&0xFF80), no hexadecimal numbers, everything but the "expected" input must die there. Why? Because no "normal" human would enter it that way. Anything that comes along in such a fashion is most likely an attack.
Such sanitation must happen before the data has even the remotest possibility to touch a database, of course. It's not like contemporary systems have a big problem with computing power, the sanitation overhead is usually minimal compared to the time wasted with barely optimized database accesses and bad database organization.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
For MythBusters it wasn't a case of not disseminating the knowledge. That was the lawyers shifting the liabilty away from the show onto anonymous (improper noun for all you grammer nazis) websites.
s/he swatted him/herself
I think that everyone on /. more or less has a good understanding of the terms, it is the media that simplifies the environment to write shorter headlines.
To clarify:
Hackers are those that delight in taking something apart and putting it back together again, either in its original form or with some modification to improve the thing in their point of view. Hackers was at one stage those who enjoyed pranks between universities, so there is an implied cheekiness in the execution of this experimental interaction with things. In the information realm, taking something apart to see how it works often involves finding out how to do that. Exploiting a flaw is analogous to taking the screws out of something to get the cover plate off. If a hacker broke into your house it would design a tool for doing so, disassemble your lock and put it back together again or find a weakness in the design of the lock that allows it to be opened without the key.
Script kiddies are those who are interested in getting into things, but either aren't interested in or able to take things apart themselves. The find tools that will work and need only enough understanding to roughly match a tool to a thing. There is a level of juvenile immaturity in this, like a child disassembling a radio with a hammer to find what is inside, with no thought as to how it might be reassemble or if this tool might cause permanent damage. If a script kiddie broke into your house they would break your lock with a Jimmie bar and probably spray paint a tag on your wall.
More recently we have criminals who will find / buy the tools to get into something for selfish gain. They may buy the understanding from a hacker, a duplicated key, or use a script kiddie type tool and find some way to monetize it
Neither of the first two implies malicious intent, however they may break the law in their pursuit of either learning something or showing their ability to affect their environment.
Would anyone modify these definitions in anyway ?
I'm tired of this terminology and on a half-hearted campaign to change it.
I'm in the old-school camp where "hacker"s are clever and not necessarily malicious.
"cracker" has the much-noted redneck connotation.
"jacker", partially from hijacker, is preferable. I guess I'd be satisfied with "cracker-jacker", too.
And with those searches I now add you to "the list"
Does it surprise anyone TFA is covered in ads for various security "solutions"? Script kiddies have been around forever, this article is just crap content intended to male the site go 'viral'. Why would /. Post this crap?
The right to protest the State is more sacred than the State.
Rape Sister is so the name of my next band.