Closed timbray closed 1 year ago
If this PR isn't intended for merging, should we concert it to a draft PR so it can't be merged?
If this PR isn't intended for merging, should we concert it to a draft PR so it can't be merged?
Done.
@timbray Before we close this PR, you wanted to include a caution to developers about using naive code to build paths using dot notation. @cabo pointed out that (I would argue somewhat less) caution is also needed when building paths using bracket notation. Are you still keen to see this kind of cautionary material in the spec? If so, which section would best contain it? The most natural could be the Security Considerations section, but we don't yet cover naive programming slips there, so those cautions would look out of place.
My feeling is that developers who are sufficiently incompetent to mess up in this way are (a) very unlikely to read the spec and (b) likely to screw up in some other ways that we can't anticipate. So I'd prefer not to add these cautions.
We could add a short third subsection on security considerations from building JSONPath queries out of potentially attacker-controlled variables, mostly pointing out that similar considerations exist as for SQL injections. I'd do this as a separate PR.
At this point, I'll defer to your editorial judgment. If I were writing this I'd find a way to work the example in, but it's really not essential.
A potential PR is in https://github.com/ietf-wg-jsonpath/draft-ietf-jsonpath-base/pull/307
Signed-off-by: Tim Bray tbray@textuality.com
Obviously, this PR is designed for cherry-picking rather than merging.