clarification needed for 12.4.1

[elarlang]

Current V12.4.1:

Verify that files obtained from untrusted sources are stored outside the web root, with limited permissions.

"spin-off" issue from #1065 (comment)

I'm not too happy with this requirement. It feels a bit from old-style PHP crappy architecture, where file in public folder leads to RCE.

The main question is, should we just blindly disallow to store files in public folder in general, or make it a bit more flexible.

• sometimes files are expected to stay in public folder, like "public" images (or we ask them to serve from another domain? is it reasonable?)
• even if .php file is stored in public folder for "PHP application", it's important to avoid to execute it as PHP program code (by web-server configuration for example)

[jmanico]

I agree this needs work. Again, I like to delete confusing requirements. We do not need to be a complete standard, we need to be a clear one, is my opinion.

[cmlh]

We do not need to be a complete standard, we need to be a clear one, is my opinion.

Perhaps inserting an explanatory note would resolve the confusion @jmanico or something like the format below:

1. Boardline Requirement 1
   1a. Conflicting Requirement 1a
   1b. Conflicting Requirement 1b
   1c. ...

[jmanico]

This is really old-school thinking. The situation is way more complex, I again suggest we just delete this requirement and move on.

[elarlang]

Take it as a placeholder, I'll come back to this one when looking entire V12.*

[jmanico]

I'd still like to delete it.

[elarlang]

proposal, delete as duplicate of 4.1.3:
V4.1.3 Verify that the principle of least privilege exists - users should only be able to access functions, data files, URLs, controllers, services, and other resources, for which they possess specific authorization. This implies protection against spoofing and elevation of privilege.

[jmanico]

I agree with your proposal.

[elarlang]

12.4.1 is removed as duplicate of 4.1.3 (just one special case of authorization problems)

For fixing "decision time situation":

#	Description	L1	L2	L3	CWE
4.1.3	Verify that the principle of least privilege exists - users should only be able to access functions, data files, URLs, controllers, services, and other resources, for which they possess specific authorization. This implies protection against spoofing and elevation of privilege. (C7)	✓	✓	✓	285
12.4.1	Verify that files obtained from untrusted sources are stored outside the web root, with limited permissions.	✓	✓	✓	552

• CWE-285: Improper Authorization
• CWE-552: Files or Directories Accessible to External Parties

[tghosth]

[tghosth]

Sorry, @elarlang / @jmanico,

I am reopening this as I really don't agree that it is a duplicate of 4.1.3 and I don't think it should have been deleted.

This is the history of the requirement:

#	Description	L1	L2	L3
12.4.1	Verify that files obtained from untrusted sources are stored outside the web root, with limited permissions.	✓	✓	✓	552
12.4.1	[MODIFIED] Verify that files obtained from untrusted sources are stored outside the web root, with limited permissions.	✓	✓	✓	552
12.4.1	Verify that files obtained from untrusted sources are stored outside the web root, with limited permissions, preferably with strong validation.	✓	✓	✓	922
16.4.1	Verify that files obtained from untrusted sources are stored outside the web root, with limited permissions, preferably with strong validation.	✓	✓	✓	922
16.6	Verify that files obtained from untrusted sources are stored outside the web root, with limited permissions, preferably with strong validation.		✓	✓	3.0

Basically it comes from a 3.0 requirement and I agree that the permissions/validation part is weird and that the webroot part is a little 90s but I still think the "web root" part is important and I don't want it to get lost.

I would propose the following, (note the updated CWE):

#	Description	L1	L2	L3	CWE
12.4.1	[MODIFIED] Verify that files obtained from untrusted sources are stored outside the web root so that there is no risk of accidental execution.	✓	✓	✓	553

@elarlang @jmanico what do you think?

[elarlang]

Well, not that easy.

[MODIFIED] Verify that files obtained from untrusted sources are stored outside the web root so that there is no risk of accidental execution.

Authorization

12.4 is file storage category and was removed from that perspective.

From file execution perspective, it should be 12.3 requirement.

Client-Side execution

What about public content - like images, profile pictures, logos, some pdf files etc?

We have it kind of covered with othe requirement.

#	Description	L1	L2	L3	CWE
1.12.2	[MODIFIED] Verify that user-uploaded files - if required to be displayed or downloaded from the application - are served by either octet stream downloads, or from an unrelated domain, such as a cloud file storage bucket.		✓	✓	646
12.5.2	Verify that direct requests to uploaded files will never be executed as HTML/JavaScript content.	✓	✓	✓	434

I have made proposal to merge them: #1406

It would be wasting resources to serve static images via program code and may actually cause good DoS vectors.

But those are more client-side oriented.

Server-Side execution

Now the question to solve is - why it may happen, that users can upload as "public content" something, which is executed on the server side via HTTP request as program code.

I would call it business logic problem.

#	Description	L1	L2	L3	CWE
12.2.1	Verify that files obtained from untrusted sources are validated to be of expected type based on the file's content.		✓	✓	434

See also opened related issues: #1604

We also have another requirement to play with.

#	Description	L1	L2	L3	CWE
14.3.6	[GRAMMAR, MOVED FROM 12.5.1] Verify that the web tier is configured to serve only files with specific file extensions to prevent unintentional information and source code leakage. For example, backup files (e.g. .bak), temporary working files (e.g. .swp), compressed files (.zip, .tar.gz, etc.) and other extensions commonly used by editors should be blocked unless required.	✓	✓	✓	552

What we clearly don't have is (in whatever wording): Verify that files obtained from untrusted sources are not executed as program code when directly accessed with HTTP request.

[tghosth]

Ok, I am going to chalk this up for the rework of 12

[jmanico]

• I like the merge proposal at proposal: 1.12.2 (50.5.2) move/merge to 12.5.2 (50.5.1) #1406 and this is well under way
• Also see that 12.4.1 is removed

12.4.1	[DELETED, DUPLICATE OF 4.1.3]

Can we close this out for now and move these issues to a new issue if needed?

[jmanico]

The problem with the image library (which has dozens of historical examples) should be handled in requirement to keep components updated.

image itself is being executed as program code, e. g. so called polyglots (we have requirement 14.3.6 to limit the file extensions being allowed)

The whole point of file permission limitations is that this class of attack allowed even files with .gif extensions (or in the distant past wmf files and other file types), and with magic bytes claiming to be gif to still be executable ik certain cases. This is why you want to set the file permissions of uploaded files that you publically deploy to be read only. It’s a very basic and easy to implement control that fully shuts this category of attacks down. Gifs, ICO, SVG and others have had this problem. Or let me ask another question. Would you want an uploaded file of any type that you stage up in a public directory to be permissioned as executable? This seems like a very bad idea to me.

[elarlang]

What and why is going to execute it?

[jmanico]

Why? Why do attackers attack? I don’t understand the question. There is a *lot* of research on uploaded images being executable historically. For a wide variety of reasons depending on the web server type, the app server type, and the image type. So are you suggesting that staging up uploaded files in a public directory with file permissions being set to executable to be an acceptable practice? Really?

[elarlang]

Kind of "here we go again" with demagogy.

If you allow user to upload (edit: a php) file to public folder that is executed when directly accessed with an HTTP request, it does not require to have "executable" permissions. Read-only is enough.

And if it comes to "executable", then something - some process must execute it. This was my question, what process and why it can execute the file?

[jmanico]

> Kind of "here we go again" with demagogy.

This is very insulting when I am in good faith trying for to help. Please stick to the technical conversation. Personal attacks help no one.

And if it comes to "executable", then something - some process must execute it. This was my question, what process and why it can execute the file?

Since its in a public directly any user can navigate to that file. JS files can impact node servers. Gif-Jar’s impact Java servers. There are numberous situations again depending on the server type. Setting piblically available uploaded files to be read only (depending on the server and other factors) shuts down: - Remote Code Execution (RCE) - Web shell attacks - File inclusion vulnerabilities (LFI/RFI) - Privilege escalation - Denial of Service (DoS) through malicious scripts - Soe forms of Cross-site scripting (XSS) and other injection-based attacks And even if other ASVS items (like file validation) address these issues, setting uploaded publically staged files to read only - is a fairly standard secure coding practice.

[elarlang]

For the mirror.

So are you suggesting that staging up uploaded files in a public directory with file permissions being set to executable to be an acceptable practice? Really?

Setting piblically available uploaded files to be read only (depending on the server and other factors) shuts down:

Sorry, but I would say that you don't know what you are talking about. For example, LFI only requires reading permission.

[jmanico]

Sorry, but I would say that you don't know what you are talking about. For example, LFI only requires reading permission.

Again with the personal attacks…. I undetand LFI Elar. But read only permissions reduces the overall likelihood of file upload problems in this category. As mentioned above, this is not just about LFI.

[elarlang]

Let's come back to this one.

So are you suggesting that staging up uploaded files in a public directory with file permissions being set to executable to be an acceptable practice? Really?

Did I say anything towards that? No. It is your attempt to "assign" this to me, and then saying I'm attacking you :)

There is no reason to add executable permissions to uploaded files, but only removing executable permissions from files that are stored in public folders, but otherwise being directly handled by the web server (classical php solution), do not solve ANY of your listed problems. So, your proposed solution does not solve the problem (avoid file getting executed) and I think my conclusion out of that is aligned.

[jmanico]

There is no reason to add executable permissions to uploaded files, but only removing executable permissions from files that are stored in public folders, but otherwise being directly handled by the web server (classical php solution), do not solve ANY of your listed problems. So, your proposed solution does not solve the problem (avoid file getting executed) and I think my conclusion out of that is aligned.

So can you think of any situation where read only vs executable for public uploaded files helps reduce the risk of any web based attack or do you think this is just an unreasonable defense to suggest? I’m not trying to lead you on, I am genuinely asking. This is a control I’ve been asked by security engineers to implement for 20+ years. I wonder if all this time it was not necessary.

[elarlang]

I think the answer was already in quoted text:

There is no reason to add executable permissions to uploaded files, but only removing executable permissions from files that are stored in public folders, /.../, do not solve ANY of your listed problems.

[tghosth]

So I feel like this thread got a bit confused.

@elarlang suggested above the following requirement (I made a minor wording change):

Verify that files uploaded or generated by untrusted input which are stored in a public folder are not executable as program code when accessed directly by an end user.

@jmanico is there anything missing from that from your perspective?

[jmanico]

This works for me.

[elarlang]

One may argue that it disallows executing client-side javascript, so maybe we limit it to the server-side program code?

Verify that files uploaded or generated by untrusted input which are stored in a public folder are not executable as server-side program code when accessed directly by an end user.

[jmanico]

I like your suggestion even better, @elarlang - nice ending to this. Thank you.

[tghosth]

One may argue that it disallows executing client-side javascript, so maybe we limit it to the server-side program code?

Verify that files uploaded or generated by untrusted input which are stored in a public folder are not executable as server-side program code when accessed directly by an end user.

Great, let's get this PRed in :) @elarlang

[randomstuff]

Verify that files uploaded or generated by untrusted input which are stored in a public folder are not executable as server-side program code when accessed directly by an end user.

One may argue that it disallows executing client-side javascript, so maybe we limit it to the server-side program code?

Actually I understood it mainly the other way :) i.e. if the user uploads an HML or SVG file, you want to make sure that this application won't get executed on the client-side (browser).

This is a typical vector for client-side JS injection for example when you let users upload images:

1. malicious user uploads SVG file containing malicious JavaScript code;
2. the malicious SVG is exposed/available in the application origin;
3. malicious user redirects you to this SVG file;
4. SVG file is executed in your browser (including JavaScript !) and an use your session.

[elarlang]

For this scenario we have those:

V50.5 Unintended Content Interpretation

#	Description	L1	L2	L3	CWE
50.5.1	[GRAMMAR, MOVED FROM 12.5.2] Verify that direct requests to uploaded files will never be executed as HTML and JavaScript content.	✓	✓	✓	434
50.5.2	[MODIFIED, MOVED FROM 1.12.2] Verify that user-uploaded files - if required to be displayed or downloaded from the application - are served by either octet stream downloads, or from an unrelated domain, such as a cloud file storage bucket.		✓	✓	646
50.5.3	[ADDED, DEPRECATES 14.4.2] Verify that security controls are in place to prevent browsers from rendering content or functionality in HTTP responses in an incorrect context (e.g., when an API or other resource is loaded directly). Possible controls could include: not serving the content unless headers indicate it is the correct context, Content-Security-Policy: sandbox, Content-Disposition: attachment, etc.	✓	✓	✓

Related issue to merge 50.5.1 and 50.5.2: #1406