「Michelson アンチパターン」の版間の差分

提供: tezos-wiki
移動先: 案内、 検索
(ページの作成:「= Michelson Anti-Patterns = Even though Michelson is designed to make it easy to write secure contracts and difficult to write vulnerable ones, it is still possible to w...」)
 
 
1行目: 1行目:
−
= Michelson Anti-Patterns =
+
=マイケルソンアンチパターン=
  
−
Even though Michelson is designed to make it easy to write secure contracts and difficult to write vulnerable ones, it is still possible to write buggy contracts that leak data and funds. This is a list of mistakes that you can make when writing or interacting with contracts on the Tezos blockchain and alternative ways to write code that avoid these problems.
+
マイケルソンは、安全な契約書を作成しやすく、脆弱な契約書を書くのが難しいように設計されていますが、データや資金を漏らしているバギー契約を書くことも可能です。これは、Tezosブロックチェーンの契約書を作成したり、これらの問題を回避するコードを書く別の方法で間違いを犯したリストです。
  
−
Note: We are currently reworking the concurrency model of Michelson (how and when sub-transactions are made), so that some of these patterns will be prevented by the language itself.
+
注：現在、マイケルソンの並行性モデル（サブトランザクションの方法と時期）を改訂しているため、これらのパターンの一部は言語自体によって防止されます。
  
−
== Refunding to a list of contracts ==
+
==契約のリストへの払い戻し==
  
−
One common pattern in contracts is to refund a group of people’s funds at once. This is problematic if you accepted arbitrary contracts as a malicious user can do cause various issues for you.
+
契約の1つの共通のパターンは、一度に人々の資金のグループを払い戻すことです。これは、悪意のあるユーザーがさまざまな問題を引き起こす可能性があるため、任意の契約を受け入れると問題になります。
  
−
Possible issues: ~<sub><sub><sub><sub><sub><sub><sub>~</sub></sub></sub></sub></sub></sub></sub>
+
考えられる問題：?<sub> <sub> <sub> <sub> <sub> <sub>?</sub> </sub> </sub> </sub> </sub> </sub>
  
−
* One contract swallows all the gas through a series of callbacks
+
* 1つの契約は一連のコールバックを通じてすべてのガスを呑み込む
−
* One contract writes transactions until the block is full
+
*ブロックが満杯になるまで1つの契約書がトランザクションを書き込む
−
* Reentrancy bugs. Michelson intentionally makes these difficult to write, but it is still possible if you try.
+
*リエントラントのバグ。マイケルソンはこれらを意図的に書くのを難しくしますが、試してもそれは可能です。
−
* A contract calls the `FAIL` instruction, stopping all computation.
+
*契約は `FAIL`命令を呼び出し、すべての計算を中止します。
  
−
Alternatives/Solutions: <sub><sub><sub><sub><sub><sub><sub>~</sub></sub></sub></sub></sub></sub></sub>~<sub><sub><sub>~</sub></sub></sub>
+
代替/ソリューション：<sub> <sub> <sub> <sub> <sub> <sub>?</sub> </sub> </sub> </sub> </sub> </sub>?</sub>?</sub>?</sub>
  
−
* Create a default account from people’s keys. Default accounts cannot execute code, avoiding the bugs above. Have people submit keys rather than contracts.
+
*人々のキーからデフォルトのアカウントを作成します。既定のアカウントは上記のバグを避けてコードを実行できません。契約者よりもむしろキーを提出させる
−
* Have people pull their funds individually. Each user can break their own withdrawal only. '''This does not protect against reentrancy bugs.'''
+
*人々に個別に資金を引っ張ってもらう。各ユーザーは、自分の脱退だけを壊すことができます。 '' 'これは、再入荷バグを守るものではありません。' '
  
−
== Avoid batch operations when users can increase the size of the batch ==
+
==ユーザーがバッチのサイズを増やすことができる場合、バッチ操作を避ける==
  
−
Contracts that rely on linear or super-linear operations are vulnerable to malicious users supplying values until the contract cannot finish without running into fuel limits. This can deadlock your contract.
+
リニアまたはスーパーリニア操作に依存する契約は、契約が燃料制限に踏み込まずに終了できなくなるまで、値を提供する悪意のあるユーザーにとって脆弱です。これはあなたの契約をデッドロックする可能性があります。
  
−
.. _possible-issues-1:
+
.. _possible-issues-1：
  
−
Possible issues: ~<sub><sub><sub><sub><sub><sub><sub>~</sub></sub></sub></sub></sub></sub></sub>
+
考えられる問題：?<sub> <sub> <sub> <sub> <sub> <sub>?</sub> </sub> </sub> </sub> </sub> </sub>
  
−
* Malicious users can force your contract into a pathological worst case, stopping it from finishing with available gas. Note that in the absence of hard gas limits, this can still be disabling as node operators may not want to run contracts that take more than a certain amount of gas.
+
悪意のあるユーザーは病理学的な最悪の場合に契約を強制し、利用可能なガスで仕上げるのを止めます。厳しいガス制限がない場合、ノードオペレータは一定量以上のガスを取る契約を実行したくないので、これは依然として無効になる可能性があることに注意してください。
−
* You may hit the slow case of an amortized algorithm or data structure at an inopportune time, using up all of your contract’s available gas.
+
*償却されたアルゴリズムやデータ構造の遅いケースを不適切なタイミングで打つことができます。契約の利用可能なガスをすべて使い切ってください。
  
−
.. _alternativessolutions-1:
+
.. alternativessolutions-1：
  
−
Alternatives/Solutions: <sub><sub><sub><sub><sub><sub><sub>~</sub></sub></sub></sub></sub></sub></sub>~<sub><sub><sub>~</sub></sub></sub>
+
代替/ソリューション：<sub> <sub> <sub> <sub> <sub> <sub>?</sub> </sub> </sub> </sub> </sub> </sub>?</sub>?</sub>?</sub>
  
−
* Avoid data structures and algorithms that rely on amortized operations, especially when users may add data.
+
*償却された操作に依存するデータ構造やアルゴリズムは避けてください。特にユーザーがデータを追加する際には注意が必要です。
−
* Restrict the amount of data your contract can store to a level that will not overwhelm the available gas.
+
*利用可能なガスを圧倒することのないレベルまで、契約で保管できるデータの量を制限する。
−
* Write your contract so that it may pause and resume batch operations. This would complicate these sequences and require constant checking of available gas, but it prevents various attacks.
+
*バッチ処理を一時停止して再開できるように契約書を書いてください。これはこれらのシーケンスを複雑にし、利用可能なガスの絶え間ないチェックを必要とするが、様々な攻撃を防止する。
  
−
*Do not assume an attack will be prohibitively expensive* Cryptocurrencies have extreme price fluctuations frequently and an extremely motivated attacker may decide that an enormous expense is justified. Remember, an attack that disables a contract is not just targeted at the authors, but also the users of that contract.
+
*攻撃が法外に高価になると想定しないでください。*暗号化通信は頻繁に極端な価格変動があり、非常に意欲のある攻撃者は、莫大な費用が正当であると判断する可能性があります。覚えておいてください。契約を無効にする攻撃は、著者だけでなく、その契約のユーザーをターゲットにしています。
 +
==シグネチャだけではリプレイ攻撃を防ぎません==
  
−
== Signatures alone do not prevent replay attacks ==
+
契約でメッセージを認証するために署名を使用する場合は、リプレイ攻撃に注意してください。ユーザーがデータに署名する場合、そのデータが契約の有効なメッセージではないことを確認する必要があります。あなたがこれをしないと、他の誰もあなたの契約を同じ入力で呼び出すことができ、以前の承認にピギーバックすることができます。
  
−
If your contract uses signatures to authenticate messages, beware of replay attacks. If a user ever signs a piece of data, you ''must'' make sure that that piece of data is never again a valid message to the contract. If you do not do this, anyone else can call your contract with the same input and piggyback on the earlier approval.
+
.. _possible-issues-2：
  
−
.. _possible-issues-2:
+
考えられる問題：?<sub> <sub> <sub> <sub> <sub> <sub>?</sub> </sub> </sub> </sub> </sub> </sub>
  
−
Possible issues: ~<sub><sub><sub><sub><sub><sub><sub>~</sub></sub></sub></sub></sub></sub></sub>
+
*以前に承認されたアクションを再生することができます。
  
−
* A previously approved action can be replayed.
+
.. alternativessolutions-2：
  
−
.. _alternativessolutions-2:
+
代替案/ソリューション<sub> <sub> <sub> <sub> <sub>?</sub> </sub> </sub> </sub>?<sub>?</sub > </sub>?
  
−
Alternatives/Solutions <sub><sub><sub><sub><sub><sub>~</sub></sub></sub></sub></sub>~<sub>~</sub></sub>~
+
*ユーザーに固有の署名を求めるデータを作成するには、内部カウンタを使用します。このカウンタは、ユーザーが承認する必要があるものを見つけるために、キーごとに設定する必要があります。これは、契約違反の再発を防ぐために、契約の署名付きハッシュとペアにする必要があります。
 +
* <code> SOURCE </code>命令を使用して、予想される送信者がメッセージの送信元であることを確認します。
  
−
* Use an internal counter to make the data you ask users to sign unique. This counter should be per key so that users can find out what they need to approve. This should be paired with a signed hash of your contract to prevent cross-contract replays.
+
ユーザーがすべてのスマート契約<sub> <sub>?</sub> <sub> <sub> <sub> <sub> <sub> <sub> <sub> <sub> <subに一意のキーを使用すると仮定しないでください<サブ> <サブ> <サブ> <サブ> <サブ> <サブ> <サブ> <サブ> <サブ> <サブ> <サブ> </sub> </sub> </sub> </sub> </sub> </sub> </sub> / sub> </sub> </sub> </sub> </sub> </sub> </sub> </sub> </sub> > </sub> </sub> </sub> </sub> </sub>
−
* Use the <code>SOURCE</code> instruction to verify that the expected sender is the source of the message.
 
  
−
Do not assume users will use a unique key for every smart contract <sub><sub>~</sub><sub><sub><sub><sub><sub><sub><sub><sub><sub><sub><sub><sub><sub><sub><sub><sub><sub><sub><sub><sub><sub><sub><sub><sub><sub><sub><sub><sub>~</sub></sub></sub></sub></sub></sub></sub></sub></sub></sub></sub></sub></sub></sub></sub></sub></sub></sub></sub></sub></sub></sub></sub></sub></sub></sub></sub></sub></sub>~~
+
ユーザーは、相互作用するすべての契約で常に異なるキーを使用する必要があります。そうでない場合、ユーザーが別の契約書に署名したメッセージを契約に送ることができます。内部のカウンターだけではこの攻撃から保護することはできません。あなたの契約のハッシュとペアにする必要があります。メッセージの送信元を確認する必要があります。
  
−
Users should always use a different key for every contract with which they interact. If this is not the case, a message the user signed for another contract can be sent to your contract. An internal counter alone does not protect against this attack. It ''must'' be paired with a hash of your contract. You must verify the source of the message.
+
==プライベートデータの格納/転送==
  
−
== Storing/transferring private data ==
+
トランザクションのブロードキャストを含むデータが誰にでも公開されると、そのデータは公開されます。ブロックチェーンの生態系のどこからでも秘密情報を送信しないでください。その情報を含むトランザクションをブロードキャストするとすぐに、誰でもそれを見ることができます。さらに、システム内の悪意のあるノードは、署名されていないトランザクションを遅延、変更、または並べ替えることによって操作できます。
  
−
Once data is published to anyone, including broadcasting a transaction, that data is public. Never transmit secret information via any part of the blockchain ecosystem. As soon as you have broadcast a transaction including that piece of information, anyone can see it. Furthermore, malicious nodes in the system can manipulate unsigned transactions by delaying, modifying, or reordering them.
+
.. _possible-issues-3：
  
−
.. _possible-issues-3:
+
潜在的な問題<sub> <sub> <sub> <sub> <sub> </sub> </sub> </sub> </sub> </sub>サブ>
  
−
Possible Issues <sub><sub><sub><sub><sub><sub><sub>~</sub></sub></sub></sub></sub></sub></sub>
+
*データに署名がない場合は、変更することができます
 +
*取引が遅れることがあります
 +
*秘密の情報が公開される
  
−
* If data is not signed, it can be modified
+
.. alternativessolutions-3：
−
* Transactions can be delayed
 
−
* Secret information will become public
 
  
−
.. _alternativessolutions-3:
+
代替案/ソリューション<sub> <sub> <sub> <sub> <sub>?</sub> </sub> </sub> </sub>?<sub>?</sub > </sub>?
  
−
Alternatives/Solutions <sub><sub><sub><sub><sub><sub>~</sub></sub></sub></sub></sub>~<sub>~</sub></sub>~
+
*個人情報をブロックチェーンに保存したり、トランザクションでブロードキャストしたりしないでください。
 +
*操作された場合、悪用される可能性のある情報を含むすべてのトランザクションに署名します。
 +
*カウンターを使用して取引注文を実施する。
  
−
* Do not store private information on the blockchain or broadcast it in transactions.
+
これは少なくともあなたの契約に送られたメッセージに論理時計を作ります。
−
* Sign all transactions that contain information that, if manipulated, could be abused.
+
==転送の前にすべての状態を設定しない==
−
* Use counters to enforce transaction orders.
 
  
−
This will at least create a logical clock on messages sent to your contract.
+
再入可能性はブロックチェーン上の潜在的な問題です。契約が別の契約に移転すると、その契約は独自のコードを実行し、元の契約に戻るなど、任意の追加移転を行うことができます。転送が行われる前に状態が更新されていない場合、契約は古い状態に基づいてアクションを呼び出して実行することができます。
  
−
== Not setting all state before a transfer ==
+
.. _possible-issues-4：
  
−
Reentrancy is a potential issue on the blockchain. When a contract makes a transfer to another contract, that contract can execute its own code, and can make arbitrary further transfers, including back to the original contract. If state has not been updated before the transfer is made, a contract can call back in and execute actions based on old state.
+
潜在的な問題<sub> <sub> <sub> <sub> <sub> </sub> </sub> </sub> </sub> </sub>サブ>
  
−
.. _possible-issues-4:
+
*複数の出金/措置
 +
*状態が2回後に更新された場合、不正な状態を生成する
  
−
Possible Issues <sub><sub><sub><sub><sub><sub><sub>~</sub></sub></sub></sub></sub></sub></sub>
+
..alternativessolutions-4：
  
−
* Multiple withdrawals/actions
+
代替案/ソリューション<sub> <sub> <sub> <sub> <sub>?</sub> </sub> </sub> </sub>?<sub>?</sub > </sub>?
−
* Generating illegal state if state is updated twice later
 
  
−
.. _alternativessolutions-4:
+
あなたのストレージにフラグを立ててリエントラントを禁止する。ユーザーにあなたの契約を再入力させる正当な理由がない限り、これはおそらく最良の選択肢である。
 +
*信頼できる契約またはデフォルトアカウントへの振込のみ。既定のアカウントはコードを実行できないため、常にコードに転送するのが安全です。契約を信頼する前に、その動作を変更できないこと、およびその信頼性が極めて高いことを確認してください。
  
−
Alternatives/Solutions <sub><sub><sub><sub><sub><sub>~</sub></sub></sub></sub></sub>~<sub>~</sub></sub>~
+
==消費可能な契約に他の人のための資金を保管しない==
  
−
* Forbid reentrancy by means of a flag in your storage, unless you have a good reason to allow users to reenter your contract, this is likely the best option.
+
Tezosでは、契約書に費用がかかると表示されます。費用のかかる契約の管理者は、契約内に保管された資金を使用して送金を行うことができます。これにより、コードに表示されている契約の動作についての保証を無効にすることができます。
−
* Only make transfers to trusted contracts or default accounts. Default accounts cannot execute code, so it is always safe to transfer to them. Before trusting a contract, make sure that its behavior cannot be modified and that you have an extremely high degree of confidence in it.
 
  
−
== Do not store funds for others in spendable contracts ==
+
.. _possible-issues-5：
  
−
Tezos allows contracts to be marked as spendable. Managers of spendable contracts can make transfers using the funds stored inside the contract. This can subvert guarantees about the contract’s behavior that are visible in the code.
+
潜在的な問題<sub> <sub> <sub> <sub> <sub> </sub> </sub> </sub> </sub> </sub>サブ>
  
−
.. _possible-issues-5:
+
*契約の資金を取り除くことができます。
 +
*契約は義務を果たさない可能性があります
  
−
Possible Issues <sub><sub><sub><sub><sub><sub><sub>~</sub></sub></sub></sub></sub></sub></sub>
+
..alternativessolutions-5：
  
−
* The funds of a contract can be removed.
+
代替案/ソリューション<sub> <sub> <sub> <sub> <sub>?</sub> </sub> </sub> </sub>?<sub>?</sub > </sub>?
−
* A contract may not be able to meet its obligations
 
  
−
.. _alternativessolutions-5:
+
あなたが支配していない消費可能な契約に資金を保管しないでください。
−
 
 
−
Alternatives/Solutions <sub><sub><sub><sub><sub><sub>~</sub></sub></sub></sub></sub>~<sub>~</sub></sub>~
 
−
 
 
−
* Do not store funds in spendable contracts that you do not control.
 

2018年5月31日 (木) 00:34時点における最新版

マイケルソンアンチパターン[編集]

マイケルソンは、安全な契約書を作成しやすく、脆弱な契約書を書くのが難しいように設計されていますが、データや資金を漏らしているバギー契約を書くことも可能です。これは、Tezosブロックチェーンの契約書を作成したり、これらの問題を回避するコードを書く別の方法で間違いを犯したリストです。

注：現在、マイケルソンの並行性モデル（サブトランザクションの方法と時期）を改訂しているため、これらのパターンの一部は言語自体によって防止されます。

契約のリストへの払い戻し[編集]

契約の1つの共通のパターンは、一度に人々の資金のグループを払い戻すことです。これは、悪意のあるユーザーがさまざまな問題を引き起こす可能性があるため、任意の契約を受け入れると問題になります。

考えられる問題：? ?

  • 1つの契約は一連のコールバックを通じてすべてのガスを呑み込む
  • ブロックが満杯になるまで1つの契約書がトランザクションを書き込む
  • リエントラントのバグ。マイケルソンはこれらを意図的に書くのを難しくしますが、試してもそれは可能です。
  • 契約は `FAIL`命令を呼び出し、すべての計算を中止します。

代替/ソリューション： ? ?</sub>?</sub>?</sub>

  • 人々のキーからデフォルトのアカウントを作成します。既定のアカウントは上記のバグを避けてコードを実行できません。契約者よりもむしろキーを提出させる
  • 人々に個別に資金を引っ張ってもらう。各ユーザーは、自分の脱退だけを壊すことができます。 'これは、再入荷バグを守るものではありません。' '

ユーザーがバッチのサイズを増やすことができる場合、バッチ操作を避ける[編集]

リニアまたはスーパーリニア操作に依存する契約は、契約が燃料制限に踏み込まずに終了できなくなるまで、値を提供する悪意のあるユーザーにとって脆弱です。これはあなたの契約をデッドロックする可能性があります。

.. _possible-issues-1：

考えられる問題：? ?

悪意のあるユーザーは病理学的な最悪の場合に契約を強制し、利用可能なガスで仕上げるのを止めます。厳しいガス制限がない場合、ノードオペレータは一定量以上のガスを取る契約を実行したくないので、これは依然として無効になる可能性があることに注意してください。

  • 償却されたアルゴリズムやデータ構造の遅いケースを不適切なタイミングで打つことができます。契約の利用可能なガスをすべて使い切ってください。

.. alternativessolutions-1：

代替/ソリューション： ? ?</sub>?</sub>?</sub>

  • 償却された操作に依存するデータ構造やアルゴリズムは避けてください。特にユーザーがデータを追加する際には注意が必要です。
  • 利用可能なガスを圧倒することのないレベルまで、契約で保管できるデータの量を制限する。
  • バッチ処理を一時停止して再開できるように契約書を書いてください。これはこれらのシーケンスを複雑にし、利用可能なガスの絶え間ないチェックを必要とするが、様々な攻撃を防止する。
  • 攻撃が法外に高価になると想定しないでください。*暗号化通信は頻繁に極端な価格変動があり、非常に意欲のある攻撃者は、莫大な費用が正当であると判断する可能性があります。覚えておいてください。契約を無効にする攻撃は、著者だけでなく、その契約のユーザーをターゲットにしています。

シグネチャだけではリプレイ攻撃を防ぎません[編集]

契約でメッセージを認証するために署名を使用する場合は、リプレイ攻撃に注意してください。ユーザーがデータに署名する場合、そのデータが契約の有効なメッセージではないことを確認する必要があります。あなたがこれをしないと、他の誰もあなたの契約を同じ入力で呼び出すことができ、以前の承認にピギーバックすることができます。

.. _possible-issues-2：

考えられる問題：? ?

  • 以前に承認されたアクションを再生することができます。

.. alternativessolutions-2：

代替案/ソリューション ? ?? ?

  • ユーザーに固有の署名を求めるデータを作成するには、内部カウンタを使用します。このカウンタは、ユーザーが承認する必要があるものを見つけるために、キーごとに設定する必要があります。これは、契約違反の再発を防ぐために、契約の署名付きハッシュとペアにする必要があります。
  • SOURCE 命令を使用して、予想される送信者がメッセージの送信元であることを確認します。

ユーザーがすべてのスマート契約 ? <subに一意のキーを使用すると仮定しないでください<サブ> <サブ> <サブ> <サブ> <サブ> <サブ> <サブ> <サブ> <サブ> <サブ> <サブ> / sub> </sub> </sub> </sub> </sub> </sub> </sub> > </sub> </sub> </sub> </sub> </sub>

ユーザーは、相互作用するすべての契約で常に異なるキーを使用する必要があります。そうでない場合、ユーザーが別の契約書に署名したメッセージを契約に送ることができます。内部のカウンターだけではこの攻撃から保護することはできません。あなたの契約のハッシュとペアにする必要があります。メッセージの送信元を確認する必要があります。

プライベートデータの格納/転送[編集]

トランザクションのブロードキャストを含むデータが誰にでも公開されると、そのデータは公開されます。ブロックチェーンの生態系のどこからでも秘密情報を送信しないでください。その情報を含むトランザクションをブロードキャストするとすぐに、誰でもそれを見ることができます。さらに、システム内の悪意のあるノードは、署名されていないトランザクションを遅延、変更、または並べ替えることによって操作できます。

.. _possible-issues-3：

潜在的な問題 サブ>

  • データに署名がない場合は、変更することができます
  • 取引が遅れることがあります
  • 秘密の情報が公開される

.. alternativessolutions-3：

代替案/ソリューション ? ?? ?

  • 個人情報をブロックチェーンに保存したり、トランザクションでブロードキャストしたりしないでください。
  • 操作された場合、悪用される可能性のある情報を含むすべてのトランザクションに署名します。
  • カウンターを使用して取引注文を実施する。

これは少なくともあなたの契約に送られたメッセージに論理時計を作ります。

転送の前にすべての状態を設定しない[編集]

再入可能性はブロックチェーン上の潜在的な問題です。契約が別の契約に移転すると、その契約は独自のコードを実行し、元の契約に戻るなど、任意の追加移転を行うことができます。転送が行われる前に状態が更新されていない場合、契約は古い状態に基づいてアクションを呼び出して実行することができます。

.. _possible-issues-4：

潜在的な問題 サブ>

  • 複数の出金/措置
  • 状態が2回後に更新された場合、不正な状態を生成する

..alternativessolutions-4：

代替案/ソリューション ? ?? ?

あなたのストレージにフラグを立ててリエントラントを禁止する。ユーザーにあなたの契約を再入力させる正当な理由がない限り、これはおそらく最良の選択肢である。

  • 信頼できる契約またはデフォルトアカウントへの振込のみ。既定のアカウントはコードを実行できないため、常にコードに転送するのが安全です。契約を信頼する前に、その動作を変更できないこと、およびその信頼性が極めて高いことを確認してください。

消費可能な契約に他の人のための資金を保管しない[編集]

Tezosでは、契約書に費用がかかると表示されます。費用のかかる契約の管理者は、契約内に保管された資金を使用して送金を行うことができます。これにより、コードに表示されている契約の動作についての保証を無効にすることができます。

.. _possible-issues-5：

潜在的な問題 サブ>

  • 契約の資金を取り除くことができます。
  • 契約は義務を果たさない可能性があります

..alternativessolutions-5：

代替案/ソリューション ? ?? ?

あなたが支配していない消費可能な契約に資金を保管しないでください。

「http://tezos-wiki.jp/wiki/index.php?title=Michelson_アンチパターン&oldid=26280」から取得