JavaScriptを（ブラウザで）ハッキングするのはどれくらい簡単ですか？

私の質問はJavaScriptのセキュリティに関するものです。

BackboneやAngularJSのようなJavaScriptフレームワークを使用し、安全なエンドポイントが必要な認証システムを想像してください。サーバーは常に最後の単語を持ち、あなたが望むことをする権限があるかどうかをチェックするので、それは問題ではありません。

しかし、サーバーを使用せずに少しのセキュリティが必要な場合はどうでしょうか？それは可能ですか？

たとえば、クライアント側のルーティングシステムがあり、ログインしたユーザーに対して具体的なルートを保護したいとします。したがって、保護されたルートへのアクセスを許可されているかどうかを確認するためにサーバーにpingを実行します。問題は、サーバーにpingを送信すると、応答を変数に保存するため、次回プライベートルートにアクセスしたときに、既にログインしている（サーバーにpingを送信していない）かどうか、および応答でそれが行くかどうか。

ユーザーがその変数を変更してアクセスするのは簡単ですか？

私のセキュリティ（およびJavaScript）の知識はあまり良くありません。しかし、変数がグローバルスコープ内になく、ゲッターのみを持ちセッターを持たないモジュールパターンのプライベート部分にある場合、その場合でも、ハッキングできますか？

これを読む前にヨアヒムの答えを読んでください。彼は、クライアント側の脆弱性の背後にある一般的な理由をカバーしています。さて、この問題を回避する方法を提案するために...

リクエストごとにサーバーで手動で認証する必要のないクライアント/サーバー通信の安全なスキーム：

あなたはしている今でも、サーバーが最後の発言権を持っせ、およびサーバは、まだクライアントが言うすべてを検証するために持っているが、それは透過的に行われます。

HTTPSプロトコルを想定して、中間者攻撃（MITMA）を防ぎます。

• クライアントは初めてサーバーとハンドシェイクし、サーバーはクライアントの公開鍵を生成し、非対称暗号化スキームを使用して秘密鍵を保持します。クライアントは、サーバーの「公開」キーをローカルストレージに保存し、どこにも保存しない安全なパスワードで暗号化します。

• これで、クライアントはオフラインになりました。クライアントは信頼できるアクションを実行したいと考えています。クライアントはパスワードを入力し、サーバーの公開キーを取得します。

• クライアントはそのデータの知識に基づいてアクションを実行し、クライアントは実行するすべてのアクションをそのクライアントのサーバーの公開キーで暗号化します。

• クライアントがオンラインの場合、クライアントはクライアントIDを送信し、クライアントが実行したすべてのアクションは、サーバーの公開キーで暗号化されたサーバーに送信されます。

• サーバーはアクションを解読し、それらが正しい形式である場合、クライアントで発生したことを信頼します。

注意：

• クライアントのパスワードをどこにも保存することはできません。そうしないと、攻撃者はキーを取得し、独自のアクションに署名することができます。このスキームのセキュリティは、サーバーがクライアント用に生成するキーの整合性のみに依存します。そのキーを要求するとき、クライアントはまだサーバーで認証される必要があります。

• 実際には、クライアントではなくセキュリティをサーバーに依存しています。クライアントが実行するすべてのアクションは、サーバーで検証する必要があります。

• Web Workerで外部スクリプトを実行することが可能です。あなたが持っているすべての JSONPリクエストは、今やはるかに大きなセキュリティ問題になっていることに留意してください。すべてのコストでキーを保護する必要があります。紛失すると、攻撃者はユーザーになりすますことができます。

• これは、「サーバーへのpingを実行しない」という要求を満たします。攻撃者は、鍵を知らない場合、偽造データでHTTPリクエストを単純に模倣することはできません。

• ヨアヒムの答えはまだ正しい。実際には、サーバーですべての認証を実行しています。ここで保存した唯一のものは、毎回サーバーでのパスワード検証の必要性です。これで、コミットするとき、または更新されたデータをプルするときにのみサーバーに関与する必要があります。ここで行ったのは、クライアント側で信頼できるキーを保存し、クライアントにそれを再検証させることだけです。

• これは、単一ページアプリケーション（AngularJSなど）の非常に一般的なスキームです。

• サーバーの公開鍵をRSAのようなスキームで何を意味するのかを「公開」と呼びますが、実際にはスキーム内の機密情報であり、保護する必要があります。

• パスワードをメモリ内のどこにも保管しません。ユーザーがオフラインコードの実行を開始するたびに、「オフライン」パスワードを送信するようにします。

• 独自の暗号を転がさないでください -認証にはスタンフォード大学のような既知のライブラリを使用してください。

• このアドバイスをそのままお使いください。実際のビジネスに不可欠なアプリケーションでこの種の認証を行う前に、セキュリティの専門家に相談してください。これは深刻な問題であり、苦痛であり、間違いを起こしやすいものです。

他のスクリプトがページにアクセスできないことが重要です。つまり、Webワーカーで外部スクリプトのみを許可します。ユーザーがパスワードを入力したときにパスワードを傍受する可能性のある他の外部スクリプトを信頼することはできません。

使用promptしていない、あなたが完全にわからないと（それはイベントがそれへのアクセス権を持っていますが、唯一の同期コード内のポイントへのライブべきではない）その実行延期しない場合は、インラインパスワードフィールドを。また、実際にはパスワードを変数に保存しないでください。これも、ユーザーのコンピューターが危険にさらされていないことを信頼する場合にのみ機能します（ただし、サーバーに対する検証についても同様です）。

クライアントをまだ信用していないことを付け加えたいと思います。クライアントだけを信頼することはできません。Joachimの答えはそれを否定すると思います。作業を開始する前にサーバーをpingする必要がないという利便性のみを得ました。

関連資料：

• 証明書とユーザー名+パスワード。
• クライアント側でセキュリティを実行できないのはなぜですか？
• 独自の暗号を転がさないでください。
• JSを暗号化操作に対して安全にするための関連する議論

簡単です。攻撃者がクライアントを制御している場合、クライアントが指示どおりの操作のみを行うことに依存しているセキュリティメカニズムは危険にさらされる可能性があります。

クライアントでセキュリティチェックを行うことができますが、「キャッシュ」として効果的に機能するためにのみです（クライアントが回答が「いいえ」であることを既に知っている場合にサーバーへの高価な往復を回避するため）。

一連のユーザーからの情報を保持する場合は、それらのユーザーのクライアントがその情報にアクセスしないようにしてください。「秘密データ」と「表示しないでください」という指示を一緒に送信すると、そのリクエストをチェックするコードを無効にするのは簡単になります。

ご覧のとおり、この回答ではJavaScript / Browserの詳細については言及していません。これは、クライアントが何であっても、この概念が同じだからです。ファットクライアント（従来のクライアント/サーバーアプリ）、旧式のWebアプリケーション、または広範なクライアント側JavaScriptを備えた単一ページアプリであるかどうかは、実際には関係ありません。

データがサーバーを離れると、攻撃者がデータに完全にアクセスできると想定する必要があります。

ゲームコミュニティには「クライアントは敵の手の中にいる」という格言があります。「。サーバーなどのセキュリティ保護された領域の外で実行されているコードは脆弱です。最も基本的なシナリオでは、そもそも実行されないことに対して脆弱です。実際に「セキュリティコード」を実行するのはクライアントの決定であり、ユーザーはネイティブコードを使用すると、少なくともアセンブリへの自動難読化と、それを操作するために攻撃者が優れたプログラマーである必要があるという事実による追加の保護層がありますが、JSは通常、難読化されずプレーンテキストとして提供されます。攻撃を仕掛けるのに必要なのは、プロキシサーバーやテキストエディターなどの原始的なツールだけです。攻撃者はプログラミングに関するある程度の教育が必要になりますが、実行可能ファイルにコードを挿入するよりも、テキストエディターを使用してスクリプトを変更する方が簡単です。

これはJavaScriptをハッキングする問題ではありません。アプリを攻撃したい場合、プライベートプロキシを使用して、トラフィックをキャプチャ、変更、およびリプレイできます。提案されたセキュリティスキームには、それに対する保護が設定されていないようです。

特にAngularについて話す：

ルートクライアント側の保護は存在しません。ユーザーがいつでも入力できるルートにボタンを「非表示」にしても、Angularは文句を言いますが、クライアントはそれをコーディングできます。

ある時点で、コントローラーはビューのレンダリングに必要なデータをサーバーに要求する必要があります。ユーザーがそのデータにアクセスすることを許可されていない場合、サーバー側でこのデータを保護しているため、ユーザーはデータを受信しません、Angularアプリは401を適切に処理する必要があります。

生データを保護しようとしている場合、特定のユーザーが特定の方法でのみ共通データを表示できるようにしたい場合は、送信するのではなく、サーバー上でデータ「ビュー」を作成します生データをクライアントに送信し、それを再編成する（とにかく、パフォーマンス上の理由からこれを既に行う必要があります）。

サイドノート：Angularが要求するビューテンプレートに組み込まれている機密情報は絶対に使用しないでください。何らかのクレイジーな理由がある場合は、サーバー側のレンダリングを行う場合と同様に、サーバー側でこれらのビューテンプレートを保護する必要があります。