5.3.6 enhancement

[jmanico]

Suggest clarifying:

5.3.6	[MODIFIED] Verify that the application protects against JSON injection attacks. (C4)	✓	✓	✓	75

with

5.3.6	[MODIFIED] Verify that the application protects against JSON injection attacks by sanitizing JSON before JSON parsing. (C4)	✓	✓	✓	75

[elarlang]

If it moves to sanitize, then it must move to another category (5.2) as well

[elarlang]

Also, we have opened one separate issue for JSON topic, maybe we should get a bit wider overview there in place: https://github.com/OWASP/ASVS/issues/1538

[tghosth]

I have merged the comments into #1538 where this issue will be handled more widely and will close this issue for now.

[tghosth]

I don't feel this requirement got fully handled in #1538 so I am reopening this.

It feels to me like encoding is a better option than "sanitizing".

5.3.6	[MODIFIED] Verify that the application protects against JSON injection attacks by encoding untrusted input before including it in a JSON object.	✓	✓	✓	75

What do you think @jmanico?

[ryarmst]

Considering the existence of other data interchange formats, would it make sense to instead have a general requirement for protecting against data interchange format injection attacks? Or, are JSON and XML (as in 5.3.10) simply prevalent enough to warrant their own specific requirements?

[jmanico]

I like Elar's idea of a more general requirement that handles JSON, XML, YAML and any other data format. They all need to be well formed according to the specs to avoid data interchange format injection attacks and parser attacks.

[tghosth]

So this requirement is less about processing a whole JSON or XML object and more about taking some input and using it to build a JSON object ourselves. 5.3.10 is similar although I would argue that there are two injection scenarios there.

We have separate requirements for JSON schema validation 13.2.2 and XML schema validation 13.3.1.

[ryarmst]

Exactly, I understand this not as a parsing or interoperability issue, but injection into an object we build with untrusted data. Schema validation may not necessarily solve the issue as an injection could produce an object that passes validation that nevertheless includes manipulations of data not intended to be modified.

Ignoring XPath for the moment (which could be considered categorically distinct), is there a reason for this type of injection to consider JSON, XML, and other formats separately with respect to requirements?

[tghosth]

So this is a key question for chapter V5.

I guess this all fits under the category of some form injection where data is incorporated in a way that it controls structure or semantic meaning or something else.

At this point, we cover many different examples of this with different requirements for each, see section 5.3.

The primary arguments for this would probably be that:

1. The encoding required in each case would be very different.
2. Having a single catch all requirement for lots of different injection scenarios would be very hard to both implement and verify.

So based on that argument, we would consider the injection scenarios in separate requirements.

Curious to hear what you think though.

[tghosth]

Any thoughts on this @ryarmst ?

[elarlang]

I tried to understand what the issue was about, but I did not...