[Clarification/For Discussion] Multiple Clarifications for 1.5.2

[csfreak92]

ASVS 4.0 - 1.5.2 verification requirement is:

Verify that serialization is not used when communicating with untrusted clients. If this is not possible, ensure that adequate integrity controls (and possibly encryption if sensitive data is sent) are enforced to prevent deserialization attacks including object injection.

I would like to clarify from the community/maintainers of this project regarding a few items here:

• serialization for communication
• untrusted clients
• main point of this control

On the first sentence of this control, it is problematic since it says verify that serialization is NOT used when communicating with untrusted clients, isn't it that serialization is always used to communicate from server to clients? I have not seen any application not using serialization between client and server side for communicating with each other, unless there's another way I am not aware of? This part is a bit confusing.

Also, an assumption about the untrusted clients term is for client-side which is usually web browsers, mobile apps, etc., right? I guess if my assumption is right, we could at least add some statements on the V1.5 Input and Output Architectural Requirements some statements explaining the term untrusted clients for clarity of testers/developers.

Lastly, this requirement is a bit confusing whether is it referring to round-tripping of serialized data or is it referring about fresh input from the web browser (client-side)? The reason I guess for the preventative control would depend on what this control is preventing.

Any information from the community would help regarding clearing up this ASVS verification requirement.

[tghosth]

serialization for communication

Maybe we need to be clearer that we mean complex object serialization. i.e. not just take a set of values and considering them like an array or not just taking a simple json structure and reading values but actually passing complex objects which can contain logic.

untrusted clients

Happy for you to suggest some explanatory text for this.

main point of this control

I think this is primarily about accepting input from the client. This could be as a result of a round trip or it could be a new object generated at the client, no?

[csfreak92]

@tghosth, please see my comments below:

serialization for communication
Maybe we need to be clearer that we mean complex object serialization. i.e. not just take a set of values and considering them like an array or not just taking a simple json structure and reading values but actually passing complex objects which can contain logic.

Maybe we could clarify that in this control or perhaps in an explanatory text in V1.5 Input and Output Architectural Requirements to reflect this info about what is meant by object serialization here as exactly as you mentioned because most readers would assume sending input and output over the wire? What do you think?

untrusted clients
Happy for you to suggest some explanatory text for this.

Drafting an explanatory text suggestion for this and will reference this issue with a PR that I will create later. If it makes sense to add explanatory text for serialization as mentioned in the previous point, I'll add it as well. Let me know about it.

main point of this control
I think this is primarily about accepting input from the client. This could be as a result of a round trip or it could be a new object generated at the client, no?

I believe this is about accepting input from the client (both a result of round trip values or new objected generated at the client) as well. To prevent deserialization attacks, I would say use hashes or signatures (for round trip values) or encryption on payload/object level. Do you agree with that recommendation for fixing the security issue?

[tghosth]

serialization for communication

Feel free to draft explanatory text.

untrusted clients

I will take a look for the PR

main point of this control

I have thought about this more. Regardless of whether we are talking hashes, signatures or encryption, these solutions will only work for round-trip values and not serialized objects from the client. For serialized objects created by the client, we can only rely on a safe deserialization method/process. Do you agree? Do you think we need to reword in light of this?

[csfreak92]

@tghosth, I have submitted a PR for draft explanatory texts including untrusted clients and some explanation regarding serialization.

-> main point of this control

I have thought about this more. Regardless of whether we are talking hashes, signatures or encryption, these solutions will only work for round-trip values and not serialized objects from the client. For serialized objects created by the client, we can only rely on a safe deserialization method/process. Do you agree? Do you think we need to reword in light of this?

Regarding your question about this, I totally agree with you on this that most of those solutions only work for round-trip values and not serialized objects from the clients (which is the usual attack vector). I am not sure whether we should rewrite this to make some sense of it because if we will talk about round-tripped values, that's what was discussed on this other issue I had: #775. If we would say that we can only rely on a safe deserialization method/process, does that cover most cases? If you think we need to reword, please hold my PR for a while and I'll make some changes to accommodate that.

[jmanico]

Deserialization attacks only matter when untrusted data hits deserialization endpoints. So the use case where we create a JWT or other artifact and and sign it, and that artifact is not modified by the client in any way, and then that JWT is deserialized later server side - it's tempting to discuss signatures as a defense here but I implore you not to. Signing, encryption or integrity stamps do not fix the problem of a vulnerable deserialization endpoint. Period.  So in order to NOT confuse the issue 1.5.2 needs to go away IMO. We can certainly talk about signing and similar in the context of JWT's and other artifacts, that's where that discussion belongs. But to mix signing with deserialization issues confuses the issues significantly. Respectfully,

…

-- Jim Manico Manicode Security https://www.manicode.com

On 6/15/20 6:21 AM, csfreak92 wrote: @tghosth <https://github.com/tghosth>, I have submitted a PR for draft explanatory texts including |untrusted clients| and some explanation regarding |serialization|. -> main point of this control I have thought about this more. Regardless of whether we are talking hashes, signatures or encryption, these solutions will only work for round-trip values and not serialized objects from the client. For serialized objects created by the client, we can only rely on a safe deserialization method/process. Do you agree? Do you think we need to reword in light of this? Regarding your question about this, I totally agree with you on this that most of those solutions only work for round-trip values and not serialized objects from the clients (which is the usual attack vector). I am not sure whether we should rewrite this to make some sense of it because if we will talk about round-tripped values, that's what was discussed on this other issue I had: #775 <#775>. If we would say that we can only rely on a safe deserialization method/process, does that cover most cases? If you think we need to reword, please hold my PR for a while and I'll make some changes to accommodate that. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#772 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAEBYCOFB6RS42XVEN5IS4DRWXY2LANCNFSM4NGNLUIQ>.

[tghosth]

@csfreak92 I made some changes to your PR, take a look and tell me what you think.

@jmanico 100% agree. What do you think about the following change to 1.5.2:

v1.5.2 Verify that serialization is not used when communicating with untrusted clients. If this is not possible, ensure that deserialization is performed safely, for example by only allowing a white-list of object types or not allowing the client to define the object type to deserialize to, in order to prevent deserialization attacks.

[jmanico]

I think 1.5.2 changes from Josh are good as is. Perfect. The real nuance here is that the fix is super detailed for each language but this req points people in the right direction.

…

-- Jim Manico @manicode

On Jun 16, 2020, at 4:10 PM, Josh Grossman ***@***.***> wrote:  Assigned #772 to @jmanico. — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub, or unsubscribe.