Subject: [Json] Security Considerations

From: Douglas Crockford <[email-masked]>
Date: Wed, 05 Jun 2013 10:58:45 -0700

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.

---

From: Gonzalo Salgueiro <[email-masked]>
Date: Wed, 5 Jun 2013 14:06:36 -0400

Completely agree.  Needs some serious updating and would love to see it be more JS agnostic.

--G

On Jun 5, 2013, at 1:58 PM, Douglas Crockford <[email-masked]> 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.
> _______________________________________________
> json mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/json
>

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 5 Jun 2013 17:20:36 -0700

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

--Paul Hoffman

---

From: Peter Brooks <[email-masked]>
Date: Thu, 6 Jun 2013 07:12:40 +0200

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

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.

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 6 Jun 2013 08:37:50 -0700

> be excluded from the scope?

That is a WG call.

> control. There is no better documentation than that that provides the

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

--Paul Hoffman

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 6 Jun 2013 18:45:32 +0200

On Jun 6, 2013, at 17:37, Paul Hoffman <[email-masked]> wrote:

> security considerations

I might be stating the obvious here, but:

3552 Guidelines for Writing RFC Text on Security Considerations. E.
     Rescorla, B. Korver. July 2003. (Format: TXT=110393 bytes) (Also
     BCP0072) (Status: BEST CURRENT PRACTICE)

(Clearly, a large part of that doesn't apply here, but that exactly may be the most important input from that document.)

Grüße, Carsten