悪意のある Jetton リクエストは STON.fi ユーザーに影響を与えるのか？
DeFi におけるセキュリティは、使用するプロトコルだけの問題ではありません。ウォレットが正確に何の承認を求められているのかを理解することでもあります。
TON 上の STON.fi ユーザーにとって、見落とされがちな重要な違いがあります。標準の TON jetton は、ERC-20 形式の approve と allowance のモデルを使用しません。TEP-74 では、jetton の送信は、別のコントラクトが後で使用できる再利用可能な許可を与えるのではなく、特定の送信要求を承認するものです。
その違いによって、ユーザーは悪意のあるスワップ要求、偽のインターフェース、ウォレットの権限をどう考えるべきかが変わります。
TONジェットンはERC-20とどう違うのか
Ethereumでは、ERC-20トークンは一般にapprove、allowance、transferFromに依存します。ユーザーは特定の金額に対してスぺンダーを承認し、一度承認すると、そのスぺンダーは毎回新しい承認を必要とせずにトークンを移動できます。
標準のTONジェットンは、動作が異なります。
TEP-74では、標準的なapprove、allowance、transferFromの仕組みはありません。代わりに、ジェットン転送は実行される取引に対して承認されます。
適切に実装されたジェットンウォレットでは、オーナーから発生していない転送は拒否されるべきです。つまり、トークンとやり取りしたり、ウォレットを接続しただけでは、無制限かつ永続的なジェットンの支出アローワンスが自動的に作られるわけではありません。
それは重要なセキュリティ上の違いです。
では、悪意のあるジェットン要求でも損害を引き起こし得るのでしょうか？
はい。
ERC20のアローワンスがないからといって、ユーザーが悪意のある要求に対して免疫があるわけではありません。危険の源は、ユーザーが実際に署名している内容にあります。
偽のウェブサイトは、正当なDeFiインターフェースを模倣し、実際には攻撃者が管理するアドレスにジェットンを直接転送することを要求しているのに、STON.fiのスワップに見える取引を提示できる可能性があります。
一見すると取引は正当そうに見えるかもしれませんが、重要な問いは次のとおりです：
あなたのウォレットは具体的に何を送ろうとしていて、どこへ送られるのですか？
TON Connectは、1つ以上の送信（アウトゴーイング）メッセージを含む要求も提示できます。ユーザーがそれらのメッセージを承認すると、ウォレットは承認された内容を実行します。
だからこそ、要求が見慣れたトークンやプロトコルに関わっているように見えても、確認を無思慮にクリックするのは危険です。
本物のSTON.fiジェットンスワップの仕組み
通常のSTON.fiジェットン間スワップは、定義された取引フローに従います。
ユーザーのジェットンは、スワップ処理を支援する情報をペイロードとして含んだRouterフローに渡されます。次にRouterは、適切な流動性プールへ要求を転送し、以降スワップはプロトコルのロジックに従って継続します。
重要なセキュリティ上のポイントは、送金される金額が、ユーザーが承認する取引の一部だということです。
STON.fiに無制限で再利用可能なTEP-74アローワンスを付与することと同等ではありません。
そのため、1つの正当なスワップを承認したからといって、標準のジェットンコントラクトがSTON.fiや別のコントラクトに、将来の取引で無制限の残高を使うための許可を自動的に与えたことにはなりません。
本当のリスクが現れる場所
大きなリスクは、隠れたERC-20風のアローワンスではないことが多く、ユーザーが意図せずに間違った取引を承認してしまうことです。
悪意のあるインターフェースは次を要求するかもしれません：
直接のジェットン転送
意図したSTON.fiのRouterへ送る代わりに、取引が攻撃者のウォレットへ直接送る可能性があります。
想定外の金額
要求されている金額は、ユーザーがスワップしようとしていた金額より大きい可能性があります。
誤解を招く送信先
資金をまったく別の場所に送っているのに、見た目がSTON.fiに似せられている可能性があります。
ウォレット拡張またはより広い権限
ウォレットV5拡張は、単純なワンタイム転送を超える能力を導入することがあります。セキュリティへの影響が個別のスワップより広範囲になり得るため、これらはより慎重に評価されるべきです。
署名する前にSTON.fiユーザーが確認すべきことは？
取引を承認する前に、ウェブサイトの見た目だけに注目しないでください。取引そのものを確認してください。
送信するジェットンを確認し、それが意図した資産であることを確かめてください。
転送される正確な金額を確認してください。見慣れたトークンでも、見慣れない金額が安全とは限りません。
送信先と取引の構造を確認してください。要求が、未知のアドレスへの通常の送金ではなく、期待されるSTON.fiのやり取りと一致しているか確かめます。
また、何に署名しているかも確認してください。それは：
トークン転送、
データ署名、
それともウォレット拡張/機能の変更？
これらの行為は、セキュリティ上の影響がまったく異なります。
見慣れない資産については、トークン名・ティッカー・ロゴ・Webサイトのブランディングだけに頼らず、公式のトークンマスターアドレスを確認してください。攻撃者は、正当に見える見た目のジェットンを作れます。
ワンタイムの悪意ある送金に関する重要ポイント
ユーザーが悪意のあるジェットン転送を承認するように騙されたとしましょう。
その取引によって、承認された金額が直ちに失われる可能性があります。ただし、完了したその送金が、攻撃者が後で悪用して任意のSTON.fiスワップを行える「再利用可能なTEP-74アローワンス」になるわけではありません。
この違いは重要です。
悪意のある取引は依然として危険ですが、その危険は正しく理解されるべきです。標準のTEP-74挙動は、攻撃者に無制限のERC-20アローワンスを渡すこととは同じではありません。
ただし、基盤となるウォレット自体が侵害されてしまうと、状況は劇的に変わります。
ウォレットや鍵が侵害された場合はどうなりますか？
侵害されたシードフレーズ、秘密鍵、または十分に強力なウォレット拡張は、単一のSTON.fi取引以上の影響を及ぼし得ます。
その場合、攻撃者は、入手した能力によっては、ウォレットから将来の取引を直接承認できる可能性があります。
だからこそ、トークン標準そのものが永続的アローワンスを実装していなくても、ウォレットのセキュリティは根本的に重要なのです。
さらにもう一つ重要な考慮点があります：
標準外のジェットン
すべてのジェットンが、標準の単純な実装とまったく同じ動作をするわけではありません。
標準でない、またはカスタムのジェットンは、追加の管理ロジック、譲渡制限、フック、権限、その他のコントラクト挙動を導入する可能性があります。そのため、ユーザーは「すべての資産が、基本的なTEP-74実装とまったく同じリスク特性を持つ」と決めつけないようにしてください。
実践的なセキュリティ・ルール
最も安全な考え方はシンプルです：
「STON.fiを使っているか？」だけを聞かないでください。
尋ねましょう：
「私のウォレットは、どんな取引を承認させようとしているのか？」
正当なSTON.fiインターフェースであっても、慎重に扱うべきです。署名する前に、資産、金額、取引の送信先、ウォレットの実行内容を確認してください。
ウォレットの確認は、取引が安全である証明ではありません。単に、取引を実行することをあなたが承認する瞬間にすぎません。
最終的な要点
悪意のあるジェットン要求は確かにSTON.fiユーザーに影響し得ますが、標準のTONジェットンがERC-20の無制限アローワンスのようにこっそり動作するからではありません。
TEP-74では、標準的なapprove、allowance、transferFromのモデルはありません。通常のジェットン転送は、特定の取引として承認されます。
本当の危険は、誤った取引に署名すること、悪意のあるインターフェースを信じること、偽のジェットンとやり取りすること、予期しない送信メッセージを承認すること、または侵害された鍵や拡張によってウォレット自体をさらしてしまうことにあります。
STON.fiのあらゆるやり取りについて、署名する前に一呼吸置いてください。
ジェットンを確認してください。
金額を確認してください。
送信先を確認してください。
あなたのウォレットが実際に承認している内容を確認してください。
DeFiでは、最も安全な取引は「見慣れて見える」取引ではありません。
それは、あなたが確認した取引です。
STON.FIについてもっと見る