クライアント側のコーディング：悪意のある使用を防ぐ方法

過去数年にわたって、クライアントサイド（ブラウザ）アプリケーションのトレンドは本当に始まっています。

私の最新のプロジェクトでは、時代とともに動き、クライアント側のアプリケーションを作成することにしました。

このアプリケーションの一部には、トランザクション電子メールのユーザーへの送信が含まれます（たとえば、サインアップの検証、パスワードのリセット電子メールなど）。サードパーティのAPIを使用してメールを送信しています。

通常、サーバーでアプリケーションを実行します。サーバー上のコードからサードパーティAPIを呼び出します。

クライアント側のアプリケーションを実行すると、ユーザーのブラウザでこれを行う必要があります。サードパーティAPIは、これを実現するために必要なJavaScriptファイルを提供します。

私が見ることができる最初の明白な問題は、APIキーを使用する必要があることです。これは通常、サーバーに安全に保存されますが、このキーをクライアントブラウザーに提供する必要があります。

私がこの問題を回避できると仮定すると、次の問題は、技術に精通したユーザーがブラウザでJavaScript開発者ツールをロードし、アプリケーションで設定したルールを遵守するのではなく、好きなように電子メールAPIを使用することを停止することです。

私の一般的な質問は-クライアント側アプリケーションの悪意のある使用をどのように防ぐことができるのでしょうか？

あなたはそれができません、そして、より多くの人々がこれを理解し、彼らがより深く理解するほど、世界のためにより良くなります。

ユーザーの制御下にあるデバイスで実行されるコードは制御できません。スマートフォンはジェイルブレイクされる可能性があります。セットトップボックスは割れることがあります。通常のブラウザは、JavaScriptコードへのアクセスを阻止しようとさえしません。あなたは盗むまたは乱用価値のあるものを持っている場合は、決定した攻撃者はなりますが、すべてを検証しない限り、あなたは、サーバー側を大切することを行うことができます。

難読化はほとんど役に立ちません。リモートで金銭的なものが関係するとすぐにあなたが引き付ける種類の敵は、クラシファイド広告のようなアセンブリ言語を読みます。キーを保護するデバイスは、想定しているデバイスと同じであるため、暗号化は役に立ちません。同様の理由で、機能しない一見明らかな他の多くの対策があります。

残念ながら、これは非常に不便な真実です。私たちのコードが想定したとおりに実行されると仮定できれば、それはとても素晴らしいことだからです。そして、はい、それはすべてが非常に簡単になるので、面白くさえありません。しかし、願いはそうはなりません。そして、あなたが不快感を避けることができる唯一の賢いクッキーであるという希望に反対することは、あなたとあなたのクライアントを燃やすだけです。したがって、インターネットは敵の領土であるという考え方に入り、その追加費用を見積もりに含めれば、大丈夫です。

とはいえ、もちろん、多層防御のようなものもあります。JavaScriptを難読化しても、攻撃者が断固として決着することはありませんが、それほど決定的ではない攻撃者が先送りになる可能性があります。資産が保護するのに十分な価値があるが、費用がかからない場合、これらの手段のいずれかがシステムにビジネス価値を追加する可能性があります。それだけでは完璧ではありません。トレードオフを十分に認識している限り、それは合理的な戦略かもしれません。

ここでのルールは次のとおりです。

ユーザーが改ざんした場合、他のユーザーに影響を与えないクライアント側のすべてを実行します。特に、それはグラフィカルな効果を意味します。

セキュリティが必要なサーバー側のすべてを実行し、クライアントからUIイベントを送信します（たとえば、サーバーが実際にトランザクションを実行している間にクライアントが「ユーザーが[購入]ボタンをタップしました」と言うだけです）。特に、それは金融取引を意味します。

これは、完全にクライアント側のアプリケーションにすることが適切ではない場合です。

応答性を向上させるために、クライアント側のフォームのロジックと基本的な検証を行い（誰かがリクエストを偽造しようとする可能性があるため、サーバー上で再検証する必要があります）ページ装飾などの再送信は避けてください。ただし、トランザクション自体を認証および承認する必要がある場合は、サーバー上で発生する必要があります。

中央の段落が問題の核心です：

クライアント側のアプリを実行すると、ユーザーのブラウザーでこれを行う必要があります。サードパーティAPIは、これを実現するために必要なjsファイルを提供します。

クライアント側のアプリがサーバー側の作業ができないことを意味するのはなぜですか？クライアント側のプログラミングへの推進は、サーバーを排除することではなく、ブラウザーが最終的にサポートする新しいテクノロジーを活用してユーザーインターフェイスを改善することです。

.jsあなたが受け取ったファイルに関しては、それがブラウザ向けであることを確信していますか？node.jsライブラリですか？

これから戻って、より高いレベルの外観を見てみましょう..我々は.. Eudoraまたはoutlook（クライアント側のアプリ、ブラウザさえ必要としない）はどんな会社にとっても金銭的損失を引き起こしたでしょうか？いいえ。誰でもPOP / SMTP APIに書き込み、クライアントになることができます。しかし、サーバーへの損失はありません。サーバーは、クライアントのアクション、計算、ストレージ、温度、ディスクサイズ、RAMサイズ、モニターDPI、GPU、クライアントのFPUやだやだを制限しませんでしたが、それに対する答えを正確に指定しました。QuickenやMS-Moneyが銀行に侵入するのを聞いたことはありますか？

ブラウザ（クライアント側）アプリは同じアーキテクチャを使用できます。

1. APIを使用してサーバーを構築します（BTWは、常にGET POST HEADなどの派生物に要約されます）。
2. サーバーで、APIがすべての呼び出しに対して認証済みでID検証済みのクライアントとのみ通信することを確認します。
3. その場合、クライアントが誰であるかは気にしません。
4. そして、あなたはそれがブラウザ、ジェイルブレイクされたデバイス、グーグルグラス、DOS 3.1、または2014年に時間旅行してすべてを逃したテクノフォーブの偉大な偉大な偉大な祖父の手にある新しいネクサスであるかどうか気にしません過去15年間で私たちの生活をflood濫させてきた技術。
5. これで、他のすべてをクライアント側にオフロードすることができます。

SoapBoxBegin

@KilianFothは、世間知らずで無謀な人々、主に常に見出しを読んでいるが、アプリ、コード、雇用主、クライアント、自分の銀行口座にそれが起こるとは決して思わない人々に重要な認識ポイントを上げます。さらに無謀なのは、システムを管理されていない/制御されていない露出にさらすアプリを公開することを許可する雇用主（特にCTO）です。しかし、私たちはそれが「決して学ばない」ように見えることに常に困惑しています。

SoapBoxEnd

要約すると。強固でタイトなサーバー側APIを作成します。クライアントが処理できるものに基づいて、他のすべてをクライアントにオフロードします。

私はあなたが本当にできないと主張したいと思います。データをクライアントに送信する場合は、そのデータが悪用される可能性があることを期待する必要があります。APIキーに関するあなたの例は要点を説明するものであり、クライアント側のJSにはそれを含めません。盗まれて悪用されます。

確かに、物事を安全に保つためにある程度のサーバーコードが必要になります。ログインしているユーザーに関連するデータのみを取得するような簡単なことでも。その認証をすべてクライアント側で行うことはできません。また、あなたは利用され、データは安全ではありません。

私はいつもJSクライアント側の経験がサーバーコードに追加されると考えています。クライアントでの検証は優れたユーザーエクスペリエンスを提供しますが、受信サーバーでもPOSTデータを検証しないと、攻撃を受ける可能性があります。クライアントからの何かは疑わしいと見なされるべきです。

本当に簡単です。クライアントコンピューターとその上で実行されているすべてのソフトウェアが、巧妙な悪意のあるハッカーの完全な制御下にあると仮定します。

つまり、サーバーからクライアントに送信する情報はすべて悪意のあるハッカーに知られるため、サーバーまたはビジネスを攻撃するために使用できる情報をクライアントに送信しないようにする必要があります。

また、クライアントからサーバーに送信されるものはすべて悪意のあるハッカーによって作成されたものであるため、サーバーコードでは、クライアントが送信できないものがサーバーを正常に攻撃できないことを確認する必要があります。

確かに、実装は問題ですが、重要なことは精神的な態度です。サーバーが話していると考える「クライアント」はクライアントではなく、積極的な攻撃者であるという仮定です。

（また、ユーザーはビジネスメソッドを攻撃しようとする巧妙な詐欺師であると想定する必要がありますが、それはクライアント側のプログラミングとは関係ありません）。

私の意見では、クライアント側アプリケーションの大部分はUIに関するものです。たとえば、すべてのUIシステムがクライアントに1回送信された後、クライアントは必要な処理をすべて実行します。

通常、サーバーでアプリケーションを実行します。サーバー上のコードからサードパーティAPIを呼び出します。

クライアント側のアプリケーションを実行すると、ユーザーのブラウザでこれを行う必要があります。サードパーティAPIは、これを実現するために必要なJavaScriptファイルを提供します。

APIキーをお持ちの場合、クライアント側で機能することは意図されていません。クライアント側でAPIキーを指定すると、だれでもアクセスでき、そのキーを独自の目的に使用できます。それを保存し、クライアントが必要なときにサーバー側で使用してから、Ajax / WebSocketsを使用して結果を送信します。

あなたの銀行が言ったようです：「さて、クライアントが自分でそれを要求できるように、メインデータベースクライアント側のパスワードを入れて、彼はもう私たちのサーバーを気にしません。」