「eラーニングで不正をする」セキュリティ勉強会を社内で開催しました

本記事で取り上げているのは、自社開発のサービスではなく、外部のサービスです。
また、特定のサービスに対して批判や問題を指摘することを目的とした記事ではありません。

はじめに

会社からeラーニング受けるようにと指示があったのですが、簡単に不正ができることに気づいてしまいました。
そこで、eラーニングの締切後にこれを題材にセキュリティ勉強会を開催してみました。

勉強会の意図は以下のとおりです。

• 身近なアプリを題材にすることで、セキュリティ対策は身近なものだということを知ってほしい
• 自分たちが開発している製品のセキュリティは大丈夫か？ということを改めて考える切っ掛けになって欲しい
• (マネジメント側の立場から、) 不正をしている人への威嚇 (実際に不正した人がいたかは不明)

どうしても開発って機能を作ることを優先してしまいがちなので、セキュリティ対策とかの非機能は知識としては重要と知っていても、なかなか自分ごととして捉えることが出来ないのですよね。
そこで、身近なアプリの脆弱性を題材にすることで、より具体的なものとして考えられるのではないかと思った次第です。

どんな不正ができたか？

eラーニングはざっくり書くと以下のようなものでした。

• 動画を見る
• 章の最後で4択問題のテストに回答

結構スタンダードな内容だと思います。

これに対して簡単にできた不正は2つありました。

1. 動画を16倍速で見る。
2. 動画もテスト受けずに完了できる。

ヤバいですね。
1は速すぎて内容を何も理解できないです。
2はもはや研修の意味が皆無ですね。

不正のやり方

まずは、どういう手段で不正ができたかをざっくりと説明します。勉強会の中では、それなりに詳しく説明しましたが、ここではぼかして書いておきます。

1に関しては、ブラウザ上に動画の再生速度の設定値が保存されている領域があったのでそこを書き換えたら16倍速で再生出来ました。なお16を超えると速度設定が機能しませんでした。
2に関しては、各ページの完了時に実行されている関数を見つけたので、その関数を直接実行してみたら完了になりました。

なぜ不正ができたのか？

なぜ簡単に不正ができるのかというと、1も2も処理を全てクライアントで実行されていたためです。
クライアントで実行される処理は開発者ツールを開くことでブラウザ上で書き換えが出来ます。
より具体的に言うと、ブラウザはHTML、CSS、JavaScriptなどのコードをダウンロードして実行しているので、それらは開発者ツールを使えば誰でも確認・編集ができてしまいます。

Webアプリケーションの処理は大きく分けて、サーバーサイドで実施される処理とクライアントつまりブラウザ上で実施される処理の2通りがありますが、クライアントで実施される処理は、基本的に全て中身を見られるし書き換えもできてしまう ということを前提で作る必要があります。
ですので、重要な処理はサーバーサイドで実施する事が重要です。

どういう対策が考えられるか？

では、どういう対策ができるか考えてみましょう。
クライアント側がダメなら全ての処理をサーバー側で実施すれば良いと思うかもしれませんが、今回のケースではサーバーサイドのみで対策することは出来ません。というのもサーバーの中で動画を流しても、クライアント側にいるユーザーはそれを見ることは出来ませんからね。本末転倒です。
ということは、動画の再生はクライアントで実施しながら、再生状況の管理はサーバー側で実施したいということになります。これ地味に結構難しいです。

サーバーとクライアントで連携する対策

あるべき論としては、サーバーとクライアンで情報を連携して、重要な情報をサーバーサイドで保持する対策が考えられます。

• 動画視聴中のログを定期的にサーバーに送信する
• サーバー側で、視聴ログを元に視聴時間が妥当かを検証する
• 完了時も、動画の視聴状況やテストの実施状況をサーバー側で検証する

このように重要な検証処理をサーバーサイドで実施する修正を素早く対応できるなら問題ありません。
しかし、このwebアプリには元々サーバーサイドの処理が不十分なので、環境を整えるのに時間がかかるかもしれません。修正中にもサービスは稼働しており不正は出来てしまいますので、長期間放置することはよろしくありません。
ですので、リリース済のアプリで問題の修正に時間がかかる場合は、例え不完全でも素早くできる対策をとることが重要なこともあります。

クライアントのみでできる対策

前述の通りクライアント側のコードは書き換え可能なので、クライアントのみで完全な対策は絶対に出来ません。しかし、不正をやりにくくすることは出来ます。

例えば、、、

• コードを難読化して、解析をしづらくする
  • 例えば関数名がcompleteとかでなくcy3he8ica_a_ev19gcmにするとか
• 再生速度の設定値を確認して、不正な値だったら1倍にする

何度も繰り返しているように、これらの処理自体も書き換えられたら不正は出来ます。ですが、その不正をする手間が普通にeラーニングを受けるよりも大変であれば、わざわざ不正をする人は殆どいないはずです。
根本対策が理想ではありますが、状況によってはこのような簡単にできる対策を素早く実施することも重要です。

まとめ

• 「クライアント側での処理は、全て書き換えられてしまう」という前提でアプリを作ろう
  • 重要な処理は、サーバーサイドで実施しよう
• 問題が発生したときに「完璧に修正する」が常に正しいとは限らないことを認識しておこう
  • 問題の中身、不具合の影響、修正の難易度、修正による影響、などを総合的に考える
  • 時には「場当たり的な対応」を実施しよう

この内容での社内研修を許可してくれた、NCDCのコーポレート部門って懐が広いなぁと思いました。