Ref: NCC-EF-Clef-006
When Clef receives a request through its exposed API, metadata is displayed to the user in
charge of handling it. This metadata includes a variety of fields unrelated to what is being
signed like IP address, user-agent, origin, etc. There are 6 calls to showMetadata() within
signer/core/cliui.go that drive this functionality. Some of these fields can be trivially
tampered with and might provide a false understanding as users could rely too heavily on
them instead of the important fields.
The following ‘malicious’ request (with the redacted JSON taken from Go code example com-
ments) will be accepted by Clef.
curl-i http://localhost:8550/ \
-H "Content-Type: application/json"\
-X POST --data '{...}' \
-A "indicates INVALID CHECKSUM IS EXPECTED" \
-H "Origin: NCC Group requires IMMEDIATE APPROVAL per direction of J Smith"
As currently presented, the metadata provides little benefit to legitimate requests but may
facilitate illegitimate requests. A naive user may consider the extraneous request data as
superseding the true warning above and mistakenly approve this transaction.
Recommendation
Do not present request metadata alongside approval-specific data without clear delineation
and warnings. Either clearly label the categories presented and warn that request data
cannot be relied upon, or simply remove all request data.
Todo: look into if we can make this even more clear than it is currently.
Ref: NCC-EF-Clef-006
When Clef receives a request through its exposed API, metadata is displayed to the user in
charge of handling it. This metadata includes a variety of fields unrelated to what is being
signed like IP address, user-agent, origin, etc. There are 6 calls to showMetadata() within
signer/core/cliui.go that drive this functionality. Some of these fields can be trivially
tampered with and might provide a false understanding as users could rely too heavily on
them instead of the important fields.
The following ‘malicious’ request (with the redacted JSON taken from Go code example com-
ments) will be accepted by Clef.
As currently presented, the metadata provides little benefit to legitimate requests but may
facilitate illegitimate requests. A naive user may consider the extraneous request data as
superseding the true warning above and mistakenly approve this transaction.
Recommendation
Do not present request metadata alongside approval-specific data without clear delineation
and warnings. Either clearly label the categories presented and warn that request data
cannot be relied upon, or simply remove all request data.
Todo: look into if we can make this even more clear than it is currently.