Security items

[glyn]

Let's use this issue to capture possible items for the Security Considerations section of the spec.

As discussed in #14, CPU exploits are possible using selectors such as:

$[?($)][?($)][?($)][?($)]...
$[?(@==$[?(@==$[?(@==$[?(@==$[?(@==$[?(@==$[?(@==$[?(@==$[?(@==$[?(@=="b")])])])])])])])])])]
$[?(@.a || @.b || @.c ...)]

One mitigation would be to run the implementation in an environment, such as a Linux cgroup, which can restrict the CPU consumed.

[glyn]

@jchesterpivotal provided the following:

Regular Expression Denial of Service Attacks (ReDOS)

A malicious user can submit a JSON object intended to cause explosive backtracking by a JSONPath implementation performing regular expression matching. This is known as a ReDOS [REDOS] attack.

To defend against this attack, regular expressions in JSONPath filters SHOULD conform to RE2 syntax [RE2SYNTAX], which does not support backtracking. (but MAY not support "\C" - move this to the filter section). Additionally, implementations SHOULD guarantee linear run time for regular expression matching, such as provided by the original RE2 library implementation [RE2IMPL] and Go's "regexp" library [GOREG].

Informative References

[GOREG] The Go Authors, "Package regexp", January 2007,
https://golang.org/pkg/regexp/.

[RE2IMPL] The RE2 Authors, "RE2", March 2010,
https://github.com/google/re2.

[RE2SYNTAX]
The RE2 Authors, "Syntax", November 2014,
https://github.com/google/re2/wiki/Syntax.

[REDOS] Crosby, SA. and DS. Wallach, "Denial of Service via
Algorithmic Complexity Attacks (In "Proceedings of the
12th USENIX Security Symposium")", August 2003.

[glyn]

@jchesterpivotal suggested adding the following to the Security Considerations section:

Out of scope attacks

Eavesdropping, replay, message insertion, deletion, modification and man-in-the-middle attacks are considered out of scope for JSONPath. These attacks are relevant to a network protocol, but not to a query language.

[jchesterpivotal]

One mitigation would be to run the implementation in an environment, such as a Linux cgroup, which can restrict the CPU consumed.

Granted, but I'm not sure this would be in-scope for the RFC.

[gregsdennis]

Agreed about specific solutions not being in scope for the RFC. At most, I think we can identify several potential risks, but:

1. It should be stated that such a list of risks cannot be comprehensive.
2. Solutions will be specific and relevant according to the implementation, and so should not be included.

As an exaample of point 2, an implementation that is designed for applications that run on Windows obviously cannot run in Linux.

[ucarion]

Would it be worth giving special consideration to concerns for JavaScript in the security considerations? RFC 8259 does this, and there are similar concerns for this document too.

For instance, some naïve implementations of JSONPath in JavaScript could run into trouble with paths that refer to things like __proto__ or that try to invoke special functions like toString (which you can trigger by concatenating any non-string value with a string).

JavaScript is special here in that it's very popular and there is a very strong conventional representation for JSON data -- whatever JSON.parse returns -- and that representation can, if you naïvely fetch its attributes, start returning things that the programmer might not expect to be manipulating.

It may be worth talking to seasoned JavaScript security practitioners if we want to make any comment on the perils of walking arbitrary properties of Object. I am not such a person.

[danielaparker]

It may be worth mentioning that the recursive descent operator is a possible security issue. Naïve implementations that simply recurse down the stack may be vulnerable to attack, and would likely fail suitably designed fuzzer tests. At the least, the specification should require a limit to the depth of recursion.

[gregsdennis]

How big of JSON objects are we talking about here? It's not like GraphQL where you can actually have requests for circular data. JSON is most definitely finite, and surely other mechanisms, such as limits on request size (an application concern), would capture JSON objects large enough to cause recursion issues.

Unless your available call stack is really small, I suppose. But environmental awareness seems like a concern of either the app or the implementation, not this spec.

[danielaparker]

How big of JSON objects are we talking about here? It's not like GraphQL where you can actually have requests for circular data. JSON is most definitely finite, and surely other mechanisms, such as limits on request size (an application concern), would capture JSON objects large enough to cause recursion issues.

Unless your available call stack is really small, I suppose. But environmental awareness seems like a concern of either the app or the implementation, not this spec.

We're talking about attack files that are specifically generated to exploit vulnerabilities. That's what fuzz testing is about, bombarding your function calls with simulated attack files on a continuous basis, to detect whether your API is vulnerable to malicious attackers. Recursive algorithms are a big source of security vulnerabilities.

Daniel

[cabo]

We still have to write the Security Considerations section.
(Some of this also goes into #70.)