問題タブ [web-application-firewall]

パス ベースのルーティングを使用して、Open Auth ID .net Core 2 アプリケーションを Web アプリケーション ファイアウォールの背後にある App Service として構成する際に問題があります。

私のアプリケーションは myapp.azurewebsites.net で、ネットワーク制限によりパブリック インターネットからアクセスできません。同じ VNET に WAF をデプロイし、パス ベースのルート "/Admin*" を使用して WAF と App Service 間のトラフィックを許可しました。

その結果、 https ://myapp.azurewebsites.netはインターネットにアクセスできなくなりますが、https://myWAF/Adminはアクセス可能になり、アプリ サービスにマップされます。

このセットアップは正常に機能しますが、Open ID 認証を .net コア アプリケーションに導入すると、発信 Location ヘッダーに応答 URI として myapp.azurewebsites.net/signin-oidc が含まれます。

ホストがインターネットからアクセスできないため、これは機能しません。私はいくつかのアプローチを試みました。

• Azure App Registrations のアプリケーション登録 URL にWAF URL ( https://myWAF/Admin/signin-oidc ) を追加して、AAD が変更された URL を (正当なものとして) 受け入れられるようにしました。
• startup.cs に app.UseForwardedHeaders (すべての X-Forwarded ヘッダーの再利用を強制する) をコーディングしました。これは、App Service によって送信される Location ヘッダーに影響を与えないようです。WAF が X-Forwarded ヘッダーを送信していると思いますが、そうである場合、Open Auth ID スタックはそれらを使用していません。
• myapp.azurewebsites.net を WAF URL に置き換えるために、WAF でヘッダーの書き換えをコーディングしました。これにより、URL が正しく置き換えられ、コールバックが許可されますが、相関エラー (「ノンスが一致しない」ことを意味する一般的な Open ID スタック エラーのようです) で失敗します。ナンスが、呼び出されている URL に基づいている可能性があります。戻る - 私の場合は WAF リダイレクトにより変更されますが、それは推測です)。

アプリで X-Forwarded ヘッダーを使用して、WAF でヘッダーの再書き込みをコード化する必要性を回避できるように思えますが、これを使用して変更することに成功した例は見つかりません。 Open ID によって送信される応答 URI。

私の質問です。OAuth コンテキストでプロキシを処理するための正しいアプローチとして X-Forwarded ヘッダーを使用していますか、それとも WAF でのヘッダー書き換えが正しいアプローチですか?

設定しました

私は AppDev 側ではなく、InfoSec 側からこれに来ています。最初にその警告を入れたかっただけです。問題は、私の WAF が特定のイメージを応答でブロックしていることです。HTTP プロトコル準拠に失敗しました:Body in GET または HEAD 要求。このルールをアクティブにしておくことを正当化する必要があるため、非開発者として質問します。

1. これは GET および HEAD リクエストのルールであるためブロックされているのでしょうか、それとも GET および HEAD リクエストで Body を許可できますが、それは本当に良い考えではありませんか?
2. なぜそれは良い考えではないのですか？GET または HEAD リクエストで Body を許可すると、どのような問題が発生する可能性がありますか?

みんなの助けを前もってありがとう。

次のnginx構成があります

URL http://127.0.0.1/test/test2/index.php (POSTMAN から) にアクセスすると、403 が返されます。しかし、ヘッダーに Host -> mydomain.com を追加すると、200 になります。

nginx の構成を追加add_header Host "$host";すると、nginx のホスト変数に mydomain.com が含まれていることに気づきました。nginxのドキュメントによると、意図的にホストヘッダーをhttpリクエストでオーバーライドすると127.0.0.1になることを知っています。

しかし、この方法では、攻撃者は Cloudflare WAF をバイパスして Web サーバーに直接リクエストを送信できます。nginxからのそのようなリクエストをブロックする解決策は何ですか?

次の解決策を試しましたが、うまくいきませんでした。
https://www.digitalocean.com/community/questions/how-to-block-access-using-the-server-ip-in-nginx https://blog.knoldus.com/nginx-disable-direct-access -via-http-and-https-to-a-website-using-ip/