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

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

新規登録して質問してみよう
ただいま回答率
85.50%
PHP

PHPは、Webサイト構築に特化して開発されたプログラミング言語です。大きな特徴のひとつは、HTMLに直接プログラムを埋め込むことができるという点です。PHPを用いることで、HTMLを動的コンテンツとして出力できます。HTMLがそのままブラウザに表示されるのに対し、PHPプログラムはサーバ側で実行された結果がブラウザに表示されるため、PHPスクリプトは「サーバサイドスクリプト」と呼ばれています。

Ajax

Ajaxとは、Webブラウザ内で搭載されているJavaScriptのHTTP通信機能を使って非同期通信を利用し、インターフェイスの構築などを行う技術の総称です。XMLドキュメントを指定したURLから読み込み、画面描画やユーザの操作などと並行してサーバと非同期に通信するWebアプリケーションを実現することができます。

Q&A

解決済

2回答

7174閲覧

Ajax 対象ファイルのアクセス制限

yuux01

総合スコア34

PHP

PHPは、Webサイト構築に特化して開発されたプログラミング言語です。大きな特徴のひとつは、HTMLに直接プログラムを埋め込むことができるという点です。PHPを用いることで、HTMLを動的コンテンツとして出力できます。HTMLがそのままブラウザに表示されるのに対し、PHPプログラムはサーバ側で実行された結果がブラウザに表示されるため、PHPスクリプトは「サーバサイドスクリプト」と呼ばれています。

Ajax

Ajaxとは、Webブラウザ内で搭載されているJavaScriptのHTTP通信機能を使って非同期通信を利用し、インターフェイスの構築などを行う技術の総称です。XMLドキュメントを指定したURLから読み込み、画面描画やユーザの操作などと並行してサーバと非同期に通信するWebアプリケーションを実現することができます。

0グッド

1クリップ

投稿2015/11/04 14:49

Ajax で、PHPを呼び出しているのですが、そのPHPファイルにアクセス制限をかけることはできますでしょうか?

一般的な、特定の IP のみはじく、通すなどはできるのですが、

直接アクセスなどは、問題ないのですが、外部サイトからのアクセスには対応しきれていませんので、どうしたらいいものか悩んでおります。

リファラのチェックでもいいのですが、書き換えが可能ですし、送らないことすら可能です。

リファラが、空ならはじいてもいいのですが、そうすると、訪問できるユーザーが限られてしまいますので、できればそうしたくありません。

今考えているのは、連続的にアクセスがあった場合にはじくような方法を考えておりますが、何かほかにいい方法はありますでしょうか?

今のところ、単純に、外部ドメインからのアクセスができないようにできれば、十分なのですが。

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

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

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

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

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

guest

回答2

0

ベストアンサー

一般的なCSRF対策がそのまま使えるかと思いますし、
今回のケースだと単純にセッションをチェックしてもいいかと思います。

[セッションをチェック]

  1. ajaxの存在するページをPHPにして、適当なキーのセッションを発行(適切な時間のセッション生存時間を設定)。
  2. ajaxからPHPを叩いてもセッションは使用可能なので、1で発行したセッションが存在するかどうかをチェック、セッションが存在する場合だけ処理を継続し、セッションの生存時間をリセットする

[ワンタイムトークンでCSRF対策]

  1. ajaxの存在するページをPHPにして、PHPでユニークなトークンID(十分に長いランダムな文字列)を発行、データベース等にアクセス許可トークンとして保存し、同時にjsonなどで書き出してjavascriptで使えるようにする

2.ajaxからPHPを呼び出す際にアクセス許可トークンを同時にPHPに渡す
3. PHPはアクセス許可トークンが有効であるかどうかチェックする。有効であった場合は処理を継続し、使用したアクセストークンをDBから削除するなりして無効化する。同時に再度別のアクセストークンを発行して、データベース等に登録すると同時にajaxへのレスポンスとして渡す。
以下、2-3の繰り返し。

投稿2015/11/04 15:36

tanat

総合スコア18709

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

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

yuux01

2015/11/04 16:11

回答ありがとうございます。 少し深く考えすぎかもしれませんが、セッションも発行し、ワンタイムトークンも利用しているのですが、 ワンタイムトークンの場合、鍵の存在に気づかれてしまったらあまり意味はないですよね。 叩けば、鍵がもらえるのですし。 セッションは、独自セッションがまずいのかな? セッション開いた状態で、別ページからアクセスされたら、できてしまうと考えたのですが、クッキーに鍵を保管するタイプのセッションならそのようなことはないですよね。 あーでも、クッキー読んで、鍵見つけたら同じ事か・・・ 加えて、クッキー無効にされたらセッション使えなくなってしまうので、 クッキーセッションは使わないようにしているのですが
yuux01

2015/11/04 16:20

無名関数内の変数に入れてしまえば、鍵は覗かれないのか・・・ ありがとうございます。なんだかできそうな気がしてきました。
yuux01

2015/11/04 16:54

問題は最初の鍵ですね。 鍵を、HTMLなり、スクリプトなりに埋め込むのは問題外。 かといって、叩いて鍵が出るシステムもだめ。 スクリプト止めて、叩かれたらそれまで。 完璧を目指してるわけじゃないんですが、今のままでは弱い気がするんですよね。
tanat

2015/11/04 22:58

>少し深く考えすぎかもしれませんが、セッションも発行し、ワンタイムトークンも利用しているのですが、 うーん、何をもって「弱いと思う」というのが曖昧なので、過剰もしくは不可能な実装をしようとしているように聞こえます。 完璧なCSRF対策というのはとても難しい(定義によっては不可能)のですが、それにチャレンジしようとしているのと同じになっています。 *CSRF対策を含めたwebアプリケーションのセキュリティについての詳細な技術書を読んでみると面白いと思いますよ。 >ワンタイムトークンの場合、鍵の存在に気づかれてしまったらあまり意味はないですよね。 >叩けば、鍵がもらえるのですし。 一番最初に叩く先がajaxで叩く先では無くアクセス元のページなのであれば、それは正当なアクセスと判断するしかありません。 これは通常、ブラウザ(HTTPクライアント)が行う流れそのものなので、HTTPサーバが同じ手順でアクセスされたらその正当性を区別する手段は存在しません。 印象としては「外部ドメインからのアクセス」の定義が曖昧なんだと思います。 HTTPの仕様的には「外部ドメインからのアクセス」は存在しないのでそれを厳密に検知することは不可能です。 「そのajaxのアクセスより以前に正当な手段でアクセスしていることの証明が出来る」ことを持って近似的に(サービス提供者が納得できる範囲で)確認するしかありません。 リファラー、セッション、ワンタイムトークンなどですね。 >無名関数内の変数に入れてしまえば、鍵は覗かれないのか・・・ 鍵自体の暗号化や難読化の有無は別として、鍵の存在自体をクライアントに気づかれ無いようにするのは原理的に不可能です。 何らかの方法でクライアントに送信させないといけません。 *javascriptの変数に入った時点でクライアント側では捕捉可能なので、無名関数に入れようが、javascript内に共通鍵を仕込んでワンタイムパスをジェネレートさせようが解析は可能です。 鍵自体の暗号化や難読化の有無は別として、鍵の存在自体をクライアントに気づかれ無いようにするのは原理的に不可能です。 何らかの方法でクライアント「に」送信させないといけないためです。 そのあたりを完全にクリアしようとするとブラウザから離れたところで鍵を受け渡しするしかありません。 例えば、 ブラウザ外の(事前にシードを交換している)物理HWやソフトウェアによるワンタイムパスの受け渡し SMSやメールによるワンタイムパスの受け渡し 画像認証(人間による判断による情報の受け渡し) 等があります。 *銀行などの厳密なセキュリティが必要なケースでは物理HWや事前にペアリングしたブラウザ外のアプリでのワンタイムパスや物理的な乱数表(最近は廃止の傾向)を使用することでセキュリティを確保しています。 が、セキュリティの厳密さと利便性は基本的に反比例します。 そのため、サービス提供者は 「セキュリティと利便性のバランス上、サービスとして納得できる範囲」を定義してからでないと、その技術仕様を決めることは不可能です。 今回のケースで「絶対に外部ドメインからアクセス出来ないようにする」とした場合、 「HTTPで通信を行う限り不可能」となりますが、 「必ずajaxが設置してるページを見てからでないとアクセス出来ない」であれば 例えばajaxでのアクセスが発生するたびに画像認証を行えば(画像はアクセス元サイトに表示させる)、外部から直接アクセスさせることはとても難しくなります。 が、現実的に「やってられない/実用に耐えない」仕様になります。 そのため、どこまで妥協するのか?という話になります。 たとえば ・攻撃者のスクリプトによる無制限な直接アクセスは防ぎたい とするのであれば 画像認証(やHTTP外で受け渡しされるワンタイムパス)の有効期限を定めれば、その有効期限の頻度で人間がアクセスして確認しないといけなくなり、目的は果たされます。 ・攻撃されたら検知して、致命的な状態になる前になんとかしたい なのであれば、事前にユーザ登録(自動化出来ない様に対策する)と認証を行っておき、 明らかに人間のアクセスとは思われないアクセスに関してはBANしてセッションをクリアすることでアクセス出来なくする。 という感じにあります。 という感じで、セキュリティを考えると上限は無いので、厳密にどこまで守りたいかを定義してみてください。
yuux01

2015/11/06 10:41

そうですね、柔軟性と厳密性はいつも悩む部分です。 自分でももう少し調べてみます。 ありがとうございました。
guest

0

例えば、CodeIgniterのダイレクトアクセス拒否のように、マイドメイン以外のアクセスを拒否するのも良いかと思います。

PHP

1if( $_SERVER['HTTP_HOST'] !== 'mydomain.jp' ) exit('No direct script access allowed');

投稿2015/11/05 02:52

NIA

総合スコア181

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

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

yuux01

2015/11/06 10:39

そうですね、ありがとうございます。
guest

あなたの回答

tips

太字

斜体

打ち消し線

見出し

引用テキストの挿入

コードの挿入

リンクの挿入

リストの挿入

番号リストの挿入

表の挿入

水平線の挿入

プレビュー

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

ただいまの回答率
85.50%

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

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

質問する

関連した質問