[langsec-discuss] XML DIGSIG langsec problems

Nils Dagsson Moskopp nils at dieweltistgarnichtso.net
Sat Aug 29 02:56:17 UTC 2015


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.sargent at 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 <dan at doxpara.com>
> Reply: Dan Kaminsky <dan at doxpara.com>>
> Date: August 25, 2015 at 10:01:27 AM
> To: langsec-discuss at mail.langsec.org <langsec-discuss at 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
>> > john at 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 at mail.langsec.org
>> https://mail.langsec.org/cgi-bin/mailman/listinfo/langsec-discuss
>>  
> _______________________________________________
> langsec-discuss mailing list
> langsec-discuss at mail.langsec.org
> https://mail.langsec.org/cgi-bin/mailman/listinfo/langsec-discuss

-- 
Nils Dagsson Moskopp // erlehmann
<http://dieweltistgarnichtso.net>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 212 bytes
Desc: not available
URL: <https://mail.langsec.org/pipermail/langsec-discuss/attachments/20150829/a3b18852/attachment.sig>


More information about the langsec-discuss mailing list