2012-11-10 10 views
22

最近、私は便利で使いやすいことを発見したparse.comです。 これは本当に開発をスピードアップし、あなたのWeb /モバイルアプリから来るすべてのデータを格納する既製のデータベースを提供します。parse.com security

しかし、どのように安全ですか?私が理解しているところでは、コードにアプリの秘密鍵を埋め込み、データへのアクセスを許可する必要があります。

しかし、誰かがあなたのアプリからキーを回復することができますか?私はそれを自分で試しました。標準のAPKから秘密鍵を見つけるには5分かかりました。秘密鍵があなたのjavascript sourceにハードコードされたWebアプリケーションを構築する可能性もあります。

私が見つけたデータを保護する唯一の方法はACL(https://www.parse.com/docs/data)ですが、誰でも書き込み可能なデータを改ざんできる可能性があります。

誰でも私を啓発できますか?

+0

これも私に関係しています。私はいくつかのリンク(https://parse.com/questions/prohibit-user-from-changing-their-own-game-scoreとhttps://parse.com/questions/javascript-sdk-security)を見つけました。私はParseのACLシステムはおそらく私の特定のアプリケーションのニーズに十分安全だと思うが、私はある特定の用途のために、私は物事をロックダウンしようとするより多くのセキュリティ実践を学ぶ必要があるだろうと思う。 – Ryan

答えて

18

バックエンドサーバーと同様に、潜在的な悪意のあるクライアントを防御する必要があります。 Parseには、それを手助けするいくつかのレベルのセキュリティがあります。

最初の手順はACLsです。データブラウザでpermissionsを変更して、権限のないクライアントが新しいクラスを作成したり、既存のクラスに行や列を追加したりすることを禁止することもできます。

セキュリティレベルが満たされない場合は、データアクセスをCloud Functionsでプロキシすることができます。これは、クライアントとバックエンドのデータストア間のアクセス制御レイヤーを提供する仮想アプリケーションサーバーの作成に似ています。

+1

これは間違いなく、従来のolとは異なるモデルです。ここでは、JavaScriptアプリケーションでは動作しない、何かを可能にするサーバー側のコードで隠すことのできる秘密鍵があります。 @bklimtが扱う一般的なアイデアは、「親愛なるアプリのユーザーです。あなたがログインするまでは何もできません。また、ログインすると、ポリシー(ACLとアクセス許可)に基づいてアクティビティが制限されます。あなたのアカウント。" – Seth

+0

これは私が雲の機能を愛する理由です!すべてのリクエストをフィルタリングして、さらに多くのことを行うことができます。 –

3

私は、ユーザーデータの小さなビューをWebアプリケーションに公開する必要がある場合に、以下の方法を採用しました。

a。セキュアオブジェクトフィールドのサブセットを含むセカンダリオブジェクトを作成します。

b。 ACLを使用すると、セキュリティ保護されたオブジェクトは、適切なログインからのみアクセスできるようにします。

c。二次オブジェクトを公開します。

d。セカンダリオブジェクトをプライマリへの更新と同期させるためのトリガを作成します。

ほとんどの場合でもクラウド機能を使用しますが、このテクニックは柔軟性が必要な場合に便利です。また、セカンダリオブジェクトが複数のセキュリティ保護されたオブジェクトのビューである場合はクラウド機能より簡単です。

0

私がしたことは次のとおりでした。

  1. すべてのクラスに対してpublicの読み取り/書き込みを制限します。クラスデータにアクセスする唯一の方法は、クラウドコードを使用する方法です。
  2. パラメータrequest.userを使用してログインしているユーザであること、およびユーザセッションがヌルで、オブジェクトIDが合法であることを確認します。
  3. ユーザーが確認されたら、マスターキーを使用してデータを取得できます。
0

グローバルレベルのセキュリティオプション(クライアントクラスの作成など)を厳重に管理してください。)、クラスレベルのセキュリティオプション(たとえば、_Installationエントリを削除するクライアントを無効にすることができます。また、すべてのクラスのユーザーフィールド作成を無効にすることもできます)。

通常は、beforeSaveトリガーを使用して、ACLが常に正しいことを確認します。たとえば、_Userオブジェクトは、リカバリ電子メールの場所です。他のユーザーが互いのリカバリ電子メールを見ることはできないようにするため、_Userクラスのすべてのオブジェクトは読み取りと書き込みをユーザーにのみ設定する必要があります(public読み取りfalse、public write false)。

この方法では、ユーザー自身が自分の行を改ざんすることができます。他のユーザーは、この行がデータベースに存在することさえ気付かないでしょう。

これをさらに制限する方法の1つは、クラウド機能を使用することです。あるユーザーが別のユーザーにメッセージを送信できるとします。これは、メッセージの内容と、メッセージを送信したユーザーへのポインタと、メッセージを受信するユーザーに、このメッセージを新しいクラスのMessageとして実装できます。

メッセージを送信したユーザーはメッセージをキャンセルできる必要があり、メッセージを受信したユーザーが受信できる必要があるため、両方ともこの行を読み取る必要があるため(ACLには読み取り権限が必要です両方のために)。しかし、私たちはどちらもメッセージの内容を改ざんしたくありません。

したがって、ユーザーがこの行に加えようとしている変更が有効かどうかを確認するbeforeSaveトリガーを作成するか、誰にも書き込み権限がないようにメッセージのACLを設定するかユーザーを検証し、マスターキーを使用してメッセージを変更するクラウド機能を作成します。

ポイントは、アプリケーションのすべての部分でこれらの考慮事項を行う必要があります。私が知る限り、これを回避する方法はありません。