JSON is not a JavaScript subset. The U+2028 and U+2029 line terminators are allowed in a JSON string, but are not allowed in JavaScript strings.
Will Sargent <will.sarg...@gmail.com> writes: > I’m happy that JSON doesn’t suffer from the complexity that XML does, but I > find it bizarre that the answer to a “markup language” is a formalized subset > of Javascript. > > -----Original Message----- > From: Dan Kaminsky <d...@doxpara.com> > Reply: Dan Kaminsky <d...@doxpara.com>> > Date: August 25, 2015 at 10:01:27 AM > To: langsec-discuss@mail.langsec.org <langsec-discuss@mail.langsec.org>> > Subject: Re: [langsec-discuss] XML DIGSIG langsec problems > >> Once upon a time you could provide XSL style sheets for canonicalization. >> And then they added JS to XSL. >> >> To validate my signature, run my code. >> >> Yup >> >> On Tuesday, August 25, 2015, wrote: >> >> > >> > http://www.contextis.com/documents/33/Exploiting_XML_Digital_Signature_Implementations-HITBKL20131.pdf >> > >> > >> > By signing XML content, rather than the raw bytes of an XML >> > document, the W3C were faced with a problem, specifically the >> > possibility that intermediate XML processors might modify the >> > document's physical structure without changing the meaning. >> > >> > At this point you are permitted to start chuckling, privately. >> > >> > An obvious example is text encodings. As long as the content >> > is the same there is no reason why an XML file stored as UTF-8 >> > should not have the same signature value as one stored as >> > UTF-16. There are other changes which could occur which don't >> > affect the meaning of the XML but would affect its physical >> > representation, such as the order of attributes, as the XML >> > specification does not mandate how a processor should >> > serialize content. >> > >> > Eyebrows raised. >> > >> > With this problem in mind the W3C devised the canonical XML >> > specification which defines a series of processing rules which >> > can be applied to parsed XML content to create a known >> > canonical binary representation. For example, it specifies the >> > ordering of attributes, and mandates the use of UTF-8 as the >> > only text encoding scheme. >> > >> > Summary: We won't specify how you serialize it, only how you serialize >> > it to validate the signature. As a result, you have to parse the >> > untrusted message and expose parsing and canonicalization to the >> > anonymous attack surface before determining the signature is invalid, >> > assuming you even managed to check that properly: >> > >> > >> > https://lists.w3.org/Archives/Public/public-xmlsec/2009Nov/att-0019/Camera-Ready.pdf >> > >> > http://www.slideshare.net/44Con/the-forgers-artjamesforshaw44con2k13 >> > >> > https://www.owasp.org/images/5/5a/07A_Breaking_XML_Signature_and_Encryption_-_Juraj_Somorovsky.pdf >> > >> > >> > https://www.usenix.org/system/files/conference/usenixsecurity12/sec12-final91.pdf >> > >> > >> > Countermeasures: >> > >> > http://arxiv.org/pdf/1401.7483.pdf >> > >> > Proposed that the anonymous attack surface be required to do minimum >> > processing on untrusted input before authentication/authorization. >> > That means no parsing, nothing more complicated than slicing off a >> > signature and validating it. Proposed that this not just encourages >> > security in the non-authenticated case, it also minimizes the work to >> > validate the security of the anonymous attack surface. >> > >> > Open question: how much flexibility in cipher negotiation or choices >> > and serialization can be done safely during this stage. Compare >> > OpenSSL. Considered that flexibilty (which requires more complex >> > pre-auth logic) comes with risk, but if chosen carefully can be >> > minimized. >> > -- >> > http://www.subspacefield.org/~travis/ | if spammer then >> > j...@subspacefield.org >> > "Computer crime, the glamor crime of the 1970s, will become in the >> > 1980s one of the greatest sources of preventable business loss." >> > John M. Carroll, "Computer Security", first edition cover flap, 1977 >> > >> _______________________________________________ >> langsec-discuss mailing list >> langsec-discuss@mail.langsec.org >> https://mail.langsec.org/cgi-bin/mailman/listinfo/langsec-discuss >> > _______________________________________________ > langsec-discuss mailing list > langsec-discuss@mail.langsec.org > https://mail.langsec.org/cgi-bin/mailman/listinfo/langsec-discuss -- Nils Dagsson Moskopp // erlehmann <http://dieweltistgarnichtso.net>
pgpbnRMVJWi2c.pgp
Description: PGP signature
_______________________________________________ langsec-discuss mailing list langsec-discuss@mail.langsec.org https://mail.langsec.org/cgi-bin/mailman/listinfo/langsec-discuss
