Re: [secdir] SECDIR review of draft-ietf-jcardcal-jcard-05

[Philipp Kewisch <[e-mail]>]

On 7/17/13 10:15 PM, Stephen Kent wrote:
>
> This document cites the Security Considerations section of original 
> vCard RFC (noted above) as the primary content for its Security 
> Considerations section. It asserts that no new security concerns arise 
> with respect to _calendar data_, because this specification merely 
> maps the original vCard data to a new format.However, it then cites 
> the Security Considerations section of the JSON specification (RFC 
> 4627) noting that there are additional security risks that arise from 
> using JSON to represent vCard data! To me these two statements seem 
> somewhat contradictory, but that can be addressed by refining the 
> wording here.
>
> More worrisome is the fact that this very brief section mentions only 
> calendar data security. Does that mean that no other type of vCard 
> use, when using JSON encoding, creates any new security concerns? This 
> document is much broader in scope than just iCal data (the subject of 
> draft-ietf-jcardcal-jcal-07), so this narrowly focused comment seems 
> out of place.
>
Yes, this was a copy/paste fail from the jCal draft. I've corrected both 
instances of "calendar" to "vCard".

OLD:
    For security considerations specific to calendar data, see Section 9
    of [RFC6350].  Since this specification is a mapping from vCard, no
    new security concerns are introduced related to calendar data.

NEW:
    For security considerations specific to vCard data, see Section 9 of
    [RFC6350].  Since this specification is a mapping from vCard, no new
    security concerns are introduced related to vCard data.

> RFC 6350's Security Considerations section notes few concerns that are 
> Vcard-specific; most of the comments in that section relate to the 
> need to provide security for vCards when they are transported, e.g., 
> via email. All of these concerns are equally applicable here, as 
> indicated, without the calendar data comment.
>
Taken care of by the previous change.

> RFC 4627's security considerations section turns out to be an indirect 
> reference to two paragraphs in the IANA Considerations section! (This 
> seems silly and it's not clear why that document was published with 
> such an obvious structural error, but ...). The security concern cited 
> in 4627 is that JavaScript (JS) is a scripting language and thus JSON 
> might be used to execute malicious JS. However JSON is intended to be 
> a "safe" subset of JS, i.e., it should be able to be evaluated in JS 
> without security concerns, if it is properly constrained.The text in 
> 4627 provides two regular expressions that can be invoked to strip any 
> characters that might cause security problems. I'd feel a lot more 
> comfortable if this text were explicitly replicated in this I-D, and 
> the I-D _mandated_ this processing step before passing the Jcard data 
> to JS. (It might even make sense as a post processing step as part of 
> the vCard to JCard processing described in Section 3.) The level of 
> indirection currently used in the Security Considerations section, and 
> the casual advisory nature of the original text might easily be 
> overlooked by an implementer.
>
> Finally, the notion of JSON as "safe" JS subset assumes that the 
> parser processing the JSON does not have a security flaw. Such flaws 
> have been identified, one as recently as February of this year. It 
> might be good to note that this represents a new type of security 
> concern that would not arise in a conventional vCard context.
>
As most popular JavaScript implementations use JSON.parse() for parsing 
JSON data, I don't see the need to put this into Section 3. I've changed 
the text to include the regex and a little more information from what 
you wrote via email, let me know what you think:

OLD:
    The use of JSON as a format does have security risks.  Section 7 of
    [RFC4627] discusses these risks.

NEW:
    The use of JSON as a format does have security concerns.  Even though
    JSON is considered a safe subset of JavaScript, this does not ensure
    that the parser processing JSON does not have a security flaw. When
    processing jCard data, this concern should be taken into account as
    it doesn't arise with conventional vCard data.

    As with JSON, when passing jCard data to JavaScript's eval()
    function, certain precautions must be taken to ensure that no
    security issues arise.  Specifically, all characters not enclosed in
    strings MUST exclusively be in the set of characters that form JSON
    tokens.  This can be quickly determined in JavaScript with two
    regular expressions and calls to the test and replace methods.

    var my_jCal_object = !(/[^,:{}\[\]0-9.\-+Eaeflnr-u \n\r\t]/.test(
           text.replace(/"(\\.|[^"\\])*"/g, ''))) &&
       eval('(' + text + ')');

    See also Section 7 of [RFC4627] for security considerations of the
    JSON format.