###### tags: `SAIGATE`
# ハッキング対策 詳細

### 問題

オークション出品のケースにおいて
1. 出品確定（出品者の出品商品のapprove）
3. オークションの実施（オフチェーン）
4. オークション落札者に落札確認画面の表示
5. 購入者がatomicmatchを呼び出す。
6. 購入完了

上記の工程の2の段階において、外部の非ユーザーからatomicmatchを呼び出し、オークションが完了していない商品について、勝手に入手が可能である可能性が指摘された。

### 技術的見解

上記については
1. atomicmatchの引数を攻撃者は入手することができない。
2. Openseaの方法は　上記のフローと異なるが、一時的にatomicmatchを呼び出せる状態になっている点は共通しており、現状その部分での攻撃は確認されていない。

という理由から、指摘された攻撃の可能性は考えにくいと言える。

### 詳細の説明
#### 1. atomicmatchの引数について

address[14] addrs,
uint[18] uints,
uint8[8] feeMethodsSidesKindsHowToCalls,
bytes calldataBuy,
bytes calldataSell,
bytes replacementPatternBuy,
bytes replacementPatternSell,
bytes staticExtradataBuy,
bytes staticExtradataSell,
uint8[2] vs,
bytes32[5] rssMetadata)

これの中で `uint8[2] vs,`　が購入者と出品者の秘密鍵で生成した情報で、商品ごとに割り当てられている。そのため、攻撃者はFanplaOwnerDBに保存された出品者の秘密鍵を入手しなければならない。それは過去のトランザクションのインプットデータにも入っているものの、商品ごとに割り振られているため、DBをハッキングしてデータを窃盗するしかない。

以上の理由から、外部の攻撃者がatomicmatchを呼び出すことはできないと考えられる。

#### 2. Openseaとの比較について

Openseaのフローは

1. 出品の確定
2. オークションの実施（オフチェーン）
3. 価格の決定と出品者によるatomicmatchの呼び出し
4. 購入完了

になっている。

つまり、2の段階において、出品者になりすまし、自分の提示価格に対して販売を行うことは可能である。
しかし、項目１での説明と同様の理由で出品者の署名情報を入手することは困難であり、現状そのような攻撃は発生していないことからも、今回提示されている攻撃の実現は難しいと考えられる。