CLOUD SECURITY LAB

🔐 私の情報を私が守る！URLパラメータの代わりにセッションを使用すべき理由（IDOR脆弱性）

—

by

cslab
in

開発者の皆さん、こんにちは！今日は、Webアプリケーションで非常によく見られるものの、一度悪用されると手に負えなくなるセキュリティ脆弱性と、その解決策についてお話ししたいと思います。👨‍💻

最近、コードレビュー中に次のような修正点を発見したと想像してみてください。

// 修正前 (Before) 👎
// const { userId } = req.params;

// 修正後 (After) 👍
const { userId } = req.session;

たった一行の変更。しかし、この小さな違いがあなたのサービスを地獄から救い出すかもしれません。「なぜこれがより安全なのですか？」という質問に明確な答えを得たいなら、この記事を最後まで注目してください！🚀

🤔 問題の始まり：URLからユーザーIDを取得する？

まず、問題となる既存のコードを見てみましょう。

// 安全でない方法
const {
    userId
} = req.params;

allocationsDAO.getByUserIdAndThreshold(userId, threshold, (err, allocations) => {
    // ... ユーザーIDでデータを照会して結果を表示
});

このコードは、URLパスに含まれる値（req.params）からuserIdを直接取得して使用しています。例えば、ユーザーがというアドレスにアクセスした場合、サーバーはuserIdを「user123」として認識し、そのユーザーのデータを照会します。

一見すると何も問題ないように見えますよね？しかし、ここには非常に恐ろしい罠が隠されています。

もし私が悪意のあるユーザー「hacker」で、私のIDが「user456」だと仮定しましょう。私の割り当て情報を表示するためににアクセスしたでしょう。しかし、ふとこんな考えが浮かびます。

「あれ？URLの末尾にあるIDを変えるだけで、他の人の情報も見られるんじゃないか？」

そこで、アドレスバーにと入力してEnterを押します。もしサーバーが何の権限確認も行わない場合…恐ろしいことに、「user123」の情報が私の目の前に表示されてしまいます！😱

これこそが、OWASP Top 10にも頻繁に登場する安全でない直接オブジェクト参照（Insecure Direct Object Reference, IDOR）脆弱性です。まるでアパートの棟と部屋番号さえ知っていれば、他人の家のドアを勝手に開けて入るような状況です。

✨ 完璧な解決策：信頼できる情報は「セッション」にある！

では、提供された修正コードはこの問題をどのように解決したのでしょうか？

// A4 不安全な直接オブジェクト参照の修正 - URLパラメータではなくセッションからユーザーIDを取得
const { userId } = req.session;

allocationsDAO.getByUserIdAndThreshold(userId, threshold, (err, allocations) => {
    // ... ユーザーIDでデータを照会して結果を表示
});

答えは、req.sessionを使用することです！

  • req.params (URLパラメータ): ユーザーがブラウザのアドレスバーでいくらでも操作できる値です。決して信頼してはならない外部入力値です。
  • req.session (セッション): ユーザーがログインに成功した際に、サーバーが「このユーザーは認証されたOOOです」とサーバー内部に保存し、保証する情報です。ユーザーはこのセッション情報を直接修正することはできません。まるで政府が発行した偽造不可能な身分証明書のようなものです。

新しいコードは、URLに何が書かれていようと関係ありません。代わりに、サーバーに保存されている現在ログインしているユーザーのセッション情報からuserIdを取得します。

したがって、私が「user456」としてログインしている状態で、巧妙にURLを…/allocations/user123に変更してリクエストを送信しても、サーバーは次のように動作します。

  1. 「おや、『user456』ユーザーがリクエストを送ってきたな。」（クッキーを通じてセッションを確認）
  2. 「コードでreq.session.userIdを使うように指示されているから、『user456』をuserId変数に割り当てよう。」
  3. 「結果として、『user456』のデータを照会して表示しよう。」

結局、私は他人の情報を決して見ることはできず、自分の情報だけを確認できるようになります。IDOR脆弱性が完全に防御されたわけです！🛡️

🎯 結論：あなたのコードは安全ですか？

今日検討したコード変更に対する答えは明確です。

はい、URLパラメータ（req.params）の代わりにセッション（req.session）からユーザー識別子を取得するように修正したことは、セキュリティを大幅に強化する非常に正しく重要な措置です。👍

この小さな変更は、ユーザーデータアクセスに対する認可（Authorization）を正しく実装するための核心的なステップです。常に覚えておいてください。「ユーザーからのすべての入力は潜在的な脅威である。」特にユーザーの身元を確認し、権限を制御する際には、ユーザーが操作可能な値を決して信用せず、サーバーが管理する信頼できる情報（セッション）を使用する必要があります。

今すぐあなたのコードを点検してみてください。もしかして、重要なデータを照会する際にURLの値をそのまま使用していませんか？😉

タグ: セキュリティ, ウェブセキュリティ, Nodejs, Express, IDOR, 安全でない直接オブジェクト参照, セッション, 認証, 権限, 開発, コーディング

Comments

コメントを残す

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です