2012/3/7 Ángel González
> On 07/03/12 00:04, Adam Jon Richardson wrote:
> > It would be the responsibility of the framework or CMS or application
> > to protect against this type of attack (which they do quite well.)
> > When you can force a plugin to work through your API, you can take
> > appro
On Mon, Mar 12, 2012 at 5:08 PM, Richard Lynch wrote:
> On Tue, March 6, 2012 3:30 am, Florian Anderiasch wrote:
>
> Security by blacklist almost always isn't security...
>
> You're bound to miss one of the functions you should have blacklisted,
> but didn't.
>
Agreed. The approach I'm developi
On Tue, March 6, 2012 3:30 am, Florian Anderiasch wrote:
Security by blacklist almost always isn't security...
You're bound to miss one of the functions you should have blacklisted,
but didn't.
Something like Drupal would be crippled by this because major
extensions used by all rely on access t
On 07/03/12 00:04, Adam Jon Richardson wrote:
> It would be the responsibility of the framework or CMS or application
> to protect against this type of attack (which they do quite well.)
> When you can force a plugin to work through your API, you can take
> appropriate measures. When the plugin can
2012/3/6 Ángel González
> On 06/03/12 14:04, Adam Jon Richardson wrote:
> > The sandbox I'm considering would only impact the ability to directly
> call...
> It's not that easy. The internal functions could be splitted to
> safe/unsafe (according
> tosome definition, which would itself be a contr
On 06/03/12 14:04, Adam Jon Richardson wrote:
> The sandbox I'm considering would only impact the ability to directly call
> internal functions. The idea rests on the hope that the framework or CMS
> provides a security model that protects the integrity of their own
> environment. The framework can
On 03/06/2012 06:03 AM, John Crenshaw wrote:
> I've seen a simple "safe" code evaluator put together using token_get_all.
> I'm certain that you could create an include_restricted() function in
> userland using a similar system: walk through the tokens looking for anything
> forbidden (this will
>> Hi!
>>
>> Thoughts?
>>>
>>
>> This is a fine idea, however actually doing it is not that easy. Note
>> that knowing which function is "safe" is pretty hard, but that's only a
>> start.
>> Plugin code, for example, can call functions outside plugin context,
>> while passing all kinds of argum
On Tue, Mar 6, 2012 at 4:38 AM, Stas Malyshev wrote:
> Hi!
>
> Thoughts?
>>
>
> This is a fine idea, however actually doing it is not that easy. Note that
> knowing which function is "safe" is pretty hard, but that's only a start.
> Plugin code, for example, can call functions outside plugin cont
On Tue, Mar 6, 2012 at 3:30 AM, Florian Anderiasch wrote:
> Isn't that basically what all template engines tried to solve before
> with giving you a defined subset of tokens that are more or less
> directly converted to php code? The benefit I see is that plugin
> developers wouldn't need to learn
Hi!
Thoughts?
This is a fine idea, however actually doing it is not that easy. Note
that knowing which function is "safe" is pretty hard, but that's only a
start. Plugin code, for example, can call functions outside plugin
context, while passing all kinds of arguments - is it safe or not? I
Hi,
On 03/06/2012 08:34 AM, Adam Jon Richardson wrote:
[...]
> 1) Internal functions seen as universally safe would by default be allowed
> (e.g, str_replace(), array_pop(), etc.)
> 2) Unsafe internal functions would have to be explicitly declared (e.g.,
> file(), stream_*, etc.)
> 3) Any includes
Plugins are a big deal (see
http://oneofmanyworlds.blogspot.in/2012/03/difficult-decision.html for a
recent example.) In this era of mashups and breakneck innovation,
developers must rely on vast amounts of code they've never seen, let alone
audited. Wordpress, Drupal, and many other tools develope
13 matches
Mail list logo
