| |||||||||||||
Shifting blameShifting blamePosted Mar 8, 2012 14:00 UTC (Thu) by man_ls (subscriber, #15091)Parent article: GitHub incidents spawns Rails security debate Thanks for a complete and balanced explanation. If anything it is a bit biased for Homakov, but I can't see how it might be otherwise. The whole affair is a strong argument for full disclosure, but also for publishing exploits instead of "concept code". A gaping hole goes unfixed for 3+ years; framework developers even justify its existence and shift blame to application developers. Then it is exposed and tested in practice by an enterprising user, and suddenly it is closed in the target application -- and in the framework. If we are to judge actions solely by their consequences there is no doubt in this case, and the means used were quite mild too, even amusing. github, after the initial denial, has answered quickly and thoroughly: it has requested its users to do a key audit for all the repos (I received mine late last night). It appears that they have done a complete security assessment, forward looking and also including the possible consequences. I cannot help but remember how in a recent article some commenters were disparaging PHP and recommending Rails or other "sane" frameworks. It is ironic how PHP closed this particular hole years ago, but PHP devs downplayed a similar problem for 3+ years. I for one am glad to be using PHP right now, and to be aware of its security problems; while Rails users just had a sense of false security all this time.
(Log in to post comments)
Shifting blame Posted Mar 8, 2012 16:29 UTC (Thu) by angdraug (subscriber, #7487) [Link] You obviously meant to say "but Rails devs downplayed a similar problem for 3+ years"?
Shifting blame Posted Mar 8, 2012 17:07 UTC (Thu) by man_ls (subscriber, #15091) [Link] Yep, thanks for the correction!
Shifting blame Posted Mar 8, 2012 18:11 UTC (Thu) by martin.langhoff (subscriber, #61417) [Link]
"Thanks for a complete and balanced explanation"
+1. Excellent article.
Clearly, when building a fast development framework you have every temptation to have options that trade security for ease-of-development. After many years of fighting with register_globals in PHP apps (ie: Moodle) my take is that, if you need those options in your framework, they MUST default to off, and they MUST carry a scary name.
The name matters. It has to trigger two conversations:"Why does this app / toolkit required that we set development_unsafe_hackme_register_globals=Yes?" and "does your patch/feature need development_pwnme=Yes to work?".
And eventually "I don't think I want to use this patch / toolkit / app, if we have to enable developer_unsafe_mode=Yes I fear the developers are not security conscious".
PHP has various such configurations... register_globals got fixed, but "display_errors", with that meek name, it still defaults to sending full error output to the client, which can leak a lot of data to a potential attacker.
Shifting blame Posted Mar 9, 2012 13:44 UTC (Fri) by Kwi (subscriber, #59584) [Link]
display_errors is useful during development. register_globals is not (since the program wouldn't run in production). But there are other examples.
The PHP developers have a bad attitude towards security; seems the Rail developers have, too. Time for Rail developers to look for alternatives.
|
|||||||||||||