2009-04-07 13 views
2

重いAjax依存アプリケーションがあります。サーバーサイドスクリプトへの要求がスタンドアロンプ​​ログラムを経由せず、実際のユーザーがブラウザにアクセスしていることを確認する良い方法は何ですか?Ajaxセキュリティ

+0

あなたは、Webブラウザを介してあなたのWebサイトからこれらのAjaxリクエストを使用し、Ajaxとのインターフェースを作成する誰かが使用しないようにしたいと言っていますか? – Shard

+0

はい。これは特定のレベルのセキュリティに少なくとも達成できますか – Rakesh

+0

これから生じる単一のセキュリティ上の利点は考えられません。それを超えて、ブラウザからリクエストが来たことを保証する方法はありません。 @ブローダーツが正しいです。 –

答えて

0

興味深い質問。

アプリケーションに組み込まれているブラウザはどうなりますか?あなたはそれらを気にしますか?

おそらく、リクエストがブラウザから来ることを「証明する」方法を考えることはできますが、最終的にはヒューリスティックになります。ブラウザとアプリケーション間の線がぼやけている(たとえば埋め込みブラウザ)予期しないブラウザ(またはその予期しないバージョン)からユーザーを拒否するリスクが常に発生します。

6

実際にはありません。

ブラウザから送信されたリクエストは、スタンドアロンプ​​ログラムで偽装することができます。

本当に重要ですか?もしあなたが心配しているのであれば、要求が認証され、認証され、認証プロセスが良好であることを確認してください(Ajaxがブラウザのクッキーを送信するので、 "通常の"認証はうまく動作します)。もちろん、スタンドアロンプ​​ログラムも認証できることを覚えておいてください。

1

Safariはあなたのためのウェブブラウザですか?
これは、QT QWebKitライブラリを使用しているエンジンと同じエンジンで、多くのアプリケーションで使用できます。だから私は、それを認識する方法はないと言います。なぜあなたは、あなたが求めるものをしたいと思う:彼らは好きなの...

一つ質問UserAgentのようなヘッダを偽造 - 1が望んでいるすべての要求を偽造することができます

ユーザー?彼らがブラウザやanythningからリクエストした場合、あなたのための相違は何ですか?
ここで「セキュリティ」と呼ぶ理由の1つを考えることはできません。

何らかの理由でこれをやりたい場合は、ブラウザを埋め込んで独自のアプリケーションを作成することを検討してください。それは何とかすべてのリクエストでアプリケーションに何らかの認証をすることができます。そして、あなたはアプリケーションのブラウザに有効な応答を送るだけです。
ユーザーは依然としてアプリケーションをリバースエンジニアリングすることができます。

3

それは確か側のスクリプトは、スタンドアロンのプログラムを通じて来ていないと、ブラウザ

の上に座って、実際のユーザーによって何通りの方法がありますされていないサーバに要求することを行うのに良い方法は何ですか。ブラウザはスタンドアロンプ​​ログラムと区別できません。ブラウザを自動化することができます。

クライアント側からの入力を信頼できません。あなたがセキュリティ目的のためにクライアント側の協力に頼っているなら、あなたは破滅します。

0

前述のように、これを実現する方法はありません...しかし、特定のAJAX機能を対象としたCSRF攻撃を防止するのに役立つことがあります。 AJAXオブジェクトの助けを借りてカスタムヘッダーを設定し、サーバー側でそのヘッダーを確認するようにします。

そのヘッダーの値にランダム(1回限りの使用)トークンを設定すると、自動攻撃を防ぐことができます。

2

あなたが心配していることはわかりません。私が座っている場所から、あなたの質問が関係している3つの事柄を見ることができます:

まず、権限のないユーザーが有効な要求をしないようにすることができます。これは、ブラウザのクッキーを使用してセッションIDを格納することで解決されます。セッションIDは、ユーザーがログインプロセスを通過するたびに再生成される必要があり、非アクティブタイムアウトが必要です。誰もあなたが単に拒否する有効なセッションIDなしで入ってくるリクエストです。

第2に、サードパーティがあなたのサイトに対してリプレイ攻撃をしないようにすることができます(つまり、無実のユーザーのトラフィックを盗聴してから、同じ呼び出しを送信する)ことを避けることができます。簡単な解決策は、これをhttpsにすることです。 SSL層は、誰かがトラフィックの一部を再生するのを防ぎます。これはサーバー側のコストがかかりますので、本当にそのリスクを逃すことはできません。

第3に、自分のクライアントをサイトに実装するために、誰かがあなたのAPI(これはAJAXが最後に呼び出すもの)を使用しないようにすることができます。これにはあなたができることはほとんどありません。あなたはいつも適切なUser-Agentを探すことができますが、それは偽造するのが簡単で、おそらくAPIを使用しようとする誰かが考えることになります。統計情報を実装することができます。たとえば、ユーザーごとに平均AJAXリクエストを毎分見て、平均以上のユーザーがいるかどうかを確認できます。実装するのは難しく、自動化されたクライアントが人間よりも速く反応するのを防ぐのに役立つだけです。

3

「ブラウザ以外のユーザー」のリクエストをサーバー側のスクリプトに自動的にブロックする方法はありませんが、アプリケーションによってトリガーされたスクリプトと見つからないスクリプトを識別する方法があります。

これは、通常、「クラムス」と呼ばれるものを使用して行われます。基本的な考え方は、AJAXリクエストを作成するページがユニークなトークン(通常はunixタイムスタンプ+ salt + secretのハッシュ)を生成(サーバー側)する必要があるということです。このトークンとタイムスタンプは、AJAXリクエストへのパラメータとして渡す必要があります。 AJAXハンドラスクリプトは、最初にこのトークン(およびトークンタイムスタンプの5分以内にある場合など、UNIXのタイムスタンプの有効性)をチェックします。トークンがチェックアウトすると、この要求を実行することができます。通常、このトークン生成+チェックはApacheモジュールとしてコード化され、自動的にトリガされ、アプリケーションロジックとは別になります。

不正なスクリプトは、(アルゴリズムを解読しない限り)有効なトークンを生成することができないため、無視しても問題ありません。

トークンをセッションに格納することも別の方法ですが、サイトの認証システムよりもセキュリティを購入することはありません。

関連する問題