Re: [Json] Security Considerations

[Paul Hoffman <[e-mail]>]

On Jun 5, 2013, at 10:12 PM, Peter Brooks <[e-mail]> wrote:

> On 6 June 2013 02:20, Paul Hoffman <[e-mail]> wrote:
>> On Jun 5, 2013, at 10:58 AM, Douglas Crockford <[e-mail]> wrote:
>> 
>>> The section on security considerations is completely inadequate. It is describing a use of JavaScript eval that is now considered to be a very bad practice, and it provides no advice for other languages.
>>> 
>>> It should instead be advising care when constructing JSON texts, insisting on proper encoding practices and avoidance of concatenation.
>> 
>> Who wants to take a stab at proposed Security Considerations wording? This should probably go in Section 7, not Section 6, so that allows a bit more formatting such as headers and such.
>> 
> How far can this go before it becomes completely new stuff that should
> be excluded from the scope?

That is a WG call.

> For security to work, each object ought to be able to specify the
> roles that have read or modify access - with a well defined policy
> (echoing the current position for backwards compatibility) to describe
> what happens when there are no access rights defined for an object.
> 
> It is good practice for the actual security requirements for each
> object to be documented in the object - if they are not, and
> application logic is relied upon to provide access control, then it is
> difficult, if not impossible, to have proper governance of access
> control. There is no better documentation than that that provides the
> actual control.


Useful security considerations for a format include "Emitting X might be dangerous" and "Parsing Y might be dangerous". There are probably others.

--Paul Hoffman