開発者向けセキュリティチェックリスト
Nostrのアプリケーション開発には中央集権型サービスとは違った脆弱性が発生する場合があります。
このページではNostrに関するアプリケーションの開発者 (e.g. クライアント、リレー、webサービス、bot) 向けにセキュリティ関連情報をまとめています。
署名検証 (クライアント全般)
問題: 悪意のあるリレーが改竄されたイベントを送ってきた場合、クライアントがイベントの署名検証を行っていないと意図しないイベントを取り扱ってしまう可能性がある
解決策: クライアントは受け取ったイベント全てに対して署名検証を行う
レスポンス検証 (クライアント全般)
問題: リレーがクライアントの問い合わせ (REQ) の内容と異なるイベントを返してきた場合、クライアント側で要求したものと合致するイベントとか検証しないと意図しないイベントを取り扱ってしまう可能性がある
例: @jack に関するkind: 1をリレーに要求したが、リレーが @jack のなりすましアカウントのkind: 1(ただし署名は正しい) を返してきた
解決策: クライアントはREQのフィルターの内容と合致するイベントが返ってきたかどうかを検証する。例題の場合にはレスポンスの pubkey が @jack のものであるかどうかを確認するなど
NIP-05ドメイン検証 (クライアント全般)
問題: NIP-05が設定されているアカウントに対して、当該ドメインに対して確認のリクエストを投げなければ、クライアント利用者がなりすましアカウント等を本人だと誤認する可能性がある
解決策: クライアントはNIP-05が設定されたドメインに対して検証のリクエストを行う
イベントの日時チェック (webサービス等)
問題: 極端に過去のイベントの受け入れを許容してしまうと、過去の改竄が可能になってしまう場合がある
例: ユーザがNostr上で1日1回ボーナスをもらえるサービスで、ユーザの利用開始以前に遡ってボーナスの要求が行われた
解決策: サービス側で受け取ったイベントの日時チェックを厳密に行う
DMメタデータ (全般)
問題: ユーザ間で匿名メッセージのDM (kind: 4) のやりとりを行った際に、「誰と誰がやりとりしているのか」が第三者のユーザにわかってしまう
解決法: 仕様上の問題であるため根本的な解決方法は現状では存在しない。参考リンクのように、自分に関するイベントを自分以外に返さないような信頼できるリレーのみを利用すれば回避は可能
DMの外部イベント参照 (全般)
TBU
Zap額検証 (クライアント全般)
TBU
巨大な外部リソース読み込み (クライアント全般)
問題: コンテンツ長の大きな外部リソースのURLを未検証でリクエストしてしまう場合に、クライアントの利用者の回線に過剰な負荷をかける可能性がある
例: 巨大なプロフィール画像が設定されたユーザのkind: 0をリクエストし、プロフィール画像をそのまま取得した
解決策: Amethystのように画像読み込みオプションを提供したり、snortのように自前の画像プロキシを用意する
削除イベントの取り扱い (全般)
TBU
nonceタグの取り扱い (全般)
TBU
不正なタグ (クライアント全般)
問題: 空文字やマルチバイト文字など、NIPで未定義の文字列をtagsの1要素目に設定された場合、バリデーションが不十分だとエラーが発生する可能性がある
例: Amethystで不正なタグを含む投稿を読み込んだ場合、アプリがクラッシュする
解決策: tagsのバリデーションを厳格にする
セキュリティに関する外部リソース