new requirement - do not follow redirects by default for requests made by server-side components

[elarlang]

I think we don't have addressed the problem, if server-side client makes request to external party and the external party redirects the request to "malicious URL".

Related requirement:

14.6.1 Verify that the web or application server is configured with an allowlist of resources or systems to which the server can send requests or load data or files from.

My proposal is to have requirement with the idea: server-side components that making requests must not follow redirects till is not intended for that use-case.

[tghosth]

So I think 14.6.1 is more general and may not be logically aware of whether to follow redirects or not.

I think maybe we we want to work on the other requirement for SSRF:

#	Description	L1	L2	L3	CWE
5.2.6	[MODIFIED] Verify that the application protects against Server-side Request Forgery (SSRF) attacks, by validating untrusted data against an allowlist of protocols, domains, paths and ports and sanitizing potentially dangerous characters before using the data to call another service.	✓	✓	✓	918

I would suggest a modification:

"Verify that the application protects against Server-side Request Forgery (SSRF) attacks, by validating untrusted data against an allowlist of protocols, domains, paths and ports and sanitizing potentially dangerous characters before using the data to call another service. The application should also be configured to not follow redirects when calling the other service unless this is specifically intended functionality."

[elarlang]

Although the note is valid here, requirement 5.2.6 is addressing user-input driven request forgery in the application but "do not follow redirects" is wider than user-input controlled calls.

Also, the defense against "do not follow redirect" is about configuration or defensive coding, but not input validation or sanitization. It is not a V5 topic.

[tghosth]

Verify that where the application back-end makes calls to external URLs, it is configured to not follow redirects unless this is specifically intended functionality. This is relevant for any external URL and is not limited to a situation where the URL has been provided by an untrusted user.

This is the proposed wording, to be added to 14.6

Alternative option to edit existing 14.6.1:

[MODIFIED, MOVED FROM 12.6.1] Verify that the web or application server is configured with an allowlist of resources or systems to which the server can send requests or load data or files from, and that it is configured to not follow redirects unless this is specifically intended functionality.

[jmanico]

I think @elarlang is spot on here. An allow list is validation, but if one of the items on your allow list redirects, that's only a problem if your server-side HTTP "fetch" class takes redirects, and to avoid this is about configuring something - and not validation.

So perhaps split the allow-list from the redirect? Especially when it comes to coding these are solved at different layers.

[elarlang]

Thinking more about it, I think we should go with a separate requirement and probably the best option is to use section "V10.4 Defensive Coding" for that as proposed by Josh during discussion.

14.6.1 can be done in some waf, proxy, os, application or whatever level, but the "no not follow redirects" is the question of the library that makes the request - those are different enough to test and to implement - so let's keep them separately.

[tghosth]

Verify that where the application back-end makes calls to external URLs, it is configured to not follow redirects unless this is specifically intended functionality. This is relevant for any external URL and is not limited to a situation where the URL has been provided by an untrusted user.

So @elarlang, you are proposing this wording and to add on to 10.4?

[elarlang]

Yes, although I'm not sure we need this explanation part. But if someone thinks that it is good then it can stay like it is.

[jmanico]

I suggest we drop the explanation and stick with: Verify that where the application back-end makes calls to external URLs, it is configured to not follow redirects unless it is intended functionality.