
I think tumblr has a huge security hole - adrinavarro
http://pastebin.com/R2PJa6BU
======
nsfmc
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.

~~~
InclinedPlane
This isn't a bug, it's a failure of basic security principles. Imagine if the
super to your apartment complex accidentally mailed a box full of duplicate
keys to a local methadone clinic. That's not an embarrassing mistake, it's a
catastrophic error bordering on criminal negligence. Drawing attention to it
is meant to not only deepen the embarrassment and thus encourage fixing the
underlying problem so that it never happens again but also to let other people
know (such as tumblr users) about the amateurishness of the tumblr operation
and finally to encourage other developers out there to avoid making the same
mistakes.

~~~
smbwrs
You lost me at "bordering on criminal negligence". They gave away a lot of
details about how their internal systems are structured, but surprisingly
little as far as actual usable data. Passwords can be changed, API keys can be
disabled and regenerated, local IP addresses can be switched up. No user data
was revealed. How is this even close to criminal, let alone catastrophic? This
is pants-down embarrassing, at worst.

~~~
InclinedPlane
I meant in reference to the analogous hypothetical.

Tumblr isn't guilty of criminal negligence, but they are guilty of a very
serious failing of basic security precautions. Luckily there are other layers
of security at play preventing this from being a catastrophic disaster for
tumblr. However, if a group of thieves break into your bank and drill into
your vault you do not go home and rest easy because they only managed to drill
through two feet of your vault's hardened steel and there was an entire 3 or 4
inches more. Less so if you'd done something dumb like leave the keys to the
vault in a coffeeshop.

~~~
j2d2j2d2
I think you fail to give them credit for what they're attempting. Security is
the focus of many readers of HN, but Tumblr's focus is the user experience.

This isn't to say security isn't important, but they're rushing to make Tumblr
as fun to use as possible so they can survive.

Yes, they received money. They also have monstrous growth. _Now_ they can
afford to expand the engineering processes beyond, "get it working" to "make
it work really well and securely".

Good things are still to come from Tumblr so let's go easy on them when they
use duct tape instead an arc welder.

~~~
nettdata
Security isn't something you just bolt on after the fact, it's part of the
design, and involves so much more than just code.

If they failed to take security into account in the early stages, never mind
implement it at the beginning of development, then odds are they won't be
implementing it effectively any time soon, especially with the rate at which
they'll be expected to keep growing and adding functionality.

This kind of issue that they're showing now could (and probably should) have
been detected and handled early on, even with a simple third-party code
review.

And the fact that they are as big as they are, and growing as quickly as they
are, means that they should have an increased sense of responsibility when it
comes to security and protecting their users.

~~~
j2d2j2d2
The existence of one bug doesn't imply complete disaster everywhere. It should
be treated as an anecdote. Good science demands it.

Good science would also suggest Tumblr should get some experts to help them
discover anything else that might be lingering, which they're planning to do.
Much like a peer review process.

Your attitude is important for those in the security industry as it pushes
things forward, but remember that not everyone has the time to spend on it
that you might. It can either be an asset or the bane of your existence. As an
asset, you get paid for the things you understand because others don't. As the
bane of your existence, you fight society for not knowing what you know.

Tumblr is hiring. Maybe you should apply and help them fix it?

~~~
nettdata
To be clear, I didn't suggest a "complete disaster everywhere". That being
said, you can tell a lot about the state of the nation by something rather
simple and isolated as what they've experienced here. There are some rather
simple best practices that probably should be employed that apparently are
not, and even a cursory review probably would detected it.

I was, more than anything, responding to the parent's post regarding "they can
just add security later" idea.

It's true that I tend to work on projects where security is a huge deal
(online banking, government, global video game services including in-game
payments, etc). As the architect of these systems, a key part of the design is
security, and while other projects don't have to be quite as diligent, that
doesn't mean they should just ignore it altogether.

I'd also like to hope that my attitude is not just for those of us in the
security industry, but for everyone making web-based applications.

Personally, I think any online service does their current or potential clients
a disservice if they don't take security into account early on.

As soon as you take money from someone, I consider that to be a responsibility
that has been accepted to not only provide the functionality you offer, but to
do it in an appropriately secure manner.

It's the classic techie vs. sales guy argument; we don't want it perfect, we
want it on Wednesday.

The problem is that if even simple and effective security is overlooked or not
dealt with early on, you'll almost always be forced to accept a compromise
rather than take the required time to implement it properly.

As to the job, I'm already quite busy, thanks. Between implementing Oracle
clusters and my new startup that's just closing on our financing, I've got my
plate full.

Besides, I hate PHP. ;)

~~~
j2d2j2d2
I think this touches on PHP's real security issue.

It's easy to get going quickly but becomes an issue fast. Smart people tend to
move away from PHP, but startups find this difficult.

Hiring is then an issue and the bad practices persist.

~~~
nettdata
With all due respect, I'm not sure I buy that "hiring is an issue" argument.

You don't need someone full-time to help develop best practices, help design
or architect code/systems, or to do code reviews.

Any startup that gets funding should, in my opinion, get a short-term
consultant to come in, take a look around and offer suggestions and advice.
Even if it's just for a day. These are resources that have been there, done
that, and wouldn't be interested in a full-time gig with the company to begin
with. Even if the company could afford them.

Hopefully this isn't too far off topic, but it's something that I see missing
from a lot of clients that I get called into. (Not saying these guys haven't
done this, either.)

I think there's a lot of value for a startup to validate their work with
outside help, especially if they're relatively new to the game. Even if it's
just pointing them to some articles or reading for them to follow up on, or
just mentioning ideas of things they should look into; it can prove to be
huge.

For instance, I'm currently mentoring a few developers/teams on a part-time,
couple hours a week basis. Some of it is just being available on MSN to answer
a quick question every now and then, other times it's doing a couple code
reviews. Other times it's grabbing lunch/beer with them to discuss the
concepts of things like how to implement continuous integrated testing, or
managing other processes, or discussing new tech that they've heard of. For
the most part, they're not paid gigs either. I enjoy helping people do stuff
well, and the little bit of good faith help usually leads to some good future
work.

Sometimes all it takes is asking the right question to get them to think about
things in a different manner.

The last gig I got was for a major video game company. The job involved a .NET
stack, which I knew nothing about and had never worked with, not even a little
bit. I got the job despite that fact because in the interview I asked them
general (admiteddly leading) questions, such as "how are you handling _____,
or what is your plan for _____". Even though all of my experience had been in
non-MS tech stacks, the technical director that was interviewing me was
furiously taking notes. It was clear that they hadn't planned for some of the
things I was mentioning, never mind thought of them. But once they heard the
question, it was painfully obvious they should have. As a result, a 3-day
consulting engagement turned into full-time for two years.

In my case right now, I've sought a mentor in some new tech I'm working with
in my current startup. It's allowed me to hit the ground running, and take
advantage of their experience. A half day one-on-one made all the difference
for me, and will drastically improve the quality of what I'm doing.

------
stowaway
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.

~~~
nbpoole
Amateurish? Incompetent? It seems a bit extreme to make those generalizations
because someone made a typo in a PHP file that managed to hit production.

~~~
jasonlotito
They made a typo. Then they didn't test on their local machine. Then they
didn't test on a dev server. Then they didn't test on a staging server. Then
they didn't test on a live server. At no point did they do any form of
testing.

Judging by the mistake, I wouldn't be surprised if they edited the file live
on the server.

~~~
datasink
A production config file is typically an exception to the rule. If you have a
development team, you will probably not want each one of them to know what
your production passwords are. If you have sysadmins, they will probably want
none of the devs to know.

For what may be a thoroughly tested and properly deployed release, what
happens when a sysadmin needs to update a password for a database? In many
cases, without custom tools or a formal process, they'll just pop the config
file open with vi and rsync the change out to their web cluster. I'd bet this
is what happened in Tumblr's case. A sysadmin did it. Probably to avoid doing
a full production redeployment for a simple config update. They will put
resources into formalizing this now that they've been bitten.

~~~
jasonlotito
In my opinion, of course, sys admins shouldn't be touching configurations that
affect production code. You can have config files kept from the development
team, but only allow access to the actual config file to a few select
individuals if you need to. Sensitive data can be kept separated.

> For what may be a thoroughly tested and properly deployed release, what
> happens when a sysadmin needs to update a password for a database?

They coordinate the efforts with someone on the development team to deploy
this. A sysadmin touching source code is as bad as a developer making changes
to the networking side, especially if neither are talking back and forth.

This is how we work. Any changes made by networking are first vetted on by me,
for example, for the systems I'm responsible for. I work with them to ensure
that deployment is done at the proper time, and we handle any possible
problems on our end. The networking team doesn't touch anything we work on,
and vice-versa. Communication becomes key.

~~~
datasink
Coordinating between teams for any changes to a production config file is a
hard sell, but yes, this is the only really solid way to make certain stupid
mishaps don't happen. This is how we did it at my last company as well. In
addition to using production branches.

Most companies pin down their processes in response to issues that pop up.

------
yuvadam
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&...](http://www.google.com/webhp?hl=en#sclient=psy&hl=en&site=webhp&source=hp&q=site%3Atumblr.com+m3MpH1C0Koh39AQD83TFhsBPlOM1Rx9eW55Z8YWStbgTmcgQWJvFt4)

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

~~~
erikpukinskis
And it looks like the hole has been there for at least a month:

[http://www.google.com/search?q=site%3Atumblr.com+m3MpH1C0Koh...](http://www.google.com/search?q=site%3Atumblr.com+m3MpH1C0Koh39AQD83TFhsBPlOM1Rx9eW55Z8YWStbgTmcgQWJvFt4&hl=en&safe=off&sa=X&ei=kCCFTYW2L4uWsgPPvdiEAg&ved=0CAkQpwUoBg&source=lnt&tbs=cdr%3A1%2Ccd_min%3A2%2F1%2F2011%2Ccd_max%3A3%2F1%2F2011&tbm=#q=site:tumblr.com+m3MpH1C0Koh39AQD83TFhsBPlOM1Rx9eW55Z8YWStbgTmcgQWJvFt4&hl=en&safe=off&prmd=ivns&sa=X&ei=xiCFTfatN5D4swOYmcXlAQ&ved=0CA0QpwUoBg&source=lnt&tbs=cdr:1%2Ccd_min%3A2%2F18%2F2011%2Ccd_max%3A2%2F18%2F2011&tbm=&bav=on.2,or.r_gc.r_pw.&fp=9fb592477e9d4777)

------
zaidf
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).

~~~
tjogin
I think PHP has so many gotchas, so many ways to trip up even seasoned
developers, that it's inevitable to miss something.

~~~
VMG
Putting passwords in the php file? That's not a seasoned developer in my mind.

~~~
russss
I'm going to disagree with you. The problem with PHP is that there's no easy
way of sharing state between requests.

If you have a separate (ini-style) configuration file, every time you get a
new request, the file will have to be read in from disk and parsed. On
heavily-loaded web servers this can be a significant performance issue.

Configuration stored in a PHP file will be cached by your opcode cache and so
doesn't incur any per-request parsing/reading overhead.

The problem here is not that Tumblr stored their configuration in PHP. The
problem is their lack of testing their changes.

(As I mentioned elsewhere in the thread, this particular nasty issue can be
solved by simply enforcing that every .php file begins in '<?'.)

~~~
jasonlotito
> If you have a separate (ini-style) configuration file, every time you get a
> new request...

it will just pull it from the cache, not needing to be parsed or read from
disk.

Configuration stored in a PHP file is bad. Changing working code simply
because you want to add a new slave is a horrible idea. It would be like
having to recompile Apache from source every time you want to add a new vhost
because all the entries are written in C.

Interpreted languages like PHP, Python, Perl, etc all make it easy to put
config options directly into the language. When your app is small, it's fine.
But as it gets larger, move it out.

But yes, that they didn't even catch this is in testing is the real problem.

~~~
russss
> it will just pull it from the cache, not needing to be parsed or read from
> disk.

I don't believe PHP's ini_read caches anything. Sure, your OS cache is going
to have that file in, but PHP still has to do the fopen(), fread(), parse,
fclose() dance on every page hit. This does not happen with an opcode-cached
source file.

I have actually benchmarked this. Amortized across billions of page hits per
month it produces a notable saving.

Kudos points out that you could use APC - this is absolutely true but IMO it
basically equates to doing the same thing in a more complex way.

> Configuration stored in a PHP file is bad. Changing working code simply
> because you want to add a new slave is a horrible idea. It would be like
> having to recompile Apache from source every time you want to add a new
> vhost because all the entries are written in C.

This is a false comparison between interpreted and compiled languages. Not to
mention that plenty of C programs use #defines for configuration. Varnish even
translates its configuration language into C and dynamically loads it as a
module, which provides significant flexibility.

In a dynamic language, and where you trust the person doing the configuration,
there's no reason why your configuration shouldn't be in a source file. Both
Django and Rails do it this way.

~~~
carbon8
_"In a dynamic language, and where you trust the person doing the
configuration, there's no reason why your configuration shouldn't be in a
source file. Both Django and Rails do it this way."_

Not true. In Rails, sensitive information like database passwords or AWS keys
are _not_ stored in the source, you store them in configuration files, YAML
files by default. It's also widely recommended that these not be checked into
version control.

~~~
russss
My bad - it's been a while since I touched Rails and my memory was rusty.

------
Maxious
Official update from tumblr: [http://staff.tumblr.com/post/3959106211/update-
regarding-sec...](http://staff.tumblr.com/post/3959106211/update-regarding-
security-issue)

------
sudhirj
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.

~~~
xuki
Nope, you need the users' token to perform that (given that they gave post to
wall permission). However using Facebook secret key, you can ban users from
using your app. But then again, you need user id.

~~~
jimktrains2
But you could have users log into your site and then act as tumblre. If they
already OK'd the tumblr app, they would never know. Otherwise they'd just have
to ignore the screen saying what App you're OKing (and most people, I'd wager,
would, and just think you were using tumblr for something).

right?

------
smallwords
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.

~~~
elliottcarlson
Typos are very easy to make - but that's why you need to first test your code
locally, test your code in a development environment, have others test and
approve your code in a staging environment before a small typo gets to
production where something like this can happen.

------
FirstHopSystems
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.

~~~
jasonlotito
Do not store configuration in code. Store it in files that aren't part of the
software. Store this file outside the web root.

------
mrspeaker
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.

------
timerickson
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.

~~~
sudhirj
Well, at least they're using strong passwords. Fat lot of good it's doing
them, though.

~~~
smbwrs
If they're clever, that password isn't the actual password, it's a salted hash
that the Database class breaks down to the real password before connecting. In
theory, that hash alone shouldn't be enough for a breach, unless someone is
able to figure out how it's encrypted and salted.

~~~
xentronium
If you can "break down" something to real password, it's not hashing but
rather encryption. Anyways, I don't see how it helps if the actual php code is
exposed. Adding layers of super-duper-secret php code (Database class) is not
going to help if you display them in browser.

~~~
smbwrs
My point is more that there's at least one layer of protection between that
page and the actual password, which I'd say is more important than displaying
some code. It would take more than one mistake to really do damage, which is
better than nothing.

------
KevBurnsJr
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.

~~~
datasink
Where do you see this?

~~~
jeffreyg
the routes are defined on lines ~1160-5600

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

~~~
radq
Have you sent them an email about this?

~~~
sudhirj
Just did.

~~~
adrinavarro
Thanks, I really didn't know where to email them (nor I'm sober enough right
now to do that, IMHO)

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

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

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

------
mattmight
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.

------
holdenc
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?

~~~
oscardelben
By looking at the code !quality, I wouldn't be surprised to learn that they
have no tests at all.

~~~
pilif
How can you look at this code and make any statement about general code
quality? The stuff that was exposed was pure initialization code that would
look the same anywhere you look.

Granted. This should move outside of the web root, but just looking at this
one file that just sets up configuration values provides no ground to say
anything about general code quality

~~~
jasonlotito
> How can you look at this code and make any statement about general code
> quality? The stuff that was exposed was pure initialization code that would
> look the same anywhere you look.

No it doesn't. Having to modify live code just to change configuration options
is bad. If I want to add a new slave, or change some configuration option, it
should have no affect on running code. I shouldn't be changing any software
logic, and that's exactly what editing this file does.

Their are standard ways to avoid this. But no, if changing your config file
means changing what essentially amounts to changing the executable of your
code, you're asking for trouble.

~~~
bluesnowmonkey
It doesn't really matter if the configuration is in an executable form or not.
Without testing, you can break it either way. With testing, you probably
won't. They're equivalent.

~~~
jasonlotito
This issue isn't the site breaking. The issue is the leaking of the
configuration options. By removing it from the code, you can help avoid that.
And you can even go the extra step of making sure that even if you load a
broken config, the system will continue to use the old config.

------
adolph
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?

~~~
troels
Good point.

Just like you'd want to have a well described (preferably automated) way to
restore from backups, you should also have one for resetting all passwords.
Such a process is also useful for protecting against disgruntled employees.

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

------
jentulman
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.

------
tsigo
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.

------
nikcub
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';

~~~
russss
Then, if you accidentally edit your front controller file so that it starts
with 'i?php' instead of '<?php', it will get exposed.

This is what happened with Tumblr.

~~~
nikcub
You are right, it wil expose the front controller, but it wont expose the
includes from there. If you screw up the open tag on the config file, even if
it is outside of webroot it will be exposed

I just tested a few variations on one of my old projects and the reason why I
didn't see it is because I had ob_start() and was killing the buffer in my
templating class (which is a good idea)

not to mention that the db passwords were in an external yaml file anyway
(most of the frameworks do this) which would get loaded and cached

~~~
russss
The ob_start thing is an exceedingly good point and I don't know why I didn't
think of it myself. Probably because I haven't touched PHP in 3 years.

~~~
nikcub
> Probably because I haven't touched PHP in 3 years.

we should start a support group

------
didip
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')
      }

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

~~~
glesperance
They could make their app completely open source then ; in that way they'd
probably have a better quality assurance process than "suffer, apologize &
fix".

------
joshfng
It's been taken care of [http://staff.tumblr.com/post/3959106211/update-
regarding-sec...](http://staff.tumblr.com/post/3959106211/update-regarding-
security-issue)

------
virtualroot
[http://staff.tumblr.com/post/3959106211/update-regarding-
sec...](http://staff.tumblr.com/post/3959106211/update-regarding-security-
issue)

~~~
virtualroot
A human error caused some sensitive server configuration information to be
exposed this morning. Our technicians took immediate measures to protect from
any issues that may come as a result.

We’re triple checking everything and bringing in outside auditors to confirm,
but we have no reason to believe that anything was compromised. We’re certain
that none of your personal information (passwords, etc.) was exposed, and your
blog is backed up and safe as always. This was an embarrassing error, but
something we were prepared for.

The fact that this occurred at all is still unacceptable, and we’ll be
seriously evaluating and adjusting our processes to ensure an error like this
can never happen again.

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

~~~
reustle
Don't edit files on the production server?

------
jjm
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...

~~~
datasink
It's a config file. How can you make dozens upon dozens of unique memcache,
database, and defined constants DRY?

~~~
jjm
Thats the point. Who says it has to be a config file? Think outside the box.

Here is how Flask can do configuration (a Python micro framework):

<code>

class Config(object):

    
    
        DEBUG = False
    
        TESTING = False
    
        DATABASE_URI = 'sqlite://:memory:'
    
    

class ProductionConfig(Config):

    
    
        DATABASE_URI = 'mysql://user@localhost/foo'
    
    

class DevelopmentConfig(Config):

    
    
        DEBUG = True
    
    

class TestinConfig(Config):

    
    
        TESTING = True
    

</code>

~~~
datasink
Zend Framework also handles configs with inheritance. It's an elegant way to
handle overrides, no doubt. They do one better by allowing the definition to
be in ini files, which would have circumvented the Tumblr bug.

Still, I think config files are often best when they're verbose and as
straightforward as possible. There are fewer surprises this way. If I'm
working on a project by myself or with a very small team of people I trust,
I'd go the inheritance route. If the team is larger, I'd go the verbose route.

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

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

~~~
nikcub
that means the edit was done on the production server?

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

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

------
nikcub
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.

~~~
mattkirman
It doesn't really look like there was any attack. One of the developers made a
mistake with the PHP opening tag in the config file. Anyone visiting the page
would have seen this output.

~~~
bl4k
there are dozens of pages that have been exposed on this one server. I have no
idea how the opening tag can get mangled in so many different files

~~~
elliottcarlson
By having a central config file that is included throughout the pages. Once
included, it's not parsing it as PHP because it has the typo in it - thus
showing it on all pages that include that file...

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

~~~
yuvadam
Firewalls have got nothing on exposed API keys.

~~~
chuhnk
This is very true. In this case the obvious choice is to create new keys
although how inconvenient it will be I dont know.

