質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

新規登録して質問してみよう
ただいま回答率
85.48%
Webサイト

一つのドメイン上に存在するWebページの集合体をWebサイトと呼びます。

CORS

CORSとはCross-Origin Resource Sharingの頭文字をとったもので、ブラウザがオリジン以外のサーバからデータを取得するシステムのことです。

Azure

Azureは、マイクロソフトのクラウド プラットフォームで、旧称は Windows Azureです。PaaSとIaaSを組み合わせることで、 コンピューティング・ストレージ・データ・ネットワーキング・アプリケーションなど多くの機能を持ちます。

API

APIはApplication Programming Interfaceの略です。APIはプログラムにリクエストされるサービスがどのように動作するかを、デベロッパーが定めたものです。

Q&A

解決済

1回答

1333閲覧

対象外のオリジンからのアクセスを制限したい。

HelloWorld2

総合スコア32

Webサイト

一つのドメイン上に存在するWebページの集合体をWebサイトと呼びます。

CORS

CORSとはCross-Origin Resource Sharingの頭文字をとったもので、ブラウザがオリジン以外のサーバからデータを取得するシステムのことです。

Azure

Azureは、マイクロソフトのクラウド プラットフォームで、旧称は Windows Azureです。PaaSとIaaSを組み合わせることで、 コンピューティング・ストレージ・データ・ネットワーキング・アプリケーションなど多くの機能を持ちます。

API

APIはApplication Programming Interfaceの略です。APIはプログラムにリクエストされるサービスがどのように動作するかを、デベロッパーが定めたものです。

0グッド

2クリップ

投稿2019/04/15 08:41

※ソースコードベースの質問ではなく、「あるべき論」、「方針」に関する質問です。初心者のため、そもそもの認識に誤りがあるかもしれませんが、ご指摘、ご鞭撻頂けると幸いです。

やりたいこと

  • 対象のWebサイトのHTML内に、JavaScriptのタグを埋め込み、そこから自作のAPIを実行し、ajaxのpost通信でデータを送信します。
  • apiは、AzureのFunctionsを用いてC#で作成します。(今回の質問にはあまり関係ありません)
  • apiを実行できるWebサイトを、特定のOriginに限定します。

現状

  • api側でCORSの設定を行い、JavaScript内のajax送信の際、「contentType」に「application/json」を設定することで、プリフライトリクエストを送り、対象外のOriginからのapiの実行を防ごうとしています。

問題点

  • ajaxで「contentType」の指定を外して実行された場合、プリフライトリクエストは送れず、対象外のOriginからのapi実行は防げない認識です。(レスポンスはされないが、実行はされる)
  • したがって、悪意のあるリクエストからapiを守るために、CORSの設定以外の対策が必要だと考えております。

質問内容

  • 特定のOrigin以外からのapi実行を防ぐためには、どうすれば良いのでしょうか・・・?

考えていること

  • 無知の私の考えでは、api側で対象のOriginをすべて保持し、api側のソースコード内で、HttpRequestのリクエストヘッダのOriginヘッダを取得し、対象のOriginに含まれるかどうかを判定し、trueの場合apiを実行する、という考えしか思い浮かびません。。。(そもそもOriginヘッダの書き換えできるなら、悪意のあるサイトは弾けませんが・・・)

気になる質問をクリップする

クリップした質問は、後からいつでもMYページで確認できます。

またクリップした質問に回答があった際、通知やメールを受け取ることができます。

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

guest

回答1

0

ベストアンサー

CORSとプリフライトって、通常は通信出来ないクロスドメインな通信を安全に許可するための仕組みであって、サーバ側のセキュリティに寄与するものでは無いです。

オリジン間リソース共有 (CORS)
https://developer.mozilla.org/ja/docs/Web/HTTP/CORS

Cross-Origin Resource Sharing (CORS) は、追加の HTTP ヘッダーを使って、あるオリジン (ドメイン) で動いているウェブアプリケーションが、異なるオリジンのサーバーのリソースにアクセスできるようにする仕組みです。

そのため、通常のHTTPリクエストに対する認証やアクセス制限と同様の方法でアクセス制限をかける必要があります。
(クロスドメインの場合、cookieの扱いは注意が必要ですが。)

無知の私の考えでは、api側で対象のOriginをすべて保持し、api側のソースコード内で、HttpRequestのリクエストヘッダのOriginヘッダを取得し、対象のOriginに含まれるかどうかを判定し、trueの場合apiを実行する、という考えしか思い浮かびません。。。(そもそもOriginヘッダの書き換えできるなら、悪意のあるサイトは弾けませんが・・・)

HTTPリクエストヘッダーはHTTPクライアントが生成するものであり、自由に捏造可能です。
特定のリファラーやUAからしかアクセス出来ないようなページを用意したとしても、
簡単に突破可能なのと同じで、悪意を持ったリクエストを防ぐ手段にはなりません。

投稿2019/04/15 14:06

tanat

総合スコア18713

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

HelloWorld2

2019/04/16 01:44 編集

ご回答ありがとうございます。 > サーバ側のセキュリティに寄与するものでは無いです。 さまざまなサイトで書かれておりますが、あまりイメージがわいてないです。というのも、サーバ側でCORSの設定をするため、ブラウザ側でどこら辺がセキュアなのか・・・?という印象です。ブラウザ側で設定するなら非常に納得がいくのですが。 > 通常のHTTPリクエストに対する認証やアクセス制限と同様の方法でアクセス制限をかける必要があります。 なるほど、そうなのですね。 (通常の認証やアクセス制限について詳しくなく恐縮ですが)ログイン処理もない、不特定多数が閲覧するWebサイトからapiを実行する場合、apiへのアクセス制限をかけるのは難しいでしょうか?(「特定のオリジン」からの不特定多数からのアクセスを許可したいです)
tanat

2019/04/16 02:15

> サーバ側のセキュリティに寄与するものでは無いです。 さまざまなサイトで書かれておりますが、あまりイメージがわいてないです。というのも、サーバ側でCORSの設定をするため、ブラウザ側でどこら辺がセキュアなのか・・・?という印象です。ブラウザ側で設定するなら非常に納得がいくのですが。 スタート地点の背景(ブラウザは原則としてXHR等でのクロスドメイン通信は出来ないが、JSONP等で抜け穴的&非安全に通信できてしまう)から調べてみるといいと思います。 > 不特定多数が閲覧するWebサイトからapiを実行する場合、apiへのアクセス制限をかけるのは難しいでしょうか? オリジン=コンテンツの配信元=サーバなので、「特定のオリジンからの」というのは表現が若干ずれていると思いますが、 「今、特定のサイトにアクセスしている人だけ」という条件であれば、 そのサイトのサーバと何らかの方法でサーバ間通信させて - セッション情報を共有したり、 - APIアクセストークンをHTML上に表示してそれを使わないとAPIアクセス出来ないようにしたり - OAuthなどで認証させたり といった仕組みが考えられます。 通常のHTTPリクエストに対する認証やアクセス制限について1から説明するのは難しいので、まずは通常のwebアプリケーションの認証方法について調べてみてください。
guest

あなたの回答

tips

太字

斜体

打ち消し線

見出し

引用テキストの挿入

コードの挿入

リンクの挿入

リストの挿入

番号リストの挿入

表の挿入

水平線の挿入

プレビュー

15分調べてもわからないことは
teratailで質問しよう!

ただいまの回答率
85.48%

質問をまとめることで
思考を整理して素早く解決

テンプレート機能で
簡単に質問をまとめる

質問する

関連した質問