はじめに

こんにちは。ウェブアプリケーションを開発する上で、セキュリティ対策は欠かせない要素のひとつです。昨今ではAIを活用することで、脆弱性の発見から修正までの工数削減が期待できます。本記事では、具体的な例として「オープンリダイレクト」の脆弱性を取り上げつつ、AIを活用した修正の流れをご紹介します。

なお、機密性の高いコードや情報をAIに入力する場合は、自社の利用ポリシー（コンプライアンス）を確認してください。また、AIの提案はあくまでも参考であり、実際の導入判断や最終的な検証は開発者自身で行う必要があるのでご注意ください。

今回はRuby on Railsを使った例で、オープンリダイレクトの脆弱性について詳しく見ていきます。

本記事の実行環境

本記事では、以下のような環境を使用して検証を行いました。  
環境によっては一部コマンドやバージョンが異なる場合がありますので、適宜読み替えてご利用ください。

• OS: macOS 15.3 (Build 24D60)
• Ruby: 3.2.5
• Rails: 7.2.2

検証環境

オープンリダイレクトを修正した後、脆弱性が解消されたかどうかを検証するために、下記のツールを使ってテストを行います。

• curl (リクエスト送信用)

なおRailsはDRY（Don't Repeat Yourself）と「設定より規約」の原則に従っているため、これらの構成要素を上手に組み合わせることで効率的にアプリケーションを開発できます。必要な箇所で適切な設定や追加のコードを書くことが一般的です。

オープンリダイレクトとは

「オープンリダイレクト」とは、アプリケーション内でリダイレクト先URLが動的に決定される際、ユーザーが意図しない外部サイト（悪意のあるサイトなど）へ誘導されてしまう脆弱性です。ユーザーがクリックや操作をするだけで、攻撃者が仕込んだ別のURLへ飛ばされてしまう可能性があります。

今回はこの脆弱性をAIと協力しながら修正する具体例をお伝えしたいと思います。

AIを使った修正の流れ

1.脆弱性の詳細をAIに説明・確認する

• プロジェクト内に潜むオープンリダイレクトの箇所を洗い出し、どのような形で攻撃が行われるかをまとめる。
• AIに質問して、一般的な修正手法やテストパターンなどのアイデアをもらう。

2.修正案の作成

• AIが提案する方法を踏まえ、実装の方針を固める。
• コードを書き換える際のベストプラクティス、可読性や拡張性の高さなども考慮する。

3.テスト・動作確認

• AIの提案をもとにテストコードを作成し、想定外の動作がないか確認する。
• 単なる動作確認だけでなく、脆弱性が本当に修正されているかを検証する。

上記1.2.3の流れでオープンリダイレクトを修正していきます。

1.オープンリダイレクトの例

本記事では、特に次の2種類のヘッダを悪用したオープンリダイレクトを取り上げます。

ヘッダの種類

(1)Refererヘッダ

(2)Hostヘッダ

どちらもHTTPリクエストヘッダに分類されますが、悪用される仕組みや修正方法が異なります。

(1) Refererヘッダを悪用したオープンリダイレクト

Refererヘッダとは

ユーザーがアクセスしているページに遷移してくる直前のページURLが格納されるヘッダです。アプリケーションの中には、このRefererヘッダを元にリダイレクト先を決定しているケースがあります。

脆弱性の例

redirect_to :back

このようなコードを利用していると、攻撃者がRefererヘッダを細工したリクエストを送信するだけで、ユーザーを悪意のあるサイトへリダイレクトさせることが可能になってしまいます。

(2) Hostヘッダを悪用したオープンリダイレクト

Hostヘッダとは

アクセス先のドメイン情報を含むHTTPリクエストヘッダです。通常はアプリやサーバーが使用する正しいドメイン名が含まれますが、意図的に改ざんされたHostヘッダを送信することが可能です。

脆弱性の例

#リダイレクトURLを生成する際に、request.hostやrequest.host_with_portをそのまま用いる
redirect_to "https://#{request.host_with_port}/some_path"

といった形でリダイレクト先を動的に決定している場合、攻撃者が細工したHostヘッダを送り込むことで、ユーザーを別の偽サイトに誘導することができます。

2.AIが提案する修正方法

(1) Refererヘッダの対策: redirect_to :back の修正

AIによる提案では、redirect_to :back を使用せず、固定のパスへリダイレクトする方法が挙げられました。例えば以下のようにします。

redirect_to my_page_path

これにより、ユーザーが来た元のURL（Referer）に依存せず、指定したページにリダイレクトできます。悪意あるRefererヘッダを送ってもリダイレクト先が固定になるため、オープンリダイレクトを防げます。加えて、ルーティングファイルを整備することでコードの可読性や保守性も向上します。

#config/routes.rb
namespace :admin do
  resources :users do
    # 任意のパスを定義
    # 例: get 'redirect_sample', to: 'users#redirect_sample'
  end
end

(2) Hostヘッダの対策: ホストヘッダを検証する

実装例

AIからの提案として、ホストヘッダを検証するメソッドをアプリケーションの親クラス（ApplicationControllerなど）に追加する方法があります。

#application_controller.rb など
before_action :validate_host

def validate_host

  #allowed_hosts は Settings から読み込む想定
  allowed_hosts = Settings.host

  unless allowed_hosts.include?(request.host_with_port)
    Rails.logger.warn "Invalid Host Header Detected: #{request.host_with_port} from IP: #{request.remote_ip}"
    render plain: "Invalid Host Header", status: :bad_request and return
  end
end

• Settings.host には、アプリケーションが許可する正規ドメインを設定します。
• リクエストのhost_with_portが許可リストに含まれていない場合にエラーを返すことで、攻撃者が細工したHostヘッダを弾くことができます。

設定例

config/settings.yml
  host:
    - "myapp.example.com:3000"
    - "myapp.example.com"

複数の環境やドメインを想定して並べると、開発・テスト・本番環境で切り替えて利用できます。

テストコードの例

AIにテストの作成を依頼すると、以下のようなサンプルを提示してくれます。これをもとに、様々なケースを想定してテストを充実させられます。

describe '#validate_host' do
  let(:allowed_hosts) { ["allowed-host.com:3000"] }

  before do
    allow(Settings).to receive(:host).and_return(allowed_hosts)
  end

  context '許可されたホストヘッダの場合' do
    it 'エラーにならない' do
        host! "[allowed-host.com:3000](<http://allowed-host.com:3000/>)"
        get :new
        expect(response).to be_successful
    end
  end

  context '許可されていないホストヘッダの場合' do
    it '400 Bad Request を返す' do
        host! "[malicious-host.com](<http://malicious-host.com/>)"
        get :new
        expect(response).to have_http_status(:bad_request)
    end
  end
end

3.動作確認（curlコマンド例）

(1) Refererヘッダの動作確認

#Refererを指定しない場合
curl -v
       -X PATCH
       -F "file=..." <https://example.com/materials/1000>

#Refererを細工する場合 (悪意のあるURLを設定)
curl -v
       -X PATCH
       -H "Referer: <https://attacker.com>"
       -F "file=..." <https://example.com/materials/1>

修正後のコードでは、Refererヘッダを細工してもリダイレクト先が変わらず、エラーが返る（あるいは安全なリダイレクトが行われる）ことを確認します。

(2) Hostヘッダの動作確認

#許可されたホストを指定
curl -v
       --header "Host: myapp.example.com:3000"
<https://myapp.example.com:3000/new>

#許可されていないホストを指定
curl -v
        --header "Host: malicious-host.com"
<https://myapp.example.com:3000/new>

後者では Invalid Host Header などのエラーが返ってくれば、想定通りに防御できています。

最後に

オープンリダイレクトは、一見見落としがちな脆弱性ですが、実際には攻撃者がユーザーを悪意あるサイトへ誘導できてしまうため非常に危険です。
AIを活用することで、

• 脆弱性の詳細の整理
• 修正案の発案
• テストコードの提案

といった一連の流れを効率化でき、抜け漏れのない実装が可能になります。今回はオープンリダイレクトを例に取り上げましたが、同様の方法で他の脆弱性（SQLインジェクションやXSSなど）にも適用可能です。ぜひ、チームや個人の開発フローにAIを取り入れて、より安全なウェブアプリケーションを構築してみてください。