2008-08-26 160 views
172

JavaScriptは、Cookieに基づくアクセス制限のあるサイトでAJAXが使用されている場合、Cookieにアクセスする必要があります。 HttpOnly CookieはAJAXサイトで動作しますか?HttpOnly CookieはAJAXリクエストとどのように機能しますか?

編集: Microsoftは、HttpOnlyが指定されている場合、CookieへのJavaScriptアクセスを許可しないことによってXSS攻撃を防止する方法を作成しました。 FireFoxはこれを後で採用しました。だから私の質問は:StackOverflowのようなサイトでAJAXを使用している場合、Http-Only Cookieはオプションですか?

編集2:質問2のHttpOnlyの目的は、クッキーへのJavaScriptのアクセスを防止することであり、あなたはまだXMLHttpRequestオブジェクトを通じてJavaScriptでクッキーを取得できた場合は、HttpOnlyののポイントは何ですか?

編集3:

ブラウザは、このようなクッキーを受け取り、以下のHTTP交換にいつものようにそれを使用することになっているが、それが見えるようにしない:ここでははウィキペディアからの引用ですクライアント側のスクリプトに適用されます。[32] HttpOnlyフラグは標準の一部ではなく、すべてのブラウザで実装されているわけではありません。現在、XMLHTTPRequestを介してセッションクッキーを読み書きすることはできません。 [33]。

私は、HttpOnlyを使用するとdocument.cookieがブロックされていることを理解しています。しかし、XMLHttpRequestオブジェクトのクッキー値を読み取ることができ、XSSを使用できるようです。 HttpOnlyはあなたをどのように安全にするのですか?クッキーを基本的に読み取り専用にすることによって?

あなたの例では、あなたのdocument.cookieに書き込むことはできませんが、私はあなたのクッキーを盗んで、私のドメインにXMLHttpRequestオブジェクトを使って投稿することができます。

<script type="text/javascript"> 
    var req = null; 
    try { req = new XMLHttpRequest(); } catch(e) {} 
    if (!req) try { req = new ActiveXObject("Msxml2.XMLHTTP"); } catch(e) {} 
    if (!req) try { req = new ActiveXObject("Microsoft.XMLHTTP"); } catch(e) {} 
    req.open('GET', 'http://stackoverflow.com/', false); 
    req.send(null); 
    alert(req.getAllResponseHeaders()); 
</script> 

編集4:申し訳ありませんが、私はあなたがStackOverflowのドメインへのXMLHttpRequestを送信し、その後、正規表現アウトCookie、文字列に)(getAllResponseHeadersの結果を保存し、その後にそれを投稿できることを意味し外部ドメイン。明らかに両方のサイトが間違っている、これは実際にbug in FireFoxあるああ、:Wikipediaとha.ckersはこの1つに私と一緒に同意することが表示されますが、私は再教育を受け...

決勝を編集することが大好きです。 IE6 & 7は実際には現在、HttpOnlyを完全にサポートしている唯一のブラウザです。私が学んだすべて繰り返しに

  • HttpOnlyのは、IE7 &でdocument.cookieへのすべてのアクセスを制限し、FireFoxの(他のブラウザについてはよく分からない)
  • HttpOnlyのは、中にレスポンスヘッダからクッキー情報を削除しますIE7のXMLHttpObject.getAllResponseHeaders()
  • XMLHttpObjectsは、元のドメインにのみ送信できるため、クッキーのクロスドメイン投稿はありません。

編集:この情報はおそらく最新ではありません。

+0

私はgreasemonkeyスクリプトにあなたの例題を投げましたが、FFはクッキーを表示しなくなったようです。優れた研究と事例。 –

+0

同じ原点ポリシーでは、スクリプトが実行されていないドメインに対してhttp要求を行うことはできません。しかし、私はあなたがwindow.locationを使用しているページにユーザーをリダイレクトし、クエリ文字列パラメータを介して情報を渡すことによって簡単にクッキーを渡すことができると確信しています。 –

答えて

3

必ずしもあなたがしたいことに依存します。少し詳しく説明できますか? AJAXは動作するためにクッキーにアクセスする必要はなく、情報を抽出するためにリクエストを独自に行うことができます.AJAX呼び出しが行うページリクエストはクッキーデータにアクセスできます& Javascriptに直接アクセスすることなく、クッキー

0

いいえ、あなたがログインしているかどうかをチェックするものだAJAX呼び出し要求があまりにも&をクッキーへのアクセス権を持っていることページ。

あなたはJavaScriptを使用して他の認証を行うことができますが、私はそれを信用しないだろう私はいつもバックエンドに何らかの認証チェックを入れることを好みます。

1

クッキーは、AJAX呼び出し時に自動的にブラウザで処理されるため、Javascriptでクッキーを使用する必要はありません。

1

したがって、私はJavaScriptがあなたのクッキーにアクセスする必要があると仮定しています。

ブラウザからのすべてのHTTPリクエストが、問題のサイトのCookie情報を送信します。 JavaScriptはCookieの設定と読み取りの両方を行うことができます。 CookieはAjaxアプリケーションでは定義されていませんが、ほとんどのWebアプリケーションではユーザー状態を維持するために必要です。

「AJAXを使用する場合、JavaScriptはCookieにアクセスする必要がありますか? - したがって、「いいえ」である。たとえば、Ajaxリクエストを使って自動提案オプションを提供する拡張検索フィールドを考えてみましょう。その場合、クッキー情報は必要ありません。

+0

XmlHttpRequestにはCookieが必要です。あなたが言及した拡張検索は、ログインページの後ろにあるかもしれません。しかし、JavascriptがVMにCookieの値を公開できる必要があるかどうかは、別の質問です。 –

1

明らかに、サーバーの観点から見ると、AJAXリクエストによって要求されるページは、ユーザーがリンクをクリックすることによって行われる標準的なHTTP取得要求と基本的に変わりません。すべての通常のリクエストプロパティ:user-agent、ip、session、cookiesなどがサーバーに渡されます。

55

はい、HTTP専用Cookieはこの機能には問題ありません。彼らはまだXmlHttpRequestの要求をサーバーに提供されます。

スタックオーバーフローの場合、CookieはXmlHttpRequest要求の一部として自動的に提供されます。 Stack Overflow認証プロバイダの実装の詳細はわかりませんが、そのCookieデータは自動的に "投票"コントローラメソッドよりも低いレベルでIDを確認するために使用されます。

より一般的には、AJAXにはでなく、が必要です。 XmlHttpRequestのサポート(古いブラウザではiframe remotingさえも)は、技術的に必要なすべてです。

ただし、AJAX対応の機能にセキュリティを提供する場合は、従来のサイトと同じ規則が適用されます。各リクエストの背後にあるユーザーを特定するための方法が必要であり、ほとんどの場合、Cookieはその目的のための手段です。

あなたの例では、私はあなたのdocument.cookieに書き込むことはできませんが、あなたのクッキーを盗んで、私のドメインにXMLHttpRequestオブジェクトを使って投稿することはできます。

XmlHttpRequestは、(あなたが触れている正確な種類の理由で)クロスドメイン要求を行いません。

通常、iframe remotingまたはJSONPを使用してドメインにCookieを送信するためのスクリプトを挿入できますが、アクセスできないのでHTTP-OnlyでCookieを再度保護します。

サーバー側でStackOverflow.comを侵害していない限り、自分のCookieを盗むことはできません。

編集2:HTTP-のみの目的は、クッキーへのJavaScriptのアクセスを防止することであり、あなたはまだXMLHttpRequestオブジェクトを通じてJavaScriptでクッキーを取得できた場合は質問2は、HTTP-だけのポイントは何ですか?

は、このシナリオを考えてみましょう:

  • 私はページにJavaScriptコードを注入する道を見つけます。
  • Jeffがページを読み込み、悪意のあるJavaScriptが自分のCookieを変更して自分と一致するようにします。
  • Jeffはあなたの質問に恒例の答えを提出します。
  • 彼は彼の代わりに私のクッキーデータを提出するので、答えは私のものになります。
  • あなたは「私の」恒星の答えに投票します。
  • 私の実際のアカウントは、ポイントを取得します。 HTTPのみクッキーで

、第二段階は、それによって私のXSSの試みを破り、不可能であろう。

編集4:申し訳ありませんが、私はあなたがStackOverflowのドメインへのXMLHttpRequestを送信し、その後、文字列にgetAllResponseHeaders()の結果を保存するクッキーからregexで、その後、外部のドメインにそれを投稿できることを意味し。 Wikipediaとha.ckersは私と同意見ですが、私は再教育が大好きです...

これは間違いありません。あなたはその方法でセッションをハイジャックすることができます。 XSSのハッキングを成功させることができる人たちの集団を大幅に薄くします。

しかし、私のシナリオに戻ると、HTTP-がクライアントのCookieの変更に依存する(珍しいことではない)XSS攻撃を正常に遮断する場所を確認できます。

それはa)は、単一の改善がすべての脆弱性を解決しないだろうと、b)は、システムがこれまでは完全に安全ではないという事実に帰着します。 HTTP-です。これはXSSに対して有効なツールです。

同様に、XmlHttpRequestのクロスドメイン制限がすべてのXSSエクスプロイトの防止に100%成功していない場合でも、制限を削除することは決してありません。

+0

多くのフレームワークは 'csrf' [トークンをクッキーに入れます](http://stackoverflow.com/q/20504846/781695)。私はJSがそれを取得するために隠されたHTML要素にcsrfトークンを置かない限り、 'csrf'チェックを必要とするAJAX呼び出しは動作しないと思います。 – Medorator

2

はい、Ajaxベースのサイトで実行可能なオプションです。認証クッキーは、スクリプトによる操作のためのものではなく、単にサーバーに行われたすべてのHTTP要求にブラウザーによって含まれています。

スクリプトは、セッションクッキーが何を言うか心配する必要はありません。認証されている限り、ユーザーまたはスクリプトによって開始されたサーバーへの要求には、適切なCookieが含まれます。スクリプトがクッキーの内容を知ることができないという事実は重要ではない。

認証以外の目的で使用されるCookieの場合、スクリプトでこれらを変更または読み取ることができるようにするには、HTTP専用フラグを設定せずにこれらを設定できます。どのCookieをHTTPだけにするかを選択して選択することができます。たとえば、UIの設定(ソート順、左手枠の折りたたみの有無など)のような重要なものは、Cookieでスクリプトと共有できます。

私は本当にHTTPのみのクッキーが好きです。これは本当にきれいなアイデアだった独自のブラウザ拡張の1つです。

0

はい、CookieはAjaxにとって非常に便利です。

リクエストURLに認証を入れるのは悪い習慣です。先週、GoogleのキャッシュからURLの認証トークンを取得するというニュース項目がありました。

いいえ、攻撃を防ぐ方法はありません。古いブラウザでは、まだjavascriptを使用してクッキーに簡単にアクセスできます。あなたはhttpだけをバイパスすることができます。あなたが何を思いついても、十分な努力が与えられたときに得られます。そのトリックは、価値のあるものにするためにあまりにも多くの努力をすることです。

サイトをより安全にしたい場合(完全なセキュリティはありません)、期限切れの認証Cookieを使用できます。次に、クッキーが盗まれた場合、攻撃者はクッキーが期限切れになる前にそれを使用しなければなりません。彼らがそうしなければ、あなたはそのアカウントに疑わしい活動があることを知っています。タイムウィンドウが短ければ短いほどセキュリティは向上しますが、サーバーに負荷をかけてキーを生成して保守する負荷が増えます。

2

もう少しです。

Ajaxは厳密にクッキーを必要としませんが、他のポスターと同様に有用です。 Cookie HTTPOnlyをスクリプトから非表示にすると、すべてのブラウザでサポートされているわけではなく、一般的な回避策があるため、部分的にしか機能しません。

XMLHTTPレスポンスヘッダがクッキーを与えているのは奇妙です。技術的には、サーバはレスポンスとともにクッキーを返す必要はありません。クライアントに設定されると、期限が切れるまで設定されたままになります。再使用を防ぐためにCookieが変更されるというスキームがありますが、そのため、XMLHTTPレスポンスにCookieを指定しないようにサーバーを変更することで回避策を回避できます。

一般的には、HTTPOnlyを注意して使用する必要があります。攻撃者がXMLHTTPを使用せずに単純なポストフォームを使用して別のサイトから発信されたajaxのようなリクエストを送信するようにアタッカーが調整し、ブラウザの依然としてアクティブなクッキーがリクエストを認証するというクロスサイトスクリプティング攻撃があります。

AJAXリクエストが確実に認証されるようにするには、リクエスト自体とHTTPヘッダーにCookieを含める必要があります。たとえば、スクリプトや独自の隠れた入力を使用します。 HTTPOnlyはそれを妨げるでしょう。

通常、HTTPOnlyがあなたのウェブページに含まれるサードパーティのコンテンツがCookieを盗み出すのを防ぐための興味深い理由があります。しかし、第三者のコンテンツを含めることに非常に慎重で、積極的にフィルタリングする興味深い理由がたくさんあります。

関連する問題