User: Password:
|
|
Subscribe / Log in / New account

Shifting blame

Shifting blame

Posted Mar 8, 2012 18:11 UTC (Thu) by martin.langhoff (subscriber, #61417)
In reply to: Shifting blame by man_ls
Parent article: GitHub incidents spawns Rails security debate

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


(Log in to post comments)

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.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds