Latacora's blog post "How (not) to sign a JSON object" cautions against signing JSON by stringifying it before applying a signature. This approach is vulnerable to attacks that modify whitespace or key ordering, which changes the string representation without altering the JSON's semantic meaning. The correct method involves canonicalizing the JSON object first – transforming it into a standardized, consistent byte representation – before signing. This ensures the signature validates only identical JSON objects, regardless of superficial formatting differences. The post uses examples to demonstrate the vulnerabilities of naive stringification and advocates using established JSON Canonicalization Schemes (JCS) for robust and secure signing.
This blog post from Latacora, titled "How (not) to sign a JSON object (2019)," discusses the intricacies and common pitfalls of digitally signing JSON objects, specifically focusing on ensuring the integrity and authenticity of the data. The author emphasizes that simply signing a JSON string representation is insufficient due to the flexibility of JSON syntax. Variations in whitespace, key ordering, and numeric representation can all result in different string representations of the same underlying JSON object, leading to signature verification failures even though the semantic meaning of the data remains unchanged.
The post meticulously dissects several flawed approaches, illustrating the vulnerabilities they introduce. One such approach is naively signing the stringified JSON. This is problematic because different JSON libraries might produce slightly different string outputs for the same JSON object, causing signature verification to fail. Another inadequate method involves canonicalizing the JSON before signing, but relying on insufficiently rigorous canonicalization methods. For example, simply sorting keys alphabetically doesn't account for variations in numeric representation or whitespace.
The author then proposes a more robust solution: using a deterministic JSON serialization method. This method ensures that a given JSON object will always be serialized into the exact same string, regardless of the platform or library used. By signing this deterministic representation, the signature will reliably verify as long as the underlying data remains unchanged. The post highlights the importance of using a well-defined and widely adopted canonicalization algorithm to avoid interoperability issues.
Furthermore, the blog post delves into the security implications of using non-deterministic JSON serialization. It explains how an attacker could potentially manipulate the JSON structure, altering insignificant details like whitespace or key order, to create a different string representation that still carries the same semantic meaning but invalidates the signature. This could allow for undetected tampering with the data.
The post concludes by recommending specific libraries and tools for implementing secure JSON signing, emphasizing the critical need for careful consideration of these seemingly minor details to guarantee the integrity and authenticity of signed JSON objects. The overall message is that signing JSON requires a meticulous and deliberate approach, relying on established standards and deterministic serialization to prevent vulnerabilities and ensure the reliability of digital signatures.
Summary of Comments ( 0 )
https://news.ycombinator.com/item?id=42990948
HN commenters largely agree with the author's points about the complexities and pitfalls of signing JSON objects. Several highlighted the importance of canonicalization before signing, with some mentioning specific libraries like JWS and json-canonicalize to ensure consistent formatting. The discussion also touches upon alternatives like JWT (JSON Web Tokens) and COSE (CBOR Object Signing and Encryption) as potentially better solutions, particularly JWT for its ease of use in web contexts. Some commenters delve into the nuances of JSON's flexibility, which can make secure signing difficult, such as varying key order and whitespace handling. A few also caution against rolling your own cryptographic solutions and advocate for using established libraries where possible.
The Hacker News post "How (not) to sign a JSON object (2019)" has generated several comments discussing various aspects of JSON signing and security practices.
Several commenters focus on the importance of canonicalization before signing. One commenter emphasizes that the article's core message boils down to "canonicalize before signing," highlighting how failing to do so can introduce vulnerabilities. They further illustrate the point by referencing Python's
json.dumpsfunction and how different keyword arguments can lead to different string representations of the same JSON object, ultimately resulting in different signatures. Another commenter points out that using JSON for signing is inherently tricky due to the numerous variations possible in a serialized JSON object. They recommend CBOR (Concise Binary Object Representation) as a more suitable alternative for signing because of its consistent binary representation. This reinforces the idea that using a standardized, unambiguous data format is crucial for secure signing.The discussion also delves into specific vulnerabilities related to different JSON parsing libraries. One commenter mentions that some libraries accept duplicate keys, which can be exploited by attackers. They suggest that "canonicalization is about enforcing a schema and rejecting invalid input," emphasizing that strict validation is essential for preventing such attacks. Another user highlights specific problems with PHP’s
json_decodefunction and how it handles duplicate keys, which could further expose systems to security risks if not carefully addressed.Another thread in the comments explores the concept of "deterministic JSON," where commenters discuss the challenges in achieving consistent serialization. One commenter notes the difficulty of creating a truly deterministic JSON representation across different languages due to variations in floating-point representations, character encoding, and key ordering.
Several users shared examples of libraries and tools designed for secure JSON signing, including
json-canonicalizeand various JWS (JSON Web Signature) libraries. These comments offer practical solutions for developers seeking to implement secure signing practices.Finally, there's some discussion around JSON Web Signatures (JWS) and JWT (JSON Web Tokens). One commenter criticizes the use of JWT, arguing that JWS provides more flexibility and is sufficient for most use cases. They imply that JWT adds unnecessary complexity and might encourage less secure practices. Another user reinforces this by suggesting the use of detached signatures, emphasizing that signing only the relevant data minimizes the attack surface.
In summary, the comments on the Hacker News post highlight the critical importance of canonicalization before signing JSON, discuss the challenges and vulnerabilities associated with inconsistent JSON representations, recommend alternative formats like CBOR, and provide practical advice on using tools and libraries designed for secure JSON signing. The discussion also touches upon the nuances of JWS and JWT, suggesting simpler approaches for enhanced security.