Skip to content

Why does ApplicationMessage have an app field? #1493

Open
@sanity

Description

@sanity

I think I found a design flaw in the delegate interface. When constructing an ApplicationMessage in a client application, I noticed the client is expected to provide the app field:

pub struct ApplicationMessage {                                                                        
    pub app: ContractInstanceId,                                                                       
    pub payload: Vec<u8>,                                                                              
    pub context: DelegateContext,                                                                      
    pub processed: bool,                                                                               
}

The Problem

This appears to violate a critical security boundary:

1 The app field should represent the address of the webapp's contract that's sending the message
2 Allowing clients to specify this value means any client could impersonate any contract
3 This undermines the isolation between contracts that's fundamental to the security model

Expected Behavior

I would expect freenet-core to:

1 Set the app field based on the authenticated client's identity
2 Verify that the client is authorized to act on behalf of that contract
3 Not trust client-provided values for security-critical identity fields

Questions

1 Is this a design oversight, or am I misunderstanding the intended usage?
2 If clients are supposed to provide the app field, what prevents contract impersonation?
3 Should the API be redesigned so that app is set by the server rather than the client?

This seems particularly important since the original purpose of the app field appears to be preventing contracts from accessing each other's data - but that protection is ineffective if clients can freely specify any contract ID.

Metadata

Metadata

Assignees

Labels

questionFurther information is requested

Type

Projects

Status

Triage

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions