Draft: draft-ietf-jsonpath-base

Commentary: See also . Fixes 
 I have read the latest draft of section 5.2 " Attacks on Security Mechanisms that Employ JSONPath " and I 'm having trouble figuring out what it 's saying and what would be useful for implementors . On consideration , I think the following is true . If the JSON text to which you 're applying a JSONpath follows the rules of I - JSON [ RFC7493 ] the results should be deterministic and repeatable for the same  text from one JSONpath implementation to another . On the other hand , if you have JSON with dupe object keys , or 300 - digit numbers , or broken UTF16 surrogates , you really have no expectation of deterministic behavior . I think ( do others agree ? ) that given I - JSON , conforming JSONpath implementations should be deterministic ? Anyhow , I 'd replace section 5.2 with text saying something like " If your security mechanism includes the use of JSONpath implementations , you should be aware that results will be nondeterministic and interoperation can fail if a JSON text you are processing includes constructs that are deprecated but allowed by [ RFC8259 ] . Deterministic behavior can be expected for any  text conformant with [ RFC7493 ] . 
 Note that in , I did n't adopt the language above to describe certain constructs as " deprecated but allowed " by RFC 8259 since that RFC does not use the term deprecation . Please feel free to object to this in the PR . 
 It 's been previously mentioned in the issues , but the draft should say something about the danger of attack from a query that triggers overflow in a recursive step . The JSONPath recursion operator , given how it 's implemented in many implementations , is vulnerable to attack , in situations where a JSONPath expression is provided as a parameter . It 's pretty obvious that some , perhaps even most , implementations would not be able to pass Google fuzzer , were that a scenario . Note that enterprises take the risk of vulnerability through recursion very seriously . In my opinion , some limits on recursion levels ought to be specified . 
 Interesting . Would n't such a stack overflow attack be bounded by the  document ? I guess where an attacker can provide both the  document and the JSONPath , there is an opportunity for stack overflow . But there is a more general resource exhaustion attack if attackers are allowed to provide arbitrarily large  documents . I agree that JSONPath implementations may wish to defend themselves by imposing recusion limits , memory limits , etc . , but I 'm not sure I 'd want to go as far as requiring specific limits in the spec . 
 I believe so , but as you also mention , the attacker could supply both . Or supply a document that exploits a JSONPath with a recursive operator . Of course , a hostile document raises more issues than for just JSONPath . Pull parsers also may exhibit recursion , Microsoft guards against that by limiting .Net JSON parser depth by default to 64 . My own view is that in today 's world , anything that suggests recursion should be flagged . 
 Ok , and based on the advice in on DOS attacks , I 'll put together a PR to flag up the risk of a DOS attack due to recursion and see how that goes down .
Paragraph (version A):
Where JSONPath is used as a part of a security mechanism, attackers
can attempt to evoke unexpected behavior, or take advantage of
differences in behavior between JSONPath implementations.
Paragraph (version B):
Where JSONPath is used as a part of a security mechanism, attackers
can attempt to provoke unexpected or unpredictable behavior, or take
advantage of differences in behavior between JSONPath
implementations.
Paragraph (version B):
Unexpected or unpredictable behaviour can arise from an argument with
certain constructs described as unpredictable by RFC8259.
Predictable behavior can be expected, except in relation to the
ordering of objects, for any argument conforming with RFC7493.