web-dev-qa-db-ja.com

リダイレクト時のX-Frame-Optionsヘッダー

サーバー上でいくつかのWebアプリケーションを実行しています（Debian 8はApacheを実行しています）。私の顧客の1人がアプリのセキュリティを向上させたいと考えています。サードパーティの会社によるセキュリティ監査を受けた後、修正したい脆弱性が見つかりました。これらの1つは、欠落しているX-Frame-Optionsヘッダーです。

ヘッダーはHTTPSアプリケーションに存在しますが、HTTPヘッダーにはありません。同じApacheインスタンスから公開されるWebアプリケーションの要件が異なるため、httpd.confファイルで一意のX-Frame-Optionsヘッダーを直接定義できません。

内部リダイレクトhttp -> httpsを構成してから、www.を追加しました。 webappaddress.com -> www.webappaddress.com。

問題は、HTTPバージョンを明示的に要求するが、リダイレクトの前にヘッダーを取得しないことにあります。何が起こりますか：get http version -> redirect on https -> redirect to www.* if missing。

virtualhostの私の構成（80と443の両方の場合）：

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{SERVER_NAME}$1 [R,L]

.htaccessの設定：

<IfModule mod_headers.c>
    Header set X-XSS-Protection "1; mode=block"
    Header set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
    Header always append X-Frame-Options SAMEORIGIN
    Header set X-Content-Type-Options nosniff
    <If "%{HTTP_Host} != 'www.webappaddress.com'">
            Header set Content-Security-Policy "default-src 'self'; style-src 'unsafe-inline' 'self' ;"
            Header always set Referrer-Policy "Origin-when-cross-Origin"
    </If>

だから私の理論はリダイレクトが起こる前にクリックジャッキングがまだ可能かもしれないということです（私が間違っているなら教えてください）が、あなたがFacebookやGoogleを見ると、彼らは同じアプローチに従っているようです：http-> httpsリダイレクトの前にセキュリティヘッダーはありません。

fb redirect

apacheheaderclickjackinghtaccessvirtualhost
1
bomba

セットアップはクリックジャッキングに対して脆弱ではありません。

クリックジャッキングはiframeにページをロードし、ユーザーをだまして操作させます。 X-Frame-Optionsヘッダーと frame-ancestorsディレクティブ は、iframeにページをロードしないようにします。

HTTP Webサイトにはこれらのヘッダーがなく、iframeにロードできますが、操作するものは何もありません。 HTTPSにリダイレクトするだけなので、攻撃者はiframeに空のページを読み込む可能性があります。ここをクリックする必要がないため、クリックジャッキングのリスクはありません。

1
Sjoerd