はじめにこんにちは、ウォレット開発運用部アプリケーション開発グループの山崎です。今回で5回目のテックブログ執筆となります。Depositという脆弱性と、それに対する取引所の対策手法について一例をあげて解説していきたいと思います。Depositについて解説している素晴らしい文献が存在するのですが、日本語では私が知る限りいい記事を見つけられなかったので、それなら自分で書いてしまおう!と思ったことにあります。https://arxiv.org/pdf/2006.06419.pdfというわけでこれから解説していきます。Depositについて簡単に説明します。Deposit」つまり「見せかけの残高」が存在するようにし、取引所から資金を抜き取るという攻撃手法が存在します。2020年8月に7,772のERC-20トークンにこの脆弱性があることが大学機関の調査によって明らかにされ、当時ブロックチェーン界隈で少し話題になりました。Depositの脆弱性をついた攻撃の具体的な手法と、取引所の対策例について説明していきます。これを理解する上で、ERC-20のメソッドへの理解が必要なので、まずはこれについて説明します。ERC-20のメソッドERC-20はファンジブルトークンを作る上での標準仕様を規定しているものです。ERC-20に則ってトークンを作成すれば比較的簡単にEthereum上のトークンを作成することができます。ERC-20トークンを作る上で実装の必要があるメソッドは以下になります。Depositについて解説していきます。メソッドを呼び出したアカウントから受信者へトークンを移動させるメソッドで、そのオペレーションが成功したかをbooleanで返します。Depositの具体的手法まずはSlowmistが公表した攻撃例のトランザクションを見てください。メソッドに脆弱性がある実装例です。)が送金すべきトークンを十分に持っているかを条件分岐によって判定しています。返し、実際の残高の移動は行われません。これを防ぐためにEIPでは以下の記述のように、送信者の残高が不足していた際は例外を投げることが推奨されています。以前はOpenZepplinのSafeMathのようにオーバーフロー時に例外を投げてくれる安全な数学関数を使うと良いとされていました。v0.8.0から、オーバーフローチェックがデフォルトで行われるようになったので、現在はSafeMathを使う必要はありません。成否だけを見て、トランザクションを取り込んでしまうと、スマートコントラクトの実装に脆弱性があるトークンでは実際には残高が移動していないのに誤って取り込んでしまう危険性があります。よる判断に加え、二次的な判定も加える必要があります。Ethereum系の通貨は入金用アドレスに着金した時点では残高として認識せず、入金用アドレスから別のアドレスに残高を実際に送金できることが確認できた時点ではじめて残高として認識するという手法がその一つの例です。Depositという脆弱性と、それに対する取引所の対策手法の一例について解説してきました。このように取引所ではお客様の資産を安全に管理するために、様々な観点から脆弱性への対策を講じていることを垣間見ていただければ幸いです。最後にコインチェックではエンジニアを積極募集中です。今話題のWeb3、ブロックチェーンの領域で勝負したいエンジニアの方などご興味ある方はお気軽にお申し込みください。FMもやっておりますので、よろしければ聞いてみていただけると幸いです。読者のみなさまGM、NFT開発Gの西澤です。こんにちは、ウォレット開発運用部アプリケーショ...2021-02-12Enjinのサービスを使ってNFTを鋳造してみる新規事業開発部の堀川です。»Coincheckコインチェック株式会社のエンジニアが知見を発信する技術ブログです。2引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。