Missing Type Juggling Vulnerability Checks in ASVS

[ImanSharaf]

It appears that type juggling checks are not currently in place, which could potentially leave some systems open to attacks.

Type juggling is a common vulnerability that occurs when type conversions are not properly validated. This can lead to unintended behavior, such as security weaknesses, that can be exploited by malicious actors.

I strongly recommend that you take this issue into consideration and implement the necessary checks to prevent type juggling vulnerabilities.

Thank you for your time and efforts in maintaining ASVS.

[elarlang]

I would say we don't have clearly suitable category for the requirement.

[ImanSharaf]

@elarlang What about category 5?

[tghosth]

Sounds like input validation (section 5.1).

How about:

Verify that strong variable comparisons are performed to avoid type juggling vulnerabilities.

What do you think @ImanSharaf @elarlang ?

[elarlang]

It's not only validating user-input.

For example, in PHP world it may happen everywhere in the code if you don't check type.
https://www.php.net/manual/en/language.types.type-juggling.php

edit: Requirement text is ok, but we don't have suitable category for that at the moment. I labeled it to "code review" to group similar requirements together and maybe we need to create new (sub)category for those.

[ImanSharaf]

Thank you for considering my suggestion. @tghosth The requirement text you proposed, "Verify that strong variable comparisons are performed to avoid type juggling vulnerabilities," captures the essence of the issue well. @elarlang I understand your concern about type juggling occurring not just in user input validation but also in other parts of the code. However, it is important to note that if the type juggling is not a result of user input or externally influenced data, the potential security risk would be significantly lower, as it would not be directly exploitable by malicious actors.

[elarlang]

However, it is important to note that if the type juggling is not a result of user input or externally influenced data, the potential security risk would be significantly lower, as it would not be directly exploitable by malicious actors.

As boolean true fact we can apply this logic everywhere, but we don't do it. Based on HTML injection (XSS): do we say, that if users don't control the data directly, then we don't need to encode it for the output? We don't say that. Display layer need to work without knowing from where the data comes. Program code need to work without making difference, does it handles user input or data from any other source. Otherwise, if something is reorganized, like some part of program code now handles userinput, no one have overview of it.

[tghosth]

@elarlang how about a section called "Secure Input handling" I think that would cover all the tmp code-review examples. What do you think?

[elarlang]

@elarlang how about a section called "Secure Input handling" I think that would cover all the tmp code-review examples. What do you think?

The title itself without context (for me) does not say what it is (I can say "Secure Input Handling" for output encoding and escaping as well). In general - if we can make it clear and separate from other categories (with clear scope), then we can create it. Maybe 5.4 or 5.5 needs renaming for that? (probably worth separate issue)

[tghosth]

@elarlang I think we are going to naturally discover that we need to create a new section to hold a bunch of attack specific protections. At this point, I don't see any way around that.... We will see this as we work on the V5 issues.

In the meantime, do we have any thing to add other than the following?

Verify that strong variable comparisons are performed to avoid type juggling vulnerabilities.

[elarlang]

For category it waits: #1643

[tghosth]

What do you think about the input validation section for this one? To my mind, this is an input validation mechanism but they need to be performing the validation securely.

[elarlang]

I don't think it's an input validation problem. Let's say user enters value 0 in HTML input field and HTTP protocol does not define what is the type for that. Validation - should an application accept the input or not.

It's up to the program code to use the value correctly. Given example in PHP may cause interpretation as "false":

if ($_POST['text-field-name']) { ... }

[tghosth]

Ok so can you think of any other way of categorising it?

[tghosth]

Suggested a fix in #1617 (comment) to address this along with type confusion.

[tghosth]

I am going to close this as I don't think there is any separate action on top of #1617