Discussion: V14.4.2 - move or change - serving content as attachment

[elarlang]

V14.4.2 Verify that all API responses contain Content-Disposition: attachment; filename="api.json" (or other appropriate filename for the content type).

As it is API specific, move this requirement to V13.2

(goal ASVS v4.1)

[jmanico]

Agreed ; good call.

…

-- Jim Manico @manicode

On Feb 22, 2020, at 10:54 PM, Elar Lang ***@***.***> wrote:  V14.4.2 Verify that all API responses contain Content-Disposition: attachment; filename="api.json" (or other appropriate filename for the content type). As it is API specific, move this requirement to V13.2 (goal V4.1) — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[tghosth]

Marking for 4.1

[jmanico]

We're ready for a PR on this @elarlang

[elarlang]

With current wording it makes sense to move it, but maybe we should review and generalize the wording instead.

I don't know how to wordsmith it - idea is, if some content/file is not meant to be displayed and executed in browser as part of used application functionality, it must be served as attachment. Also related to requirement:

V12.5.2 Verify that direct requests to uploaded files will never be executed as HTML/JavaScript content.

Far away from requirement proposal, open for discussion.

[jmanico]

My instinct says something closer to:

V12.5.2 Verify that uploaded files cannot execute active web content such as HTML/JavaScript content.

Maybe? Bah this is tough.

[Bankde]

I agree it looks more fit to 13.2 than 14.4

@elarlang There are some similarities to V12.5.2 but I think they are different.
V12.5.2 => Prevent browser to interpret file as Javascript/HTML (prevent XSS, etc.)
V14.4.2 => Prevent browser to download file as malicious file name; e.g. download user.json into user.bat. (prevent social engineering).
The file could include any script but is safe in its content-type/context and could be malicious in different context when browsers choose incorrect interpretation.

However, I'm more concerned about the reason of this requirement.
I don't think I have seen this recommendation (adding content-disposition header into every API responses) apart from RFD mitigation, and I don't think I have seen top webs following this practice either?

Are there other reasons I'm missing or threats that this requirement mitigate?
If it's solely for RFD, and not a common recommendation/practice, I think L1, L2 sounds too stressed.

[elarlang]

If you force browser to send content as attachment on direct access, then the content-type can be text/html and it will be not executed in browser. From that perspective 14.4.2 and 12.5.2 serve the same goal as well.

[Bankde]

Note: This is the earliest commit I have found: https://github.com/OWASP/ASVS/blame/45a586e09711d1c2585a572f1839cb72b7950b4d/4.0/en/0x22-V14-Config.md#L78
It's an improvement and defense in depth so I think it's more fit to L3 than L1, L2?

For RFD solution (quite off-topic)

I prefer this straightforward solution: https://hackerone.com/reports/39658

"fix the issue with content being returned for extensions that aren't supported"

because application shouldn't serve the resource/content/extension that does not exist.

[Bankde]

@elarlang
I think the idea is like this
V12.5.2: You may upload any file. When you access it, it should be accessed as a download-content, not an active web HTML or javascript.
V14.4.2: We know that those APIs return json but what if there is a mistake to cause our users to download the file and the name is also controllable by attacker (.bat)? We should set Content-Disposition name so even if our users download them, the file name are safe (.json) and won't execute in their PC.

Solution to both issue is adding "Content-Disposition header" but the perspectives are different. I personally don't think we should merge them.

[elarlang]

RFD part is covered with #726 and from that perspective current 14.4.2 is duplicate for 12.3.4>12.5.3

I was more focused on this mime type part from your linked commit and there is some common area with 12.5.2.

[elarlang]

Othen I watch this serving as attachment as 2nd layer of defence, when API serves JSON content with text/html content-type (and with current wording for the 14.4.2 it was pointing clearly only for API).

Anyway, with current issue - I think I (or we) need to analyze it a bit more and make it clear, why exactly this requirement exists.

[jmanico]

Per #1004 we are going to delete 14.2.2 there is no need for this requirement in modern browsers anymore.

[jmanico]

14.4.2 deleted

[elarlang]

Is there any requirement to say, that "API responses must not be accessible directly" and/or response from API can not be with Content-Type: text/html? Previously 14.4.2 covered that situation, now it's not covered.

[jmanico]

Per @elarlang this is not fully addressed yet. Can you all please take a look at #1009 for us, please?