🤷🏻 ✍️ 🤾🏽 Meteorだけでなくセキュリティについて（パート2） 🎰 💨 🐂

最初の部分で怖がらなかった場合は、Meteorのセキュリティメカニズムに関する議論を続けることを提案します。クライアントに発行されたloginTokenから始めて、クライアントでデータベースを変更する際にルールを許可/拒否します。HTTPSおよびforce-ssl パッケージ、browser-policyパッケージ（コンテンツセキュリティポリシーおよびX-Frame-Options）を使用して、そして、組み込みのデータ検証メカニズム（check（）関数とaudit-arguments-checkパッケージ）で終わります。

loginToken

承認後、クライアントは現在のユーザーを承認する一時トークンを受け取り、localStorageに保存されます。

> localStorage.getItem("Meteor.loginToken") "eEg4T3fNPGLns7MfY"

厳密に言えば、それはMeteor._locaStorageオブジェクトに格納されます。これは、それをサポートするブラウザーのwindow.localStorageのラッパーです。

Accountsオブジェクトを使用してこのトークンを見つけることもできます。

 Accounts._storedLoginToken()

同じトークンがサーバーのMeteor.usersコレクションに保存されます。

 > Meteor.user().services.resume { "loginTokens": [ { "token":"DXC3BqekpPy97fmYs", "when":"2014-01-31T10:53:54.347Z" } ] }

もちろん、ブラウザコンソールでは、このフィールドは明示的に公開されている場合にのみ使用できます。

トークンとユーザーIDのペアを持つブラウザーは、許可されていると見なされます。これを確認するには、ブラウザーにログインして、現在のloginTokenとuserIdを取得します。

 localStorage.getItem("Meteor.loginToken"); localStorage.getItem("Meteor.userId");

次に、それらを別のブラウザーにインストールします。

 localStorage.setItem("Meteor.loginToken", "'+loginToken+'"); localStorage.setItem("Meteor.userId", "'+userId+'");

しばらくすると、ブラウザセッションが承認されます。

トークンの寿命

トークンは、ユーザーがログアウトするか、パラメーターで指定されたタイムアウトが期限切れになるまで存在します（デフォルトは60日です）。

 Accounts.config({loginExpirationInDays: 60})

コレクションを変更するためのクライアント特権の制限-ルールの許可 / 拒否

サービスサブドキュメントを変更しようとすると、ブラウザからこれを行うことができません。

 > Meteor.users.update({ _id: Meteor.userId() }, {$set: { "services.test": "test" } }) undefined update failed: Access denied

これは、サーバー上のこのドキュメントへのアクセスが許可 / 拒否ルールによって制限されているために発生します。 accounts-baseパッケージソースでこのメカニズムがどのように実装されているかを見てみましょう。

 Meteor.users.allow({ // clients can modify the profile field of their own document, and // nothing else. update: function (userId, user, fields, modifier) { // make sure it is our record if (user._id !== userId) return false; // user can only modify the 'profile' field. sets to multiple // sub-keys (eg profile.foo and profile.bar) are merged into entry // in the fields list. if (fields.length !== 1 || fields[0] !== 'profile') return false; return true; }, fetch: ['_id'] // we only look at _id. });

コードから、userIdが現在のユーザーと一致するドキュメントへの変更のみが許可され、プロファイルサブドキュメントのみを変更できることがわかります。 fetchパラメーターは、Meteorに、アクセス許可を確認するために、変更されたドキュメント全体を受信する必要はなく（大きい場合もある）、1つの_idフィールドだけで十分であることを伝えます。ルールallowは更新操作に対してのみ宣言されているため、クライアントの挿入および削除操作は禁止されています。

 > Meteor.users.insert({}) "qs8HbcSDjgbgb3vgS" insert failed: Access denied. No allow validators set on restricted collection for method 'insert'.

拒否ルールにより、allowで許可された操作を禁止できます。つまり、許可ルールの1つ（複数のルールを設定できる）がtrueを返す場合、拒否ルールの1つがtrueを返すと、この許可はオーバーライドされる可能性があります。この場合、許可ルールにもかかわらず記録は拒否されます。

サブドキュメントのアクセス権を確認する

更新操作では、検証オプションが多少制限されます。たとえば、サブドキュメントのフィールド（たとえばdoc.field1）への書き込みを禁止する必要があるが、別のフィールド（たとえば、コレクションテストのdoc.field2）に入れることを許可する必要がある場合、機能しません。この場合、ルールに入力される許可および拒否の出力をサーバーに追加して、どのパラメーターがルールに渡されるのかを見てみましょう。

 Test.allow({ update: function (userId, document, fields, modifier) { console.log('Test.allow(): userId:', userId, '; document:', document, '; fields:', fields, '; modifier:' , modifier); return true; } }); Test.deny({ update: function (userId, document, fields, modifier) { console.log('Test.deny(): userId:', userId, '; document:', document, '; fields:', fields, '; modifier:' , modifier); return false; } });

そして、ドキュメントの1つの_idを以前に認識して、doc.field1フィールドの更新操作を実行します（この例のコードでプロジェクション= {}変数を設定することで、テストコレクションに必要なフィールドが公開されていることを確認してください、そうでない場合、結果は表示されません）：

 > Test.findOne({_id: "FG7FaQqYgB7Rs9RDy"}) Object {_id: "FG7FaQqYgB7Rs9RDy", name: "First", value: 1} > Test.update({_id:"FG7FaQqYgB7Rs9RDy"}, { $set: { "doc.field1": "value1" } } ) undefined > Test.findOne({_id: "FG7FaQqYgB7Rs9RDy"}) Object {_id: "FG7FaQqYgB7Rs9RDy", name: "First", value: 1, doc: Object} > Test.findOne({_id: "FG7FaQqYgB7Rs9RDy"}).doc.field1 "value1"

サーバーログには次が表示されます。

 I20140131-13:31:27.582(4)? Test.deny(): userId: kL7Fkuk29ci4vz8q4 ; document: { _id: 'FG7FaQqYgB7Rs9RDy', name: 'First', value: 1 } ; fields: [ 'doc' ] ; modifier: { '$set': { 'doc.field1': 'value1' } } I20140131-13:31:27.582(4)? Test.allow(): userId: kL7Fkuk29ci4vz8q4 ; document: { _id: 'FG7FaQqYgB7Rs9RDy', name: 'First', value: 1 } ; fields: [ 'doc' ] ; modifier: { '$set': { 'doc.field1': 'value1' } }

fieldsパラメーターでは、最上位レベルのフィールドのパッシブのみが渡されます。つまり、それに基づいて、docフィールド（およびそのすべてのサブドキュメント）へのアクセス権を決定できますが、この配列に基づいてdoc.field1およびdoc.fieldフィールドに異なる権限を適用することはできません。これを行うには、MongoDb操作を含むオブジェクトが渡される修飾子パラメーターを使用できます。操作の完全な分析を行わないために、何らかのハードフォーマットのみを許可し、他のすべてのオプションを何らかの方法で禁止します。

 Test.allow({ update: function (userId, user, fields, modifier) { console.log('Test.allow(): userId:', userId, '; document:', document, '; fields:', fields, '; modifier:' , modifier); var setData = modifier["$set"]; return setData && Object.keys(setData).length===1 && setData["doc.field1"]; } });

もちろん、許可 / 拒否ルールは、安全でないパッケージがプロジェクトから削除された場合にのみ機能します。ところで、これらのハンドラーは、クライアントによるサーバー側の変更にも使用できます。

信頼できるコードと信頼できないコード

これまで、識別子によってレコードを変更しました。実際には、クライアントは更新操作を実行できず、要求セレクターで何か他のものを示します。たとえば、

 Test.update({ value: 1 }, { $set: { "doc.field1": "value1" } } ) Error: Not permitted. Untrusted code may only update documents by ID. [403]

これは、Meteorが信頼できるコードと信頼できないコードを分離しているという事実によるものです。クライアントで呼び出されるサーバーメソッドを含むサーバーで実行されるコードは、信頼できると見なされます。信頼できない-ブラウザのクライアント側で実行されるコード。

信頼されていないコードは、ドキュメントの_idを示し、許可/拒否ルールを確認して、ドキュメントを一度に1つだけ変更できます。また、アップサート操作（ドキュメントがない場合は挿入）も許可されません。同じ方法での削除操作は、_idが指定された単一のドキュメントにのみ適用できます。詳細については、 docs.meteor.com / ＃ updateおよびdocs.meteor.com/#removeのドキュメントを参照してください。

サーバーメソッド

クライアントがデータベースに直接アクセスする代わりに、サーバー側の方法を使用できます。サーバーで実行されるコードは信頼できると見なされるため、重要な操作のロジックをサーバーに配置して、クライアント上の対応するコレクションへの変更を禁止することができます。たとえば、サーバーに追加します。

 Meteor.startup(function() { Meteor.methods({ testMethod: function(data) { console.log('testMethod(): data:', data); return 'testMethod finished (data:',data,')'; } }); });

そして、メソッドが完了したときに呼び出される最後のパラメーターコールバックを渡して、クライアント側から呼び出します。

 > Meteor.call('testMethod', 'test data', function(err, result) {console.log(err, result);}) undefined undefined "testMethod finished (data:test data)"

HTTPSおよびforce-sslパッケージ

Meteor自体にはHTTPSサポートが含まれておらず、証明書をホストするSSLを終了する中間サーバーが必要です。組み込みのforce-sslパッケージを使用すると、localhostからの接続を除き、HTTP接続をHTTPS URLにリダイレクトできます。

Nginxを使用する場合、リダイレクトは次のように実装できるため、このパッケージは必要ありません。

（localhost上のNginxをMeteorのプロキシとして設定する例（自己署名証明書の生成を含む））

キーと証明書を生成する

 $ openssl genrsa -des3 -out localhost.key 1024 $ openssl req -new -key localhost.key -out localhost.csr Common Name (eg, YOUR name) :localhost $ openssl x509 -req -days 1024 -in localhost.csr -signkey localhost.key -out localhost.crt

証明書とキーを/ etc / nginx / sslフォルダーにコピーします

 $ mkdir /etc/nginx/ssl $ cp ./localhost.key /etc/nginx/ssl $ cp ./localhost.crt /etc/nginx/ssl

Nginx設定

ファイル/etc/nginx/sites-available/meteor.confを作成します（Nginxを「ゼロから」インストールする場合、同じポートが登録されている同じディレクトリにあるデフォルトファイルを削除または再構成する必要があります）。

 server { listen 80; server_name localhost; # $scheme will get the http protocol # and 301 is best practice for tablet, phone, desktop and seo # return 301 $scheme://example.com$request_uri; # We want to redirect people to the https site when they come to the http site. return 301 https://localhost$request_uri; } server { listen 443; server_name localhost; client_max_body_size 500M; access_log /var/log/nginx/meteorapp.access.log; error_log /var/log/nginx/meteorapp.error.log; location / { proxy_pass http://localhost:3000; proxy_set_header X-Real-IP $remote_addr; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; } ssl on; ssl_certificate /etc/nginx/ssl/localhost.crt; ssl_certificate_key /etc/nginx/ssl/localhost.key; ssl_verify_depth 3; }

リンクを作成：

 ln -s /etc/nginx/sites-available/meteor.conf /etc/nginx/sites-enabled/meteor.conf

Nginxを再起動します。

 $ sudo service nginx restart

ブラウザポリシー、コンテンツセキュリティポリシー、およびX-Frame-Optionsパッケージ

実際、その他の2つのパッケージはbrowser-policyの背後に隠されており、それぞれがbrowser-policy-contentとbrowser-policy-framingの別々に使用できます。これらの最初のものは、さまざまなタイプのリソースをロードするためのソースのホワイトリストが指定されるコンテンツセキュリティポリシールールを定義するためのインターフェイスを提供します。 2つ目はX-Frame-Originパラメーターで、これを実行しようとしているサイトのURIに応じて、フレームまたはiframeタグ内にページを表示できます（現時点では、X-Frame-OriginでソースURIを指定することはFirefoxおよびIE 8以降でのみサポートされています）。

パッケージの追加にはデフォルトのポリシーが含まれますが、コンテンツのダウンロードはページ自体と同じサイトからのみ許可されますが、XMLHTTPRequestリクエストとWebSocket接続はどのサイトにも送信できます。さらに、eval（）などの機能はブロックされ、アプリケーションは、ダウンロード元と同じサイトでのみフレームおよびiframeに含めることができます。

同時に、ページが読み込まれると、サーバーの応答ヘッダーに次のパラメーターが追加されます。

 content-security-policy: default-src 'self'; script-src 'self' 'unsafe-inline'; connect-src * 'self'; img-src data: 'self'; style-src 'self' 'unsafe-inline'; x-frame-options: SAMEORIGIN

また、この例では、外部サイト（GoogleおよびFacebook）からのユーザー画像は、コンソールに次のメッセージとともに表示されなくなります。

 Refused to load the image 'https://lh6.googleusercontent.com/-aCxpjiDMNcM/AAAAAAAAAAI/AAAAAAAAJMY/9hZytqLLZ6Q/photo.jpg' because it violates the following Content Security Policy directive: "img-src data: 'self'".

外部サイトからの画像が再び表示されるようにするには、サーバーに次の行を追加します。

 Meteor.startup(function() { BrowserPolicy.content.allowImageOrigin("https://*.googleusercontent.com"); BrowserPolicy.content.allowImageOrigin("http://profile.ak.fbcdn.net"); BrowserPolicy.content.allowImageOrigin("http://graph.facebook.com"); });

タイトルは次のようになります。

 content-security-policy: default-src 'self'; script-src 'self' 'unsafe-inline'; connect-src * 'self'; img-src data: 'self' https://*.googleusercontent.com http://profile.ak.fbcdn.net http://graph.facebook.com; style-src 'self' 'unsafe-inline'; x-frame-options: SAMEORIGIN

デフォルトの制限に加えて、Meteorのドキュメントでは、サーバー側でBrowserPolicy.content.disallowInlineScripts（）を呼び出して、ページでインラインJavascriptを実行できないようにすることを推奨しています（もちろん、インラインJavascriptを使用しない場合）。

データ検証： check（）関数とaudit-arguments-checkパッケージ

Meteorは、サーバーメソッドとパブリッシュ関数に渡されたデータを検証するメカニズムを提供します。これを行うために、 check（）関数が意図されており、チェックされた値と検証用のテンプレートが渡されます。テンプレートは、明示的な型指示、またはより複雑な検証ルールを定義するMatchオブジェクトにすることができます（http：//docs.meteor.com/#matchを参照）

audit-argument-checksパッケージをインストールすると、検証に合格しなかったデータに合格した公開メソッドおよび公開関数の実行がブロックされます。

検証が不要な場合は、次のパラメーターを使用してチェック機能を呼び出すことができます

 check(arguments, [Match.Any])

パッケージを追加

 $ mrt add audit-argument-checks

サーバーメソッドを呼び出そうとすると、エラーが返されます。

 > Meteor.call('testMethod', 'test data', function(err, result) {console.log(err, result);}) undefined errorClass {error: 500, reason: "Internal server error", details: undefined, message: "Internal server error [500]", errorType:"Meteor.Error"…} undefined

サーバー上：

  Exception while invoking method 'testMethod' Error: Did not check() all arguments during call to 'testMethod'

サーバーメソッドに検証を追加すると、再び正しく機能し始めます。

  check(data, String);

結論の代わりに

開発を共有しようとしても、本質的にMeteorの非常に小さな部分にしか影響を及ぼせないという事実にもかかわらず、素材のボリュームがどれほど大きくなるかに気付きませんでした。

このテキストが、Meteorをより詳しく知り、それについて新しいことを学ぶのに役立つことを願っています。

Meteorだけでなくセキュリティについて（パート2）