クライアント側のエクスプロイトとは
私はサイバーセキュリティについて学び、クライアント側のエクスプロイトについて読みました。私はそれらが脆弱性/エクスプロイトであり、サーバーではなくクライアントをターゲットにしていることを知っています。これのいくつかの例は何ですか、そしてそれらはどのように機能しますか？
従来のクライアント/サーバーアーキテクチャには、クライアントによって開始された要求を処理するサーバーと、その要求を行うクライアントがあります。クライアント/サーバーアーキテクチャの例はWebです。この場合、webサーバーはwebブラウザー（クライアント）と通信します。したがって、クライアント側のエクスプロイトは、クライアントを攻撃または影響するエクスプロイトです。これは、サーバーを攻撃するサーバー側のエクスプロイトとは区別されます。
クライアント側の悪用の例としては、ブラウザのバグを悪用する悪意のあるJavaScriptがあります。サーバー側の悪用の例としては、サーバーのデータベース処理を攻撃するSQLiがあります。そこにはより多くのクライアント/サーバーアーキテクチャがあるため、クライアント側の悪用はWebに固有のものではありません。 PuTTY（SSHプロトコルを介してリモートサーバーを管理するために使用されるWindowsプログラム）の脆弱性を攻撃することは、WebまたはWebブラウザーが関与しないクライアント側の悪用の例です。
クライアント側の悪用は必ずしもクライアントへの攻撃ではありません！
多くのWebサーバーは、クライアント側の機能を介して認証とセキュリティを呼び出します。たとえば、クライアントコードがこのコンテンツを適切に保持して再利用することを期待して、クエリ応答でサブパスまたはIDを返す場合があります（cookies this way）。問題は、クライアントのコードとデータがクライアントユーザーによって変更される可能性があり、異なるID、オフセット、パス、またはサーバーで発生または意図されていないものを送信できるようにすることです。
数年前、オンラインショップが買い物かごのデータをクライアントに送り返し、さまざまな商品の価格など、チェックアウトまで保持することは非常に一般的でした。チェックアウトに送信する前に、クライアントの価格を変更するのは非常に簡単でした。サーバーがバスケットの再検証に失敗し、多くが失敗した場合、購入はクライアント側の変更された価格で行われます。
他の例には、サーバーがログオン時にクライアントIDを検証した3層のクライアントサーバーデータベースで他の誰かのIDを使用することが含まれていましたが、サーバーデータベース接続は実際には内部固定IDのみであり、サーバーがクライアントにエコーしたIDを渡しました録音。 ID＃1の初期認証後、クライアント側のデータはID＃123に変更される可能性があります。ID＃123は最初にチェックしただけか、認証されたものとはまったく異なるフィールドを使用して保持するため、サーバーから渡されます。 ID。
これらは2つの例にすぎませんが、どちらも実際のものでした。