適切な類推が必要：同じアプリに対して異なる方法で同じ機能を実装する異なるコーダーによる秒の問題
Moodleプラットフォームに見られる脆弱性 について学校にプレゼンテーションをしなければなりません。もちろん、これはパッチが適用されたレガシーバージョンにのみ適用されます。
問題は、技術的な知識のない聴衆を対象としたプレゼンテーションであることです。そのため、コードを使用して何かを説明することは許可されていませんが、技術的な理解がまったくなくても、聴衆が問題を理解するのに役立つ説明を提供する必要があります。
Moodleの問題は、同じ機能をさまざまな方法で実装するさまざまな寄稿者が原因で発生し、セキュリティの抜け穴が生じました。脆弱性の1つだけでは、システムに大きなダメージを与えるだけでは不十分でしたが、誤った想定の悪用、オブジェクトインジェクション、ダブルSQLインジェクション、および寛容な管理者ダッシュボードRCEを組み合わせることが可能になりました。
最初は安全に建てられた家でそれを説明することを考えましたが、その上にいくつかの追加のものが建てられたために不安になりましたが、もう少し具体的な、またはおそらく現実世界の歴史的なシナリオに合うものを探しています。
多分あなたはもっと良い考えがあるかもしれないと思いました。
これは、一般的に理解できるがかなり正確であると私が考える類推のアイデアです：
銀行が融資を受けるには、運転免許証と出生証明書の2種類のIDが必要です。銀行の従業員、アリスとボブはさまざまな面で怠惰です。アリスは常にチェックせずに「運転免許証検証済み」をスタンプしますが、ボブは常にチェックせずに「出生証明書検証済み」をスタンプします。
個人的にはこれは悪いことですが、それほど悪くはありません-偽造されたドキュメントを申請する人は誰でも、従業員がまだ実行している1つのチェックに引っかかるでしょう。しかし、ある日アリスは遅れて実行され、フォームに「運転免許証検証済み」のスタンプを押し、ボブが仕上げるのを任せます。ボブはフォームを見て、アリスが実際にライセンスを検証したと想定し、いつものようにチェックせずに「出生証明書の検証」をスタンプします。ローンは承認され、どちらの形式のIDも確認されません。
状況は、ローカルで役立つことを意図した機能を設計するために調整なしで独立して作業している人々ですが、組み合わせると災害を引き起こしました。
頭に浮かぶ最初の歴史的参照：
- 英国の鉄道システムのカオス ここで、各鉄道線の所有者は独自の軌道、軌道サイズ、列車、および時刻表（そして時には 自分の時計 ）を走らせました
- 最初のニューヨークの消防会社 彼らが顧客のために戦った場所（時々文字通り、火と殴り合いで）
どちらも楽しいストーリーと刺激的なビジュアルを生み出します。
両方に対する解決策は、集中監視と集中計画でした。これは、Moodleで経験したようなオープンソースの大失敗に対する同じ解決策です。
これが完全な例です：火星気候オービターの喪失。 https://www.wired.com/2010/11/1110mars-climate-observer-report/
引用するには：
NASAレビューボードは、問題はオービターのスラスタを制御するソフトウェアにあることを発見しました。ソフトウェアは、スラスターがポンドの力で発揮するのに必要な力を計算しました。メートル法の単位であると想定して、別のソフトウェアがデータを取り込みました：ニュートン。
これにより、約4.5timesの不一致が適切な量になりました。衛星は大気中に深く入りすぎて燃え尽きました。
これは、1981年のハイアットリージェンシーウォークウェイの崩壊を思い出させます。これは工学部の学生にとって一般的なケーススタディです。
出典： https://en.wikipedia.org/wiki/Hyatt_Regency_walkway_collapse#Investigation
追加の明快さを提供するための編集：
記録的な技術者は、致命的な設計上の欠陥がコミュニケーションの破壊に起因すると考えています。彼は...各プロジェクトを担当するアソシエイトに責任を委ねました。
記録的なエンジニアは、構造エンジニアが鋼と鋼の接続の設計を製造業者に任せることが業界では一般的な慣行であるとさらに主張しました...
...製作者...外部の詳細設計者に作業を下請けしました。その詳細設計者は、誤って信じていました...ショップの図面はすでに設計されていたため、接続自体については計算を実行していませんでした。
...記録のエンジニアは、ドキュメントに彼のシールを貼付しました... [そして] ...彼はすべての計算を個人的にチェックしたわけではなく、プロジェクトエンジニアと設計チームの仕事に依存していたと述べました。
出典： https://www.asce.org/question-of-Ethics-articles/jan-2007/
ブロック見積もりを簡潔にするために多くの情報が差し引かれていることに注意してください。ただし、完全な分析により、機械的な障害を完全に実現するために調整しなければならない仮定と誤解の完全な嵐の感覚を実際に得ることができます。
私は、opが最もよく説明しているものはスイスチーズのセキュリティに対応すると思います： https://en.wikipedia.org/wiki/Swiss_cheese_model
事故の因果関係のスイスチーズモデルは、多くの防御層が危険と事故の間にあるものの、各層に欠陥があり、それらが整列していると事故が発生する可能性があることを示しています。
講演で注意すべきことの1つは、壊滅的なイベントが原因だけで起こることはほとんどないということです。その代わり、それらはほとんどの場合、一緒になって災害を生み出す一連の障害です。そのようなソフトウェア関連の災害の1つは Knight Capital Groupの失敗 でした。貢献したいくつかの失敗点がありましたが、ソフトウェアの終わりはあなたが説明するものに適合します（強調は私のものです）
SMARSへの更新は、「Power Peg」と呼ばれる古い未使用のコードを置き換えることを目的としたもので、Knightは8年間使用していませんでした（8年間使用されなかったコードがまだコードベースに残っているのはなぜですか）謎ですが、それはポイントではありません）。 更新されたコードは、Power Peg機能をアクティブにするために使用された古いフラグを再利用しました。コードは徹底的にテストされ、正しく確実に動作することが証明されました。何がうまくいかないのでしょうか？
（ニューヨーク証券取引所への）展開に失敗したため、サーバーの1つで元のコードが実行されていました。だから、元々何かを完全に別のものにするために意図されていたコードを転用するとどうなるかを推測してください...
「死んだ」Power Pegコードの目的を理解することが重要です。この機能は、子注文が実行されたときに親注文に対して購入/売却されたシェアをカウントするためのものでした。 Power Pegは、親注文が履行されると、子注文のルーティングを停止するようにシステムに指示します。
8番目のサーバーのPower Pegフラグがアクティブになると、Power Peg機能は実行のために子注文のルーティングを開始しましたが、親注文に対するシェアの量を追跡していませんでした-無限ループのようです。
十分な注文が実行されたかどうかを確認するための追跡を行わずに、自動化された高速注文を市場に送信できるシステムがあるとしたらどうなるでしょうか。はい、それは悪いことでした。
最初の45分で、市場はオープンになり、212の親注文を受け取って処理しました。その結果、SMARSは数百万の子注文を市場に送り、その結果、154株に対して400万トランザクションで3億7700万株以上が取引されました。株式市場のジャンキーにとって、これはナイトが80株で約35億ドルのネットロングポジション、74株で31億5000万のネットショートポジションを想定したことを意味します。 簡単に言えば、ナイトキャピタルグループは45分で4億6,000万ドルの損失を実現しました。ナイトの現金と同等物は3億6500万ドルしかないことを思い出してください。 45分間で、ナイトは米国株式の最大のトレーダーであり、NYSEとNASDAQの主要なマーケットメーカーであったことから破産しました。
そのため、プログラマーAは「Power Peg」の引数を指定して関数を記述し、プログラマーBはそのコードを削除して、同じ引数がSMARSを表すようにしました。単一の失敗したロールアウトと...災害。
あなたが言っているのは「相乗効果」のようです。単独で小さな影響を与えるが、組み合わせると、それらの部分の合計を超える3つの異なるエージェント。
https://en.wikipedia.org/wiki/Synergy
類推したい場合は、バルビツール酸とベンゾジアゼピン（またはアルコール）のような2つの薬を組み合わせるのを検討するかもしれません。これはおそらく私が知っている最もよく知られた相乗効果です。
リンクされているウィキペディアの記事には、他にも役立つと思われる例がいくつかあります。
シャトーガイヤールの攻略
ギラード城は、英国のリチャード国王によって委託および設計された、非常に最先端の強く要塞化された城（文字通り、その名前は「強い城」と解釈されます）と見なされていました。城を越えたより広い要塞の数々は、フランス軍がそれを奪うのを防ぐためにも使用されました、軍は順番に防御溝を「単純に」埋めること、セーヌ川を渡る船の橋を作ることを含む様々な手段によって迂回しました（浮遊する要塞で攻撃の道筋を持続的に保つのを助ける）、そして外壁をトンネルで掘ります。
しかし、最終的には、他のすべての防御策と壁が破られた後、設計が後から選択された結果、第2カーテンウォールにピアシングを作成するために2つの異なる方法が採用されたため、倒れました。城の新しく追加された礼拝堂には、最初のベイリーから2番目のベイリーまで要塞化された門があり、ベイリーの壁をわずか3メートルの高さで貫通する窓がありました。
リチャード・ザ・ライオンハートは、城工学に関する最先端の理解で高く評価されました。しかし、彼の死後、兄のジョンラックランドは、城の2番目のベイリーに大きな礼拝堂を建設し、南向きの窓が必要であることを布告しました。おそらくカーテンウォールの高さのため、窓は壁自体に穴をあけて光を取り入れました。
理想的には、これらの南向きの窓が問題になることは決してありません。それらは小さすぎて、大きな力で城を直接動かす適切な手段を提供できませんでした。しかし、外側の最初のベイリーがエンジニアリング（トンネル/採掘）に陥った後、フランス軍は礼拝堂の窓を悪用して、2番目のベイリーに小さな力を入れ、内側から門を奪うのに十分でした（一部の情報筋によると、混乱を引き起こすために礼拝堂に）そしてそれらを開いて、それから主軍を最初のベイリーから入れさせます。
城は防御工学の偉業でしたが、革新的な外側のカーテンウォール と一連の弧 を備え、発射体、複数の溝、および最初の2番目と3番目のベイリーから完全に分離されたベイリー、2番目のベイリーの外側のカーテンウォールが両方に穴が開けられたという事実（取り外し可能なブリッジを介して）最初のベイリーから）およびライト（礼拝堂の窓）は、異なる目的のために作成され、異なるデザイナーによって作成された両方の開口部が存在するためにのみ悪用可能な重大な欠陥となりました。 3番目のベイリーは、壁が薄いために急速に落下しました（おそらく、非常に加速された建設スケジュールを満たすために、外側のベイリーが両方とも落下することはないと想定して切断するために必要な角として）。
作成する暴露ポイントが多いほど、通常の状況では良性または制御可能なリスクであると思われるものであっても、他のセキュリティ対策を回避できる可能性が高くなります。セキュリティ対策により作成する開口部が多いほど、他のセキュリティ対策よりも遅れている開口部であっても、誰かがメインゲートのセキュリティをバイパスし、別の方法を見つけます。他のセキュリティ対策の背後にある何かについてセキュリティで手抜きをすることが安全であると仮定すると、これらの正面向きの対策が失敗または回避された場合、攻撃者は簡単に最終目的を達成できます。
多層防御（しばしば城戦略と呼ばれます）は、考慮されている対策以外のすべての対策が失敗しないことに依存せず、その視点で強化するという観点から、セキュリティの概念にアプローチする必要があります。
城は、誰かが怠惰になったり、外壁の背後にあるセキュリティ対策について間違いを犯したり、特定のリング（壁）のプライマリゲート（メインゲート）よりも安全性の低いセカンダリ攻撃表面を意図せず提供したりして、落下した可能性があります）のセキュリティ。壁に開ける穴が多いほど、それらの穴のゲート方法について誰かが間違いを犯す可能性が高くなり、見落とされる可能性が高くなります。人々は間違いを犯します。間違いを探す場所が多いほど、見落とされる可能性が高くなります。専用の攻撃者は、攻撃者が利用できるようになったすべての攻撃を調査します。これは、自分が気付いていないものや、脆弱性であると考えられていないものも含みます。
ウィキペディアに包囲の完全な物語 の描写がありますが、それは不正確です（見たところは外見上、一般的な参照なので、 一部のソースは明らかにクレーム は、礼拝堂の冒涜を認めることを避けるためにフランス人によって意図的に誤った情報であった可能性があります）洗面所のシュートが原因であったとして2番目のベイリーの違反を指します。 実際の履歴 はHistoire Normandieでフランス語で入手できます。
これは実際の世界に当てはまる単純な類推であり、あらゆる技術レベルの学生が理解しやすいはずです。おまけとして、中高生にも効果があります。
自転車用ロックには2つの一般的なタイプがあります。
コード/チェーン
そして
Uロック
これらの各ロックは、簡単なツールを使用して無効にすることができます。
- コードやチェーンは頑丈なワイヤーバリカンで切ることができます。
- Uロックは、バールで強制的に開くことができます。
ただし、バリカンとバールはどちらもかさばるアイテムであるため、自転車泥棒は通常、一度に1つしか運ぶことができません。つまり、コードロックがあれば、バールで泥棒から保護され、Uロックがあれば、バリカンで泥棒から保護されます。
しかし、どうすれば両方から身を守ることができますか？ コードとUロックの両方を使用して自転車をロックします！このように、泥棒は自転車を盗むために両方のツールを携帯している必要があります。
ただし、これは、コードとUロックの両方が自転車に別々に取り付けられている場合にのみセキュリティのために機能します。
Moodleの場合、コードとUロックが互いに取り付けられています（1つは自転車の周りをループし、もう1つは接続するオブジェクトの周りをループします） 、つまり、泥棒がバイクを盗むためにそれらの1つを壊すことができればよいことを意味します！したがって、セキュリティを倍にする代わりに泥棒はバイクにたどり着くためにそのうちの1つを突破するだけでよいので、2つの異なるロックを携帯することで、セキュリティが半分に減ります。
あなたは古い家を買ったばかりです。時間の経過とともに、多くの異なる個人によって変更されてきました。
あなたは地下室に金庫を持っています。地下室に行くには2つのドアが必要です。あなたは金庫をさらに安全にしたかったので、家を買うとき、あなたはそれと外の世界の間に別のドアを追加することを確信していたので、今では3つのドアがあります！かなりいいですね。
残念なことに、このドアは低予算の会社によって製造されており、実際にはどのような基準にも準拠しておらず、実際に安全なドアを構築する責任を負っていませんでした。あなたは地元の建築業者に取り乱してドアを購入しました。さらに悪いことに、他の2つのドアも同様に選択されました。
残念ながら、ドアの3つのスタイルのいずれかに違反する可能性のある、簡単に利用できる方法があります。したがって、ドアが3つある場合でも、熟練した強盗が金庫に近づいて貴重品を盗むのは簡単です。確かに、偶然の機会の盗難は防止されます-悪党のような子供はあなたの富でうまくいかないでしょうが、決心した泥棒はそれが簡単だとわかります。
それをあなたの隣人と比べてください。彼らはより良い品質のドアを使用しただけでなく、彼の家を建てるために請負業者を雇いました-家の安全を理解している請負業者。その請負業者は、倒すのが難しいドア、または既知の倒し方法が存在しないドアを選択する方法を知っていました。彼は、ドアの配送と設置を行っているさまざまな下請業者の間で調整する方法を知っていました。彼はドアが正しく構築されたことを確認する方法を知っていました。この監視と調整により、あなたの隣人の金庫はあなたの金庫ほど簡単に略奪されることはありません。
ここにトロイの木馬に触発された類推があります。
元の馬をきっかけに、市はその種の攻撃に対抗するために自らを強化しようとしました。しかし、市内では、商品を配送するために大型車が移動する必要があります。そう：
ステップ1：新しい「馬」（今回はあまり怪しくないのは牛です）の断片を街に密輸します。木片は一度に1つずつ脅威を与えないため、質問されません。ただし、現時点では武器を密輸することはできません。
ステップ2：市内には木造車両を製造する職人がいます。作品が庭に現れたら、彼はそれらを組み立てます。その後、一人が牛の中に身を隠すことができます。
ステップ3：祭りの日、牛は他の娯楽とともに街中を練り歩きます。誰もが酔っているので、牛の乗員がその上に登り、そこから市壁に飛び乗っていることに誰も気付かないでしょう。
ステップ4：通常、護衛所を経由して市壁を登る必要があり、警備員のみが通行できます。そのため、その人がゲートハウスで折り返し、ゲートキーパーにシフトが終わったことを伝えると、ゲートキーパーは彼を信じます（とにかく彼は歓喜に加わりたいと思っています）。妥協したゲートキーパーを使用して、市のゲートを大きく開いたままにして、軍を配置することができます。
「同じ機能を異なる方法で実装する異なるコーダー」の問題に特に対処するには、アイテムを都市に持ち込む方法が2つあると考えてください。 1つは精査の少ない小さなアイテムで、もう1つは精査の多い大きなアイテムです。問題は、小さなアイテムが都市に持ち込まれ、そこに集められて大きなアイテムに組み立てられることを誰も考えなかったことです。
これが完全に当てはまるとは限らず、聴衆にとって暗すぎるかもしれませんが、思い浮かんだことの1つは、さまざまな機関が情報をやり取りしたり共有したりしていないために発生した911攻撃に関するインテリジェンスの失敗です。
私にとっては、誰かが自分のプログラムで「unserialize」を書いたように見えますが、その影響についてvery hardとは考えていません。最初のバージョンには何も問題はありませんでした。
おそらく、より深い設計と方法論の問題は、再実装されたその部分の契約が文書化されておらず、十分にテストされていないことでした。
誰かが細心の注意を払わずにシリアライゼーションを使用するときに起こりがちな面白いことをのぞくのは、初心者の視聴者（または実際にはすべての視聴者）にとっておそらくもっと面白いと思います。特にインタープリター型または非常に動的な言語で。もちろん、そのプレゼンテーションが機能するためには、少し技術的なことを説明する必要がありますが、それは目覚めている聴衆の代償です。
技術者以外の場合：
3つのドアがあり、それぞれが中央の警報システムに接続されています。
ドア1のセキュリティマニュアルには次のように書かれています。
アラームが鳴った場合：
- アラームをオフにする
- ドアをテストする
- 見つかった問題を修正する
- 問題を修正できない場合は、建物の管理者に連絡してください。
ドア2のセキュリティマニュアルによれば、
アラームが鳴った場合：
- 30秒待って、アラームが自動的にリセットされるかどうかを確認します
アラームがまだ鳴っている場合
- ドアをテストする
- 見つかった問題を修正する
- 問題を修正できない場合は、建物の管理者に連絡してください。
ドア3のセキュリティマニュアルによれば、
アラームが鳴った場合：
- 30秒待って、アラームが自動的にリセットされるかどうかを確認します。
- アラームがまだ鳴っている場合
- ドアをテストする
- 見つかった問題を修正する
- 建物の管理者に連絡して、何が起こったかを知らせてください。
これで、1人のセキュリティガードが対処する必要のある問題があることを他のセキュリティガードが認識する前に、1人のセキュリティガードがアラームをオフにすることができます。
管理者は問題や誤報の通知を受け取り、他の警報が無視されていることに気づきません。
リンク先の記事を深く掘り下げることなく。これは、根底にある仮定が作業している人々の間で一般的ではなかった問題のように見えます。
基本的に、システムは元々、ユーザーが要求できる「ユーザーに許可されていること」のリストを持つようにセットアップされていました。これらは明確に定義されており、システムにそれらを実行するように指示するだけで、それら自体が安全であるため、問題なくセキュリティパスワードを認証に含めます。
この問題は、後の開発者がセキュリティ特権を含むアカウントデータを更新する機能を追加したときに発生しました。この新しいシステムを使用して効果的にbootstrap必要な権限を知っている場合、データを設定するためのシステムは非常に安全ではないため、これがポイントでした。そもそも「注文するのではなく」というアプローチ。
基本的に、通常はシステムに何かをするように依頼し、権限がない場合は「いいえ」と言ってもかまいません。
しかし、whyについて考えていなかった誰かによる後の更新により、このように設定され、実際に拒否できないようにシステムに特権を増やすように要求する機能が追加されました。
プライベートパーティーに行きたいが、ゲストリストに含まれていないとしましょう。セキュリティ担当者はあなたを入れません。しかし、あなたが招待されていることを主催者に伝えると、彼らはそれを疑うことなくあなたをリストに載せます。
建物のすべての入り口に同じ大工がまったく同じ方法で同じドアを設置している場合は、1つを徹底的にテストするだけで（キックダウン、ロックの強制など）、その後はそれらが同じであることを確認するために他を簡単に見てください。大工がたくさんいて、一部が異なるドアを使用している場合は、それらすべてを徹底的にテストする必要があります。
アポロ13号はどうですか？コマンドモジュールと月着陸船用の二酸化炭素スクラバーは、異なる会社によって作成されました。 1つは正方形、もう1つは円形でした。
詳細はトム・ハンクスのドキュメンタリーをご覧ください:-)
MTBF、つまり6σの意味での「失敗」
これらは完全に異なるものですが、問題に適用されるいくつかの共通のプロパティを共有します。
障害間の平均時間は、物事の信頼性を評価するために一般的に使用される指標です。たとえば、車やハードディスクのようなものを購入した場合、その特定のことは、死ぬまで問題なく機能する可能性があります。しかし、平均すると、平均時間X後に、最終的には障害が発生します。これがMTBFです。
シックスシグマ（6σ）は基本的に同じ種類ですが、ほとんどの場合は処理せずにプロセスを処理し、運用時間ではなく「機会」の数を分析（および最適化）します。 ...何であれ、そして失敗もまた、...何であれ。これは、何かを作成したり、時間内に配信したり、電話に正しく応答したりするためのものです。
より具体的な例では、あなたの靴工場は1か月あたり100万個のスニーカーを生産し、そのうち3つ（理想的にはゼロ）が間違った色または靴ひもなしで出て、販売できないことを達成しようとしています。
これはどのように適用されますか？
MTBFには、よく知られている意味があります。downは、使用されるユニットの数に比例してpになります。通常の使用の2〜3年の間に携帯電話があなたのポケットの中で爆発することはほとんどありません、それは実際に起こると保証されていますsomeone 1,000万人がそれを所有している場合1年ほど前にキャンペーン/ PRの悪夢を思い出してください。
同様に、6σの角度から見ると、靴工場で100万個のスニーカーだけでなく10億個のスニーカーが製造されている場合、欠陥のある靴のペアは3,000ではなく3,000になります。
数年前、RAID-5の使用は推奨されていませんでした。どのようにすれば、データの安全性が高まりますか？ハードディスクがセクターを破損する可能性は非常に低いため、回復できません。それは決して起こらない...まあ、ほぼ。
しかし、ディスクが（最近のディスクのように）十分に大きく、多くのセクターがあり、それらのいくつかが一緒にまとめられている場合、基本的に保証再実行中に発生します-sync操作。つまり、すでに1つのディスクがダウンしているため、それを実行する必要がない正確な時間。さらに、2番目のディスクが再同期の途中で壊滅的に失敗する可能性があります。これも決して起こりません...まあ、ほぼ。ディスクが多いほど、発生する可能性が高くなります。
同じことが、同じ機能をソフトウェアに何度も再実装する場合にも当てはまります。各実装（every function、機能を複製するものだけでなく）は、1つの「機会」、つまりハードディスクと同等のものです。機能を複製することで機能が増えると、失敗する可能性が高くなります。さらに、確認するコードが増えます。
プログラマーはほとんどエラーなしで作業しているのですが（うまくいけば）、彼らが誤った仮定をしたり、まったくの間違いを犯したりする可能性は常にわずかです。与えられる機会が多いほど、それが起こる可能性が高くなります。
私のオリジナルに対する別の答えは、トピックを読み、それについて考える時間をもう少し持っていたことです。
多くの孤立したオフィスを持つ会社を想像してみてください。各部門は、フォームレターを介して指示されたとおりのことを常に行います。
手紙が悪意を持って送信されないようにするには、レターヘッドにパスワードを記載する必要があります。部署は地下の本部に、受け取ったパスワードが何をすべきかを伝えることを許可されているかどうか尋ねます。
それが真の場合、指示に従います。それ以外の場合、手紙は破棄されます。
セントラルオフィスは、会社のすべての人事データも処理します。セキュリティ上の理由から、セントラルオフィスには独自のメールアドレスがなく、直接変更する必要があります。
ある日、経営者は地下室に行って従業員データを更新する必要がなくなり、中央オフィスに自分の住所とフォームレターを提供するだけで飽きてきました。これにより、自分のオフィスから簡単に変更を加えることができます。
彼らは愚かではありません、彼らは本社のフォームレターがパスワードの変更について何も含まないことを確認しました。
奇妙なことに、すべてのフォームは特定のレターヘッドを探すことにより、共通のシステムで検証されます。
したがって、企業家が会社のガイドラインに一致する新しいフォームを作成するときに、パスワード変更フィールドが含まれている場合、本社はそれを喜んで受け入れて変更を加えます。
突然、その人は許可を変更して、会社内の任意の場所に有効な手紙を送信できるようになり、システムを完全に制御できるようになります。
これは、システムと、Moodleの例でシステムに何が起こったかの両方のかなり確かな類推です。
Ajaxの代わりの文字、およびパスワードフィールドを持つフォームレターの変更されたバージョンのSQLインジェクション。