In the abstract, i understand, why anyone would post this. I get it, and maybe i'm getting older or something, but part of me equates posting this sort of thing with pointing at an acquaintance on the street with his fly down and having a laugh with your friends rather than telling him and having a chuckle after he's zipped up.

But the whole self-righteous and incredibly passive-aggressive "man, i think these guys have a huge problem..." followed by the "man, these guys need to shape up" and "n00b mistake!" are unproductive to the extreme.

I mean, find a bug, report it, move on. Maybe i've got some unrealistic notion of karma or general human benevolence or something, but it seems hard to believe that this is such a difficult path to take especially when nearly everyone commenting has to deal with bs of this sort day-in/out.

TL;DR: Amateurish PHP developers at Tumblr fuck up; HN developers who don't know PHP that well make wildly incorrect assumptions about PHP.

People, I know it's en vogue to bash PHP (just wait, in a few years it'll be Ruby and Python - remember, PHP was once hyped, too, and now it's going in the other direction) - but if you criticize PHP, could you at least try to sound like you've actually developed in PHP for more than a week?

Because most of the negative comments here about PHP have absolutely nothing to do with PHP as such - the Tumblr error in question has to do with incompetent programmers. If you read The Daily WTF you'll know that incompetent programmers can screw up no matter what language they're using.

Mirrored to http://codepad.org/UP3FxRNv

Just in case.

edit: oh man. Check out what Google has on this[1]

edit: in readable form on github gist[2]

[1] - http://www.google.com/webhp?hl=en#sclient=psy&hl=en&...

[2] - https://gist.github.com/29c5c5970d1f3313abd1

We saw this from facebook few years ago. Now with tumblr. Is there something at core of php that makes this inevitable? I ask this as a concerned php dev(and not out of snark).

Official update from tumblr: http://staff.tumblr.com/post/3959106211/update-regarding-sec...

They've got their Twitter / Facebook / oAuth secret keys in there. Doesn't that mean everyone who sees this can act as Tumblr post to those services on behalf of users?

I hope they've changed them.

Whilst I hope tumblr correct the problem rather quickly as it is a major problem, I find those jumping to blame are forgetting one small problem. No programmer is perfect, typos are easy to mistake on any keyboard and it will happen to everyone no matter how much of a ‘ninja rockstar poodle’ they think they are.

I hate to see someone else work in the clear like this. It’s like popping a zit before your first date. It’s painful and will show up for day/s afterwards. Now I know what will be today’s headline I can bypass techmeme.

Yes its a big boo boo. It’s a massive security risk and to some it may feel like the end of the world but by then it will be tomorrow. Passwords will be reset, keys will be replaced and the valley will be talking about something else. Hopefully it won’t be someone else’s mistake.

P.S Don’t forget to test your code before deploying – now you know why.

I always use a include for any hashes or passwords in a separate file. When I started learning PHP I exposed my MySQL database password more times then I could keep track of.

It does hammer home the point of staging before deploying. Also the point of making sure you vary your passwords between sites.

I know it's easy to criticize, but far out Tumbler, you guys really have to get your act together - the downtime and general laggy-ness is at least understandable, but there is no excuse for absolute newbie foul-ups like this.

Although, on the plus side, having a site that mashes up tumbler as a content provider certainly has given us plenty of opportunity to fine tune and improve our caching strategy.

I sure hope they realize they just broadcasted the pass for the "tumblr3" database user, as well as their Twitter, Facebook, Recaptcha and other secret keys.

You can clearly see all the routes in the app. 400+ routes and only 11 controllers. Most routes are concentrated on 3-4 controllers. Each of those controllers has got to be 10,000-20,000 lines apiece.

The dashboard controller alone has approximately 120 actions.

They were throwing this when opening a tumblr blog. A twitter search reveals some people have seen this message too.

AUTHORIZE_ID and AUTHORIZE_SECRET_KEY... anyone know if those are for Authorize.net? Yikes.

There was a similar "gaping" hole 2 years back. http://news.ycombinator.com/item?id=164422 Better email them.

Found a link with better formatting on twitter: https://gist.github.com/29c5c5970d1f3313abd1

If we want security, programming languages must either make secure code easy to write or insecure code impossible to write. (Or both!)

PHP doesn't do well on either count.

Writing secure PHP code isn't impossible, but it's tedious even for seasoned developers.

Can someone please explain this a little more? My basic understanding is that they incorrectly opened a PHP tag and exposed the code. If that's the case, wouldn't the page have appeared broken in development? Or have been found during testing?

If one accepts that errors like these happen, I guess it would be a good idea to have an automated way to quickly change passwords on all the services that are used. Does anyone have some citations for literature on how to deal with that?

"this is not what I had in mind when I said we should open source the backend"

Regardless of how it occurred, and given that this isn't a language issue, I have two questions....

Does anyone know how long was it actually in this state? (There's a heck of a lot of entries in the Google search quoted in another comment, but then how often does Google index tumblr?)

Did no-one at least press F5 or CMD-R after making the edit, let alone run tests? Quality control is the real issue. I can easily imagine myself making this mistake, typo's are the source of the majority of my bugs, but I find it hard to imagine taking more than 10 seconds to notice it.

undefined

I haven't used PHP heavily in about 2 years, but it surprises me that at this point there's not a configuration setting that negates the need for the opening PHP tag and instead just treats everything in a .php file as php.

I doubt anyone using PHP at Tumblr's level is mixing raw HTML into their PHP files and thus has no need for the php tags.

If you have a PHP app, place nothing inside of web root other than an include to your front controller. This is all that should ever get exposed:

    include '../app/front_controller.php';

All this could have been avoided by using:

  if(getenv('tumblr_env') == 'production') {
    //See: http://php.net/manual/en/function.register-shutdown-function.php
    register_shutdown_function('five_hundred_err_func')
  }

I bet the tumblr developers are happy 100+ people are debugging their mistake.

It's been taken care of http://staff.tumblr.com/post/3959106211/update-regarding-sec...

http://staff.tumblr.com/post/3959106211/update-regarding-sec...

undefined

How to prevent a leak like Tumblr's - http://news.ycombinator.com/item?id=2343561

I rarely go off like this but man, look at this PHP file!

It's a mess! Very long, not dry, no wonder the dev fat fingered it...

Is the rest of the framework like this?

No headless output testing? Manual output checking (at the least)?

For the record, as much as I hate to admit it now I was a big long time PHP developer. My code is used round the web today...

I feel really bad for them right now, but I can't stop reading it.

This looks like a vim switching mode mistake to me. Oh humans...

undefined

Clicked on link, just saw a huge ad and no obvious way to dismiss it.

Its not HUGE.

I tought tumblr.com was build with Ruby on Rails.

the attacker left their IP address in the dump, and their LAN interface address

Edit: it's whoever dumped this as opposed to an attacker

I don't think tumblr have acted on this yet. The other exposed pages have S3 API secret keys, facebook api secret keys, the username and passwords for vimeo, clickatell (whatever that is), twitter oauth secret key, etc. they are going to have to revoke and re-setup each of these.

I hope their firewalls are good because this may instigate an attack. Tumblr, 80,443,established,related accept, all else DROP.