clarification: application need to behave the situation when some resource is not available (current 12.7.1)

[elarlang]

spinf-off from #1620 (comment)

Somthing to discuss and maybe cover as requirement.

For every resource or external connection, there must be analyzed and documented expected behaviour - how application need to behave if some resource (e.g. some external API) is not available.

It is related with #1620 as if resource is not available, there is possibility that all connection start waiting some timeout, which can be too long (example 30sec or 5min) and it gives quite easy vector for denial of service.

So additionally, documentation must contain - what is the timeout for each service (default timeout) or request (if some requires extra solution) and an application should monitor "slow responses" (which also requires definition, what is "slow").

[Sjord]

That is indeed an interesting situation, where one service being unavailable brings down the whole application. It would make the application fragile, but I am not sure it would be a security issue. If an attacker cannot bring the service down on purpose, then there does not seem to be an attack vector.

[elarlang]

If an attacker cannot bring the service down on purpose, then there does not seem to be an attack vector.

Attack vector is just one way. Every application need to provide also availability and if it crashes because some external connection is not available, there is no availability - was it taken down by external attacker or by internal code/configuration issue or by external service problem, does not matter anymore.

The goal should be to provide information about the situation and maybe some extra temporary workaround - like data which you need to send to external API you can temporarily save on the application side (yes, not always possible but just an example).

[tghosth]

So this is a concept that already exists in the SRE world: https://microservices.io/patterns/reliability/circuit-breaker.html

Do you think still think we should still be referencing it?

[csfreak92]

@elarlang, would this topic also cover the problem of let's say an application depending on an API, but if that API is down then it hangs, brings down the application or even causes it to have unintended behavior such as crashes? If it is, then it is indeed an interesting case of denial of service and I believe it is worth noting to add. I've only seen this behavior twice on an application pentest. Maybe it is more common than I know of. Anyone who can attest more to it?

Just throwing out more scenarios to paint this issue well.

[elarlang]

So this is a concept that already exists in the SRE world: https://microservices.io/patterns/reliability/circuit-breaker.html

Do you think still think we should still be referencing it?

I don't get it - how covering it in the SRE covers it in/for the ASVS?

@csfreak92 - I feel I have answered to those questions here: #1748 (comment) . So, yes, it should cover the case when some API is down, but not limited to it.

[tghosth]

@elarlang I mean that whilst technically it is a security issue but it is something that is more suited to the SRE function to address and therefore do we specifically want a separate requirement for it?

[elarlang]

It's up to discussion. I have seen it as a problem during pen-tests and that is the reason to rise it here.

I can see this one more important as requirement compared to "just close everything nicely when everything works anyway" (#1620) but I can see those can be combined.

[tghosth]

So you are thinking of a requirement along the lines of:

Verify that the application is designed in a way that a failure to access external resources does not result in the entire application failing, for example using the circuit breaker pattern.

[elarlang]

I think we can finetune some words here, but the direction is really good one

[tghosth]

Ok, please can you suggest category, CWE (if possible) and level :)

[elarlang]

Category / section - not easy task.

By just section title it fits to "V1.9 Communications Architecture". In reality V1.9 probably will be cleaned up via #1443 and section name is out of sync from V9 Communication Encryption.

By just section title it fits to "V9.2 General Service to Service Communication Security". In reality V9 is limited to encryption related requirements.

By category title it fits to "V12 Files and Resources". In reality V12 do not contain this kind of resource handling requirements.

By category name it may fit to "V13 API and Web Service", but the category is more providing the service, not using the service.

By idea it also fits to V7.4 Error handling - that application should not die completely when communication with external resource fails.

CWE

After searching suitable one, I gave up. What fits by title do not fit by description etc.

Level

By current logic, it's level 2.

[tghosth]

In terms of chapter, I think V12 makes the most sense. Maybe we need a new section there called application resources which would include this requirement as well as the new requirement from #1620. What do you think?

[elarlang]

It fits together with #1620. I'm not fan ot the service section in V12, but as I don't have any better idea, then let's put those requirements there and we can move them around later if needed.

[elarlang]

Reopen for clarification.

As added requirement 12.7.1 purpose was not clear (discussion in #1778), it makes sense to improve it.

#	Description	L1	L2	L3	CWE
12.7.1	[ADDED] Verify that the application is designed in a way that a failure to access external resources does not result in the entire application failing, for example using the circuit breaker pattern.		✓	✓

The main purpuse is the point - application must handle the situation when some connection is not available, so it puts me to rethink (#1748 (comment)) the category/section and it seems better match for V7.4.

Current V7.4 Error Handling

#	Description	L1	L2	L3	CWE
7.4.1	Verify that a generic message is shown when an unexpected or security sensitive error occurs, potentially with a unique ID which support personnel can use to investigate.	✓	✓	✓	210
7.4.2	[MODIFIED] Verify that a consistent and standardized exception handling mechanism (or a functional equivalent) is used across the codebase.		✓	✓	544
7.4.3	Verify that a "last resort" error handler is defined which will catch all unhandled exceptions. (C10)		✓	✓	431

• Option 1 - to just move current 12.7.1 to 7.4 (I prefer this to put special spotlight for the problem - nowadays most web application have some external connections to handle)
• Option 2 - as "handle the error" in an abstract way it is already covered, maybe just merge that into 7.4.3 (mention there)
• Option 3 - leave it in V12.7

[jmanico]

Suggestion to enhance 7.4.2 to make sure granularity is used. 7.4.2 [MODIFIED] Verify that a consistent and standardized exception handling mechanism, or a functional equivalent, is uniformly implemented across the codebase, and ensure it adequately addresses distinct error types including system, application,user-generated and security-specific exceptions

[elarlang]

Suggestion to enhance 7.4.2 to make sure granularity is used. 7.4.2 [MODIFIED] Verify that a consistent and standardized exception handling mechanism, or a functional equivalent, is uniformly implemented across the codebase, and ensure it adequately addresses distinct error types including system, application,user-generated and security-specific exceptions

For me it feels like a separate issue.