Show HN: JSON-Threat-Protection Rust High-Performance Crate
1–10 of 20 posts
Re: Show HN: JSON-Threat-Protection Rust High-Performance Crate
#2"Whether to allow duplicate object entry names." This is interesting. I just did a test and it look like `jq` evaluates `{ "a": 1, "a": 2 }` to just `{ "a": 2 }`. I have always thought that this was invalid JSON. This mean that the order of keys in JSON do have some semantic meaning.
Re: Show HN: JSON-Threat-Protection Rust High-Performance Crate
#3"Whether to allow duplicate object entry names." This is interesting. I just did a test and it look like `jq` evaluates `{ "a": 1, "a": 2 }` to just `{ "a": 2 }`. I have always thought that this was invalid JSON. This mean that the order of keys in JSON do have some semantic meaning.
Interestingly, ECMA-404 says the following:
> The goal of this specification is only to define the syntax of valid JSON texts. Its intent is not to provide any semantics or interpretation of text conforming to that syntax.
So it is legal JSON although not useful with a lot of concrete implementations. Maybe a way to find an exciting security vulnerability involving two parsers differing in their interpretation...
Re: Show HN: JSON-Threat-Protection Rust High-Performance Crate
#4"Whether to allow duplicate object entry names." This is interesting. I just did a test and it look like `jq` evaluates `{ "a": 1, "a": 2 }` to just `{ "a": 2 }`. I have always thought that this was invalid JSON. This mean that the order of keys in JSON do have some semantic meaning.
The JSON RFC (https://datatracker.ietf.org/doc/html/rfc8259#page-6) doesn't require the unique entry name, and also the fact is that many parser uses the last-win strategy like serde_json.
For human, this is invalid, but many web services accepts this kind of JSON consciously or unconsciously.
I'm guessing this may have become a feature of some services and it's hard for maintainers to break this behavior. ᵕ︵ᵕ
Re: Show HN: JSON-Threat-Protection Rust High-Performance Crate
#5"Whether to allow duplicate object entry names." This is interesting. I just did a test and it look like `jq` evaluates `{ "a": 1, "a": 2 }` to just `{ "a": 2 }`. I have always thought that this was invalid JSON. This mean that the order of keys in JSON do have some semantic meaning.
Interestingly, ECMA-404 says the following: > The goal of this specification is only to define the syntax of valid JSON texts. Its intent is not to provide any semantics or interpretation of text conforming to that syntax. So it is legal JSON although not useful with a lot of concrete implementations. Maybe a way to find an exciting security vulnerability involving two parsers differing in their interpretation...
Perhaps checking a service's behavior in response to such JSON is high on the security researcher's list of things to do that are high priority and simple.
"( – ⌓ – )
Re: Show HN: JSON-Threat-Protection Rust High-Performance Crate
#6Re: Show HN: JSON-Threat-Protection Rust High-Performance Crate
#7For things that are claimed to be high-performance, it would be helpful to see some numbers without running it locally on our own json files.
Re: Show HN: JSON-Threat-Protection Rust High-Performance Crate
#8https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-va...
Great to see this article, I totally agreed with the view that rejecting any invalid case by designing the right data structure.
Unfortunately, it is hard to achieve it in practice and people even don't realize this, JSON Object is a good example, Human are incline expecting the duplicated key is not allowed in JSON, but it happens.
For this goal, I think the Protobuf is good way to eliminate the possible invalid data for data transportation.
Re: Show HN: JSON-Threat-Protection Rust High-Performance Crate
#9https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-va...
I think you may have misunderstood the article.
The point of the article is to parse AND validate input AT THE BOUNDARY between the outside world and your program, rather than a bunch of ad-hoc validations at various points after the suspect data has entered the castle walls and has already been (at least partially) processed (thus making the program state harder to reason about). By enforcing your invariants at the border, you ensure that all data entering your system always conforms to your expectations, just like a strong type system ensures that invalid states are not representable. A schema is basically a type system for your raw data.
This concept is also a major element of Domain Driven Design https://en.wikipedia.org/wiki/Domain-driven_design
Re: Show HN: JSON-Threat-Protection Rust High-Performance Crate
#10"Whether to allow duplicate object entry names." This is interesting. I just did a test and it look like `jq` evaluates `{ "a": 1, "a": 2 }` to just `{ "a": 2 }`. I have always thought that this was invalid JSON. This mean that the order of keys in JSON do have some semantic meaning.
The JSON RFC ( https://datatracker.ietf.org/doc/html/rfc8259#page-6 ) doesn't require the unique entry name, and also the fact is that many parser uses the last-win strategy like serde_json. For human, this is invalid, but many web services accepts this kind of JSON consciously or unconsciously. I'm guessing this may have become a feature of some services and it's hard for maintainers to break this behavior. ᵕ︵ᵕ
For security researchers it’s also interesting which implementations parse with first-win strategy and which allow comments (I think Ruby does this).