# v1.25.2(Security Patch)

### 概要

[API仕様書](https://www.notion.so/Startrail-PORT-All-in-one-document-for-API-SDK-API-SDK-36c4f8078d494919866284ead6d5d9e5?pvs=21)に記載のSignup/Login Flowに関して、お伝えしていたフローの署名検証に問題がありました。なんらかの方法で他者のEOAの電子署名を取得でき、かつStartrailの仕組みを高い精度で理解している人に限り、その他者のEOAになりすますことが可能なことが分かりました。

### Startrail-sdk-jsのパッチ・バージョン：`1.25.2`

### フロー上で必要な変更(色線が変更箇所)

<table data-card-size="large" data-view="cards"><thead><tr><th></th><th></th><th></th></tr></thead><tbody><tr><td>Before</td><td><img src="https://3244648189-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOu6aN3RW264zdJsOQMJ2%2Fuploads%2FpIuHc33l8GZMbQcn9F6m%2FScreenshot%202022-03-17%20at%2010.23.46.png?alt=media&#x26;token=4ffdb520-85ee-4d7d-b363-50115d232a3d" alt=""></td><td></td></tr><tr><td>After</td><td><img src="https://3244648189-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOu6aN3RW264zdJsOQMJ2%2Fuploads%2FFm3ljrRraayFakji4w8x%2FScreenshot%202022-03-17%20at%2011.37.45.png?alt=media&#x26;token=be8490d4-c051-4c76-89b4-ff018f8011d4" alt=""></td><td></td></tr></tbody></table>

```
# 差分のまとめ(番号はAfter図参照)
20.messageからprefixに変更
21.メッセージから接頭辞(=prefix)に変更
(Before:22.は削除)
24. 文字列から接頭文字に変更
25. 文字列から接頭文字を足し合わせた文字列に変更
```

### セキュリティ脆弱性について

Signup/Login Flow図の中で以下のフローがありますが、

<figure><img src="https://3244648189-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOu6aN3RW264zdJsOQMJ2%2Fuploads%2Fj2qEk5DO8gf0q1BfDaA6%2FScreenshot%202022-03-17%20at%2010.23.46%20copy%202.png?alt=media&#x26;token=0b0fa0b0-bbc6-4b68-a114-8fca5191d10d" alt=""><figcaption></figcaption></figure>

```
18. ランダムな文字列(=message)を生成し、EOAとマッピングさせる
22. カスタマイズしたメッセージ(=messageToBeSigned)を文字列として置き換える
26. 文字列、ユーザ情報、シグネチャを送信
27. 文字列、シグネチャからEOAを復元
```

22でカスタマイズしたメッセージ(=messageToBeSigned)を文字列に置き換えてサーバサイドに送信するため、サーバ側では18で生成したランダムな文字列(=message)と27で復元に使う文字列が同等の値であることを判断することは、22で使うカスタマイズのロジックを共有していないことから、困難だと言えます。

このことは、ユーザが任意のmessageToBeSigned、signatureを取得して、26のエンドポイントにリクエストを投げることで、27で他者のEOAを復元し、バリデーションを通過させてしまう可能性につながる。

#### メッセージのカスタマイズについて

Startrail-sdk-js内部では、署名を行う前に下記の処理を実行し、メッセージを変換しております。

理由は、ウォレットとして利用しているTorus社の実装に準拠したものであり、これによりメッセージに署名を行う際、ユーザはポップアップの確認ボタンを押す必要が無くなり、UIUXの改善につながります。

### コード上で必要な変更点

1. クライアント様のコード内にバリデーション用のロジックを追加する

   影響範囲と内容

   1. Startrail-sdk-jsの更新後、

      `signMessage()`のレスポンス値が

      ```jsx
      // 現状
      export interface SignMessage {
        signature: string
        messageHash: any
        message: string
      }
      // 新たな仕様
      export interface MessageSignature {
        signature: string
        prefix: string | undefined
      }
      ```

      上記のように変更されています。

      `messageHash`と`message`を送信する替わりに`prefix`をサーバサイドに送信してください。
   2. クライアント様側のサーバサイドに下記のようなロジックを追加いただきたいです

      要点:

      1. originalMessageを再取得する
      2. originalMessageからmessageToBeSignedを生成するロジックを追加

      ```jsx
      // ① DBからEOAを元に最初に生成し文字列を取り出す
      const originalMessage = await this.findOne(eoa)

      let messageToBeSigned
      if (prefix) {
      	// ② DBから取得したoriginalMessageを基に実際に署名を行った文字列を復元する
        messageToBeSigned = `${prefix}${originalMessage.length.toString()}${originalMessage}`;
      } else {
      　// ポップアップを隠さない場合も考慮し、prefixがundefinedである場合のロジックも記述
        messageToBeSigned = originalMessage
      }

      // HTTP call to Validator-API (message: messageToBeSigned, signature, address )
      ```

   ### 上記変更が難しい場合の代替案

   以下の動画にあるような追加のポップアップをログイン時に許容していただける場合は、messageToBeSignedの生成ロジックは必要なく、お使いのStartrail-sdk-jsでもご対応が可能となりますので、その際は別途、詳細を共有させてください。

{% file src="<https://3244648189-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOu6aN3RW264zdJsOQMJ2%2Fuploads%2FZwsc7tfdf7jUWEEHEpoA%2FUntitled_%20Mar%207%2C%202022%2011_08%20AM%20(1).webm?alt=media&token=b572e2ff-a4e7-4efa-8340-ea77f1a1b2af>" %}
