IDOR（安全でない直接オブジェクトの参照）
次は、IDOR（安全でない直接オブジェクトの参照）です。
日本語名からは複雑な脆弱性に聞こえますが、とてもシンプルな脆弱性です。
シンプルがゆえに悪用されることが多い脆弱性でもあります。
IDORは、Webアプリケーションの脆弱性の1つで、攻撃者がアクセスすべきでないリソースやデータに直接アクセスすることができる状態を指します。この脆弱性は、アプリケーションがユーザーの入力を適切に検証しないことに起因しています。
攻撃者はHTTPパラメータ、またはリクエストのボディで直接オブジェクトのIDやリファレンスを変更することで、他のユーザーのデータにアクセスしたり、そのデータを変更したりすることが可能になります。
例として、以下のようなURLを考えてみましょう
https[:]//example.com/profile?id=123
このページでは、ユーザーID123のプロフィール情報が表示されると仮定します。
例えば攻撃者がこのURLの「id」パラメータを変更して「https[:]//example.com/profile?id=124」へアクセスした場合に、もしアプリケーションが適切な権限検証を行っていなければ、攻撃者はユーザーID124のプロフィール情報にアクセスできるかもしれません。
仮にアクセスが可能な場合、ユーザーID124のメールアドレスやパスワードなどの情報が露呈することも考えられます。
どうですか？とてもシンプルですよね。
しかしIDORは実際に開発者が見逃してしまう事の多い脆弱性でもあります。
では実際に攻撃してみましょう。
まずは普通にファイルをダウンロードして開いてみます。
「198.txt」というファイルをダウンロードできました。
何度ボタンを押しても同じファイルがダウンロードされることが分かります。
Burp Suiteでどのようなリクエストを送信しているか見てみましょう。
すると下記画像の様になっていました。
「fileid」パラメータにファイル名を指定していることがわかりました。
ちなみに実際であれば、先ほど学んだディレクトリトラバーサルなどの脆弱性を疑うべきですが、ここではIDORのみを考えてみましょう。
先ほどのプロフィールの例と同じように、ファイル名の数字部分を変えることで本来ダウンロードできない別のファイルをダウンロードできるかもしれません。
例えば1個前の「197.txt」をダウンロードしてみましょう。
Burp SuiteのRepeater機能で送信してみます。
すると下記画像のような結果になりました。
「Good Job!!」というメッセージのテキストファイルがダウンロードできました。攻撃成功です。
本来であれば、このファイルをダウンロードできることが脆弱性であるかどうかを確認することが必要です。
つまり、このファイルをダウンロードできることが、開発者の想定内である可能性があります。IDORが成立したかと思えば、別の画面から普通にダウンロードできるファイルであったというようなケースも多々あります。
IDORは、数字を変更したりユーザーネームを変更したりするだけで比較的簡単に攻撃することができるうえに、開発者が見逃してしまうこともある侮ることのできない脆弱性です。
実際にIDORによって、他ユーザーのパスワードを閲覧することができる状態になったアプリケーションもあります。
対策
対策方法は大きく分けて2つです。
1つ目権限の不備をなくすことです。
ファイルダウンロードプログラムにしても、冒頭でお伝えしたプロフィールの例でも、バックエンドで権限の管理を適切に行う必要があります。
つまりどのユーザーがどのページやファイルにアクセスできるのかを厳密にバリデーションするということです。
2つ目は、予測不能な値であるハッシュ値やUUIDを使用することです。
c8e0d2a5a343d9d573553d6c7ad12b8e5850ebf5f088ce1f9abf56f6479ecef8 // ハッシュ値 abe895d1-26fb-4963-8795-a60e7abd1a88 // UUID
上記の様な予測不能な値を使用することで、IDORへの対策をすることが可能です。
例えば先ほどのファイル名で、「c8e0d2a5a343d9d573553d6c7ad12b8e5850ebf5f088ce1f9abf56f6479ecef8.txt」という値が仮に送信されているのを見ても、他のファイル名を推測することは不可能ですよね。
上記2つの対策を組み合わせることで強力な防御策にすることができます。
Webアプリケーションの脆弱性のまとめ
いかがだったでしょうか。
ここまでで様々なWebアプリケーションの脆弱性を学んできました。
ハッキングという実態のよく分からないものが、少しだけイメージのつくものになったのではないでしょうか？
もちろんハッキングはWebアプリケーションに限った話ではなく、ハードウェアやゲーム、クラウドサービスなどあらゆるものが対象になります。
しかしながら、Webアプリケーションは攻撃の対象となることが非常に多く、情報の漏えいやサーバーへの侵入など、企業にとって甚大な被害を与えることがあります。
今回お伝えできたのは、Webアプリケーションの脆弱性という広い分野でいうと10%に到達しない程度かもしれません。
しかし皆さんは、確実に以前よりWebアプリケーションにどのような脆弱性があるかを知ることができたはずです。
ここで学んだ知識をいつかどこかで何かの役に立てていただければ嬉しいです。
今回の脆弱なWebアプリのソースコードをGithubに公開しているので、興味のある方は見てみてください。
初学者にできるだけ分かりやすくプログラムを書いているので、JavaScriptのベストプラクティスに則っていない部分もありますがご了承ください。
github.com
より深くWebアプリケーションの脆弱性を勉強したい方は「Web Security Academy」をお勧めします。
portswigger.net
このサイトでは無料で、様々なWebアプリケーションの脆弱性を学ぶことができます。
このサイト上にあるラボを7割くらいクリアすると、Webアプリの脆弱性診断士として就職できるレベルに到達できるほど、コンテンツが豊富です。（個人的な感覚です。）
ぜひ興味のある方は挑戦してみてください。
続いては、サーバーへの侵入テストである「ペネトレーションテスト」を学びます。
僕が個人的に一番好きな分野ですので、楽しみにしていてください。
またペネトレーションテストでは、サーバーへの侵入の過程でWebアプリケーションの脆弱性を攻撃することも多いので、皆さんがここまでで勉強したことが土台となっていることが実感できると思います。
learn-ethicalhacking.hatenablog.com
