6

Javascriptでは、C ++の場合のように、オブジェクトにプライベートデータやメソッドを与えることはできません。ああ、まあ、実際には、そうです、閉鎖を含むいくつかの回避策を介して。しかし、Pythonのバックグラウンドから来た私は、「プライバシーのふり」（命名規則とドキュメントによる）で十分であるか、「プライバシーの強制」（Javascript自体によって強制される）よりも好ましいと思う傾向があります。確かに、これが真実ではない状況を考えることができます-たとえば、人々はRTFMなしで私のコードとインターフェースしますが、私は非難されます-しかし、私はその状況ではありません。

しかし、何かが私に一時停止を与えます。Javascriptの第一人者であるDouglasCrockfordは、「Javascript：The Good Parts」などで、偽のプライバシーを「セキュリティ」の問題として繰り返し言及しています。たとえば、「攻撃者は簡単にフィールドに直接アクセスして、メソッドを自分のものに置き換えることができます」。

私はこれに混乱しています。最小限のセキュリティ慣行（ブラウザからサーバーに送信されたデータを検証し、盲目的に信頼しないでください。サイトにサードパーティのスクリプトを検査せずに含めないでください）に従うと、次のような状況は発生しないようです。ふり-プライバシーは、強制されたプライバシーよりも「安全」ではありません。そうですか？そうでない場合、ふりプライバシーと強制プライバシーがセキュリティに影響を与える状況はどのようなものですか？

4

2 に答える 2

1

それ自体ではありません。ただし、Crockford 氏が指摘しているように、信頼できない JavaScript コードを HTML ドキュメントに安全にロードできないことを意味します。このような信頼できない JavaScript コードをブラウザーで実行する必要がある場合 (ソーシャル ネットワーキング サイトでユーザーが送信したウィジェットなど) は、iframe サンドボックスを検討してください。

Web 開発者としてのセキュリティ上の問題は、多くの場合、主要なインターネット広告ブローカーが広告コードのフレーミングをサポートしていない (または禁止さえしている) ことです。残念ながら、Google が悪意のある JavaScript を意図的であろうとなかろうと (ハッキングされるなど)配信しないことを信頼する必要があります。

別の質問への回答として投稿した iframe サンドボックスの簡単な説明を次に示します。

ユーザーが送信した HTML、CSS、および JavaScript専用の完全に別のドメイン名 (例: 「exampleusercontent.com」)を設定します。このコンテンツがメイン ドメイン名を介して読み込まれることを許可しないでください。次に、iframe を使用してページにユーザー コンテンツを埋め込みます。

単純なフレーミングよりも緊密な統合が必要な場合はwindow.postMessage()、異なるフレーム内のスクリプトが制御された方法で相互に通信できるようにすることが役立つ場合があります。

于 2013-01-13T15:10:30.773 に答える
0

答えは「いいえ、偽のプライバシーは問題ありません」のようです。ここにいくつかの詳細があります：

  • 現在存在する JavaScript では、未知の信頼できないサードパーティのスクリプトを Web ページに含めることはできません。それは大混乱を引き起こす可能性があります: ページ上のすべての HTML を書き換えたり、ユーザーにパスワードの入力を求めたり、それを悪意のあるサーバーに送信したりできます。Javascript コーディング スタイルは、この基本的な事実に違いはありません。これに対処する方法については、PleaseStand の回答を参照してください。

  • 悪意はないが無能なスクリプトは、名前の競合によって意図せずに混乱を招く可能性があります。これは、一般的な名前を持つ多数のグローバル変数を作成することに対する良い議論ですが、偽のプライベート変数を避けるかどうかとは何の関係もありません。たとえば、私のバナナ販売 Web サイトでは、fake-private 変数を使用する場合がありますwindow.BANANA_STORE_MODULE.cart.__cart_item_array。この変数がサードパーティのスクリプトによって誤って上書きされる可能性は完全にありませんが、非常にまれです。

  • 信頼されていないコードが所定の方法で動作できる制御された環境を提供する javascriptの将来の変更についてのアイデアが浮かんでいます。信頼できないサードパーティの JavaScript が特定の公開されたメソッドを介して自分の JavaScript と対話できるようにし、サードパーティのスクリプトが HTML にアクセスするのをブロックすることができます。これが存在する場合、プライベート変数がセキュリティに不可欠なシナリオである可能性があります。しかし、それはまだ存在しません。

  • 明確でバグのないコードを書くことは、明らかに、常にセキュリティに役立ちます。真にプライベートな変数とメソッドを使用すると、明確でバグのないコードを簡単に記述したり難しくしたりできますが、セキュリティへの影響はあります。それらが役立つかどうかは、常に議論と好みの問題であり、たとえば、バックグラウンドが C++ (プライベート変数が中心である) か Python (プライベート変数が存在しない) かどうかです。有名なブログ投稿Javascript Private Variables are Evilなど、両方向の議論があります。

私としては、偽のプライバシーを使用し続けます: 先頭のアンダースコア (または何でも) は、一部のプロパティまたはメソッドがモジュールの公的にサポートされているインターフェイスの一部ではないことを私自身と私の共同研究者に示します。私のフェイク プライバシー コードは読みやすく (IMO)、構造化の自由度も高く (たとえば、クロージャーは 2 つのファイルにまたがることはできません)、デバッグや実験中にこれらのフェイク プライベート変数にアクセスできます。これらのプログラムが他の JavaScript プログラムよりも安全ではないことを心配するつもりはありません。

于 2013-02-06T19:34:13.773 に答える