MIME type for Web3 URL in Auto Mode
相关视频
正文
Abstract
This standard extends the ERC-6860 web3://
standard: in smart contracts not designed for web3://
(thus using auto mode), the MIME type of the returned data is either implicit (not advertised by the smart contract) or included within the returned data (RFC 2397 data URLs). This standard defines additional query parameters so that a MIME type can be returned when fetching a web3://
URL in these scenarios.
Motivation
When returning data to the web browser, a Content-Type
header indicating the MIME type of the data is strongly recommended, or the data may be incorrectly interpreted and displayed by the web browser.
The web3://
protocol has 2 modes: manual and auto.
- The manual mode is used on smart contracts explicitly requesting this mode (via an interface), so they are expected to signal the MIME type of the returned data, with the mechanism described in ERC-6860.
- On the other hand, the auto mode is used on both smart contracts specifically requesting the mode, and for all the others not signalling anything. While we can expect smart contracts explicitly requesting auto mode to signal the MIME type of the returned data, we cannot expect it for the others contracts.
This standard aims at filling this gap: with the introduction of additional query parameters, it will allow the URL to specify the MIME type of the returned data. Additionally, when the returned data is a RFC 2397 data URL, it will allow the URL to flag the returned data as data URL, so that the protocol can return the decoded data, and accompany it with the MIME type advertised in the data URL.
Specification
The standard introduces three query parameters to determine the MIME type.
-
mime.content=<contentType>
, where<contentType>
is a MIME type defined in RFC 6838. If the<contentType>
does not follow the structure of a MIME type, the URL is not fetched and an error message is displayed to the user. After URL decoding,<contentType>
is set as the value of theContent-Type
header of the response; or -
mime.type=<fileType>
, where<fileType>
is a filename extension from which a MIME type is determined. If the filename extension is not recognized, the URL is not fetched and an error message is displayed to the user. The MIME type is then set as the value of theContent-Type
header of the response; or -
mime.dataurl
, which indicates to decode the returned bytes as a RFC 2397 data URL. After decoding, the decoded body will be returned as the main output, and the MIME type specified in the data URL will be used. If the data cannot be parsed as data URL, an error will be returned.
If multiple query parameters are present, the last query parameter will be applied. If none of the query parameter is specified, Content-Type
is defined by ERC-6860. If the returns
query parameter is specified, the mime.xxx
parameters will be ignored and the Content-Type
will be defined by ERC-6860.
In RFC 2234 ABNF notation, the ERC-6860 syntax is :
attribute = attrName "=" attrValue
attrName = "returns"
/ "returnTypes"
attrValue = [ "(" [ retTypes ] ")" ]
This standard evolves it into:
attribute = retAttr / mimeCAttr / mimeTAttr / mimeDAttr
retAttr = retAttrName "=" retAttrValue
retAttrName = "returns"
/ "returnTypes"
retAttrValue = [ "(" [ retTypes ] ")" ]
mimeCAttr = "mime.content=" mimeCAttrVal
mimeCAttrVal = # ABNF of MIME type as in RFC 6838
mimeTAttr = "mime.type=" 1*( ALPHA / DIGIT )
mimeDAttr = "mime.dataurl"
Examples
Example 1
web3://0x91cf36c92feb5c11d3f5fe3e8b9e212f7472ec14/accessorizedImageOf/1289?mime.content=image/svg%2Bxml
where the contract is in auto mode.
The protocol will call the contract 0x91cf36c92feb5c11d3f5fe3e8b9e212f7472ec14
with the message defined in ERC-6860 and the returned Content-Type
header will be set to image/svg+xml
.
Example 2
web3://0x91cf36c92feb5c11d3f5fe3e8b9e212f7472ec14/accessorizedImageOf/1289?mime.type=svg
where the contract is in auto mode.
The protocol will call the contract 0x91cf36c92feb5c11d3f5fe3e8b9e212f7472ec14
with the message defined in ERC-6860 and the returned Content-Type
header will be set to image/svg+xml
.
Example 3
web3://0xff9c1b15b16263c61d017ee9f65c50e4ae0113d7/tokenURI/100?mime.dataurl
where the contract is in auto mode, and the returned data is data:application/json,["xx"]
.
The protocol will call the contract 0xff9c1b15b16263c61d017ee9f65c50e4ae0113d7
with the message defined in ERC-6860 and decode the data according to the RFC 2397 data URL standard. The returned output will be ["xx"]
and the returned Content-Type
header will be set to application/json
.
Rationale
The standard uses three different query parameters rather than a single query parameter to avoid confusion - an implementer or a user can easily tell the expected returned MIME of a link. Further, in auto mode, the query parameters are not used to form the EVM message (e.g., calldata) and thus it is safe to introduce new query parameters.
Security Considerations
These new query parameters introduce Cross Site Scripting attack vectors : an attacker could exploit string or bytes returning methods he can influence by making them return unfiltered data injected by him, and then craft a URL to make the returned data interpreted as HTML, and then send the URL to victims. If the web3 hostname is well known, the victim may get a false sense of security.
Malicious actions using javascript are broad and can include :
- Extraction of data of web storage APIs (cookies, localStorage, sessionStorage, indexedDB), sent to the attacker
- Triggering a signature request or transaction confirmation request (via a wallet javascript interface)
Cross Site Scripting is a classical attack vector in HTTP websites, we expect developers to be wary of this. Nonetheless; the ability to specify the MIME type is unusual. auto
mode websites should be discouraged and the attack vectors well documented.
Copyright
Copyright and related rights waived via CC0.