11

Ember.js私は実際のプロジェクトで使い始めることを楽しみにしていますが、Java のバックグラウンドを持っている人として、私は常にセキュリティを気にかけています。

そして、仲間の Java 開発者に、私が JavaScript MVC を使い始めたと言うと、彼らは安全性が十分ではないと言い始めました。サービスと API。

では、この種の攻撃を防ぐのに役立つ、または少なくとも効果を弱めようとする良い方法はありますか?

4

1 に答える 1

38

JavaScript コードをハッキングして、サービスや API へのバックドアを知る方法は常にあります。

JavaScript は、既に Web に公開されているサービスや API に新しい問題をもたらすことはほとんどありません。サーバー/サービスは Web からの要求を盲目的に信頼すべきではありません。そのため、javascript を使用してもセキュリティ体制は変わりませんが、ユーザー エージェントを制御していると思わせることで、人々を誤った安心感に陥らせる可能性があります。

クライアント/サーバー セキュリティの基本的なルールは同じです。ユーザー エージェントを信頼しないでください。サーバーとクライアントを信頼境界の異なる側に配置します。

信頼境界は、プログラムを通る線と考えることができます。一方では、データは信頼されていません。反対に、データは信頼できるものと見なされます。検証ロジックの目的は、データが安全に信頼境界を越えられるようにすることです。つまり、信頼されていない状態から信頼されている状態に移行できるようにすることです。

サーバーがクライアントから受信するすべてのものを検証し、XSS の脆弱性が一般的であり、クライアントに送信された情報にクライアントがアクセスできるようにするため、クライアントに送信する機密情報はできるだけ少なくします。

サーバーとクライアントの間でデータをやり取りする必要がある場合は、さまざまな手法を使用できます。

  1. サーバーが改ざんされていないことを確認できるように、データに暗号署名します。
  2. データをサイドテーブルに保存し、不透明で推測不可能な識別子のみを送信します。

機密データをクライアントに送信する必要がある場合、さまざまな戦略もあります。

  1. リクエストに添付されるが JavaScript では読み取れない HTTP のみの Cookie にデータを保存する
  2. クライアントを別のオリジンの iframe に分割し、慎重にレビューされ、余分な機能が最小限に抑えられた iframe に機密情報を隔離します。

署名

署名は、信頼できないソースから受け取ったデータが以前に検証したデータであることを検証するという問題を解決します。盗聴の問題 (暗号化が必要なため) や、クライアントがデータを返さないことを決定したり、同じ鍵で署名された別のデータに置き換えることを決定したりする問題は解決しません。

「パススルー」データの暗号署名については、Djangoのドキュメントで詳しく説明されており、API の使用方法についても概説されています。

Web アプリケーション セキュリティの黄金律は、信頼できないソースからのデータを決して信頼しないことです。信頼できないメディアを介してデータを渡すと便利な場合があります。暗号化された値は、改ざんが検出されることを認識して、信頼されていないチャネルを安全に通過できます。

Django は、値に署名するための低レベル API と、Web アプリケーションでの署名の最も一般的な用途の 1 つである署名付き Cookie を設定および読み取るための高レベル API の両方を提供します。

署名は、次の場合にも役立ちます。

  1. パスワードを紛失したユーザーに送信する「アカウントの回復」URL の生成。
  2. 非表示のフォーム フィールドに格納されたデータが改ざんされていないことを確認します。
  3. ユーザーが支払ったダウンロード可能なファイルなど、保護されたリソースへの一時的なアクセスを許可するためのワンタイム シークレット URL の生成。

不透明な識別子

不透明な識別子とサイド テーブルは署名と同じ問題を解決しますが、サーバー側のストレージが必要であり、データを格納したマシンが識別子を受け取るマシンと同じ DB にアクセスできる必要があります。

不透明で推測不可能な識別子を持つサイドテーブルは、この図を見ると簡単に理解できます

     Server DB Table

+--------------------+---------------------+
| Opaque Primary Key | Sensitive Info      |
+--------------------+---------------------+
| ZXu4288a37b29AA084 | The king is a fink! |
| ...                | ...                 |
+--------------------+---------------------+

ランダムまたは安全な疑似乱数ジェネレーターを使用してキーを生成し、キーをクライアントに送信します。

クライアントがキーを持っている場合、クライアントが知っているのは、乱数を持っていることと、おそらくそれがあなたから受け取った他の乱数と同じであることだけですが、そこからコンテンツを取得することはできません.

それらが改ざんされた (別のキーを送り返した) 場合、それは (非常に高い可能性で) テーブルに含まれないため、改ざんが検出されます。

複数のキーを同じ動作の悪いクライアントに送信した場合、もちろん、1 つを別のクライアントに置き換えることができます。

HTTP のみの Cookie

誤って他のユーザー エージェントに漏洩させたくないユーザー エージェントごとのシークレットを送信する場合は、HTTP のみの Cookie が適切なオプションです。

HttpOnly フラグ (オプション) が HTTP 応答ヘッダーに含まれている場合、クライアント側のスクリプトを介して Cookie にアクセスすることはできません (ブラウザーがこのフラグをサポートしている場合)。その結果、クロスサイト スクリプティング (XSS) の欠陥が存在し、ユーザーがこの欠陥を悪用するリンクに誤ってアクセスした場合でも、ブラウザー (主に Internet Explorer) は Cookie を第三者に開示しません。

HttpOnly Cookie は、最新のブラウザーで広くサポートされています。

隔離された iframe

アプリケーションを複数の iframe に分割することは、偶発的な漏洩のリスクを最小限に抑えながら、リッチ クライアントが機密データを操作できるようにするための現在の最良の方法です。

基本的な考え方は、大きなプログラム内に小さなプログラム (セキュア カーネル) を配置して、セキュリティに敏感なコードをプログラム全体よりも注意深くレビューできるようにすることです。これは、qmail の協力して疑わしいプロセスが機能したのと同じ方法です。

セキュリティ パターン: 区画化 [VM02]

問題

システムの一部でセキュリティ障害が発生すると、システムの別の部分が悪用される可能性があります。

解決

各部分を個別のセキュリティ ドメインに配置します。一部のセキュリティが侵害された場合でも、他の部分のセキュリティは維持されます。

「HTML5 方式のフレーム間通信」では、iframe がどのように通信できるかを説明しています。それらは異なるドメインにあるため、セキュリティに敏感な iframe は、他のドメインのコードがこれらの狭いチャネルを介してのみ通信できることを認識しています。

HTML を使用すると、ある Web ページを別の Web ページ内 (要素内) に埋め込むことができます。それらは本質的に分離されたままです。コンテナー Web サイトは Web サーバーとの通信のみが許可され、iframe は元のサーバーとの通信のみが許可されます。さらに、それらは異なるオリジンを持っているため、ブラウザーは 2 つのフレーム間の接触を許可しません。これには、関数呼び出しと変数アクセスが含まれます。

しかし、2 つの別々のウィンドウの間にデータを取得したい場合はどうすればよいでしょうか。たとえば、zwibbler ドキュメントは、文字列に変換すると 1 メガバイトの長さになる場合があります。含まれている Web ページが必要なときにその文字列のコピーを取得できるようにして、保存できるようにしたいと考えています。また、ユーザーが作成した保存済みの PDF、PNG、または SVG 画像にアクセスできる必要があります。HTML5 は、window.postMessage() と呼ばれる、同じウィンドウの異なるフレーム間で通信する制限付きの方法を提供します。

これで、セキュリティに敏感なフレームは、標準的な検証手法を使用して、(侵害された可能性がある) 機密性の低いフレームからデータを精査できます。

大規模なプログラマー グループで優れたアプリケーションを効率的に作成し、より小さなグループで機密データが適切に処理されるようにすることができます。

いくつかの欠点:

  1. 単一の「ロード」イベントがないため、アプリケーションの起動はより複雑になります。
  2. iframe 通信では、解析する必要がある文字列を渡す必要があるため、セキュリティに敏感なフレームでは、引き続き安全な解析方法を使用する必要があります ( evalpostMessage の文字列ではありません)。
  3. iframe は長方形であるため、セキュリティに配慮したフレームで UI を表示する必要がある場合、大きなアプリケーションの UI にうまく収まらない可能性があります。
于 2013-03-01T22:46:04.063 に答える