chr13

"buying 1Gbps uplink is trivial"

1 Gbps dedicated uplink is not trivial everywhere in the world. You also need more quota. Facebook easily crawled more than 1 TB of data during an hour. The more the better may not be best solution here. The higher the uplink, faster Facebook may crawl. So instead of transfering 1 TB in an hour for a 1 Gbps uplink, the transfer will be 10 TB if you have 10 Gbps. This will also depend how much bandwidth they allow their crawler, there must be an upper limit though.

We also have to remember that these requests are shared between 100+ Facebook server.

Actually the number of HTTP requests is 180,000+.

It's not clearly stated. I think what they mean to say is DoS on Facebook using brute force mechanism as testing this would bring down the Facebook system itself. Now manipulating Facebook's server to cause the attack, that'd be different I guess.

I actually found this bug first in Facebook and later in Google. Facebook said they needed time to think about this and I was hoping they would fix it, so I could not disclose this back then.

Don't want to disclose anything at this point but at least one other huge bandwidth owner suffers from this type of attack. Combined, it is clearly a disaster for any small-medium business.

May be they should visibly put that FeedFetcher can crawl your website can incur 1TB bandwidth in couple of hours ? May be apache and other httpd should block these crawlers by default ? How else would anyone know about a certain Google feature that could be disaster for them ?

Multiple spreadsheets ?

Thanks, I've updated the post.

Yes of course. But then do those dynamic images serve any purpose on a spreadsheet ? If a user needs a dynamic image he can download it to his own machine and upload it. Of course if he need many dynamic images, then that's another question.

Indeed, I've quoted that article. But it doesn't talk about random parameters which makes it so easy to attack any website not just your own where you know what the urls are.

I guess you summed it up. Indeed having more depth in a language is very important and useful, I was just trying to make a point that these aren't the only things. Here is how I perceive a language,

It is made up of syntax and behaves in a certain way. If you read the documented features you'll know all of it. There may be some undocumented things which may not be of utmost importance. However, this is just the base of programming. And when you start dealing with 5-6 languages you can forget things if you don't have a good memory but the good thing is it's all documented and known features. Whereas while programming, one can often be involved in solving unknown problems, which can't be figured out just by googling.

This is the excerpt from the reply

"Sorry it took a while to respond. It took us longer than normal because we have had a few weeks of higher than average volume and this ticket was marked as fixed but we hadn't corresponded back to you yet."

"This was indeed fixed by a separate diff that had been committed but was not yet live when you submitted the issue. So in this case we didn't learn about a new issue but we did double-check some of our assumptions around this stuff."

And I got a reward of $500. Here is the POC http://www.youtube.com/watch?v=x5HXv7nPgYo

Thanks for the reply, that clears things up.

I think the report number is 173358208.

So am I and I've mostly used a subset of C features to solve many problems. I've also seen some C 'experts' fail to come to a proper solution even if they know all the features.

It may not be intentional but what about unintentional fixes ? What happens to bugs that were valid when posted but fixed (unintentionally) right after a release/code deployment.

You missed a key point, "responsible disclosure". Not only to the company but to the public. I care less about whatever bounty they give or do not give. They could just deny the bug but this lingering is too much. I like Google's program where you have to wait x number of days and then you can disclose any bug. I guess all I wish from these programs is that they fix the bugs fast which is good for them. I did not spent time to enter anywhere. I was just curious 1 day and played around for an hour or two. I guess you are assuming too much about me and my capability and you cared so much as to create an account just to reply to this post...meh :/

I guess it depends on what you consider "real problems". One can always write good and efficient code by following what he/she knows is the defined behavior. Just found weird that some things related to standards were given more importance whereas problem solving is the key while writing any program.

I haven't seen these tricks come into play when solving real problems at ALL. Not saying you should not know the language, but better to have problem-solving skills than rot the standard. The bit about leaving a new line after main tells me she really has memorized the standard.