Security

Anyone can publish inscriptions, including arbitrary HTML, which ord server will serve at /content/<INSCRIPTION_ID>, /r/undelegated-content/<INSCRIPTION_ID>, and /r/sat/<SAT_NUMBER>/at/<INDEX>/content.

This creates potential security vulnerabilities, including cross-site scripting and spoofing attacks.

Without mitigations, a domain hosting an ord server explorer instance should be considered to be completely untrusted.

Cross-site Scripting

An attacker performs a cross-site scripting attack by injecting JavaScript into a vulnerable website such that it is later served to a victim, causing the malicious script to run in the victim's own browser with the same permissions as any other script from that website.

Such a script could access private site resources or perform privileged actions on the user's behalf, since it would be making requests on behalf of the user.

Cross-site scripting is not a concern for a vanilla ord server instance. ord server does not serve any private resources or allow privileged actions to be taken via the web interface, so although JavaScript can be injected using an inscription, it does not run with any meaningful permissions.

However, if you serve requests to ord server from a domain which also serves private resources or allow privileged actions, you may be vulnerable to cross-site scripting attacks.

Example

  • ord server is run under https://example.com/ord.

  • A bitcoin exchange is run under https://example.com/exchange.

  • Users can send bitcoin at https://example.com/exchange/send, with access controlled by a user's session cookie.

  • An attacker publishes a malicious HTML inscription with ID XYZ which contains JavaScript that accesses https://example.com/exchange/send and sends them to an attacker-controlled address.

  • When a user visits https://example.com/ord/XYZ, the malicious JavaScript requests https://example.com/exchange/send. Because the script executes on the user's behalf with the request including the user's session cookie, the server sends the user's bitcoin to the attacker.

To prevent this, do not make ord server available on the same domain and port as another web service which is vulnerable to cross-site scripting.

Spoofing

If ord server is run at a well known domain, for example, ordinals.com, an attacker could publish a malicious inscription that attempts to trick users into thinking that it represents the owners of the domain. For example, by publishing a mint page to induce users to send bitcoin. Additionally, the History API can be used to change the path without triggering a page reload, so inscription content can appear to the user under URL that suggests it was published by the site owners.

Example

  • ord server is run at https://example.com, by popular and well-respected Example Corporation.

  • An attacker publishes a malicious HTML inscription with ID XYZ which displays a mint page, and changes the URL path using the History API to /mint.

  • A user clicks a link to https://example.com/inscription/XYZ which displays the attacker's mint page, with the apparent URL of https://example.com/mint.

  • The user thinks that this is a potentially lucrative mint run by popular and well-respected Example Corporation and sends bitcoin to the mint address.

To prevent this, avoid giving users the impression that a domain hosting an ord explorer can be trusted for anything other than the content of the ord explorer itself.