つまり、オペレーティングシステムまたはそのアプリケーションで。私が考えることができる唯一の方法は、strcpy() のような危険な関数の使用についてバイナリを調べてから、それらを悪用しようとすることです。Visual Studio の /GS スイッチのようなコンパイラの改善により、この可能性はほとんど過去のものになるはずです。それとも私は間違っていますか？
人々は脆弱性を見つけるために他にどのような方法を使用していますか? ターゲットをデバッガーにロードし、予期しない入力を送信して、何が起こるかを確認しますか? これは長くて退屈なプロセスのようです。
このテーマについて、良い本やウェブサイトを推薦してくれる人はいますか?
前もって感謝します。
「クライアント側のセキュリティ」に関連する2つの主要な問題があります。
今日利用されている最も一般的なクライアントは、「ドライブバイダウンロード」形式のブラウザです。ほとんどの場合、メモリ破損の脆弱性が原因です。ActiveX comオブジェクトはWindowsシステムで一般的なパスであり、AxManは優れたActiveXファザーです。
メモリ保護システムの観点から、/ GSはカナリアであり、バッファオーバーフローを停止するためのすべての目的ではありません。これは、リターンアドレスを上書きしてEIPを制御しようとしているスタックベースのオーバーフローを保護することのみを目的としています。NXゾーンとカナリアは良いことですが、ASLRはメモリ破損の悪用を阻止するのにはるかに優れている可能性があり、すべてのASLR実装が同等に安全になっているわけではありません。これら3つのシステムすべてを使用しても、ハッキングされる可能性があります。Windows7で実行されているIE8にはこれらすべてがあり、pwn2ownで最初にハッキングされたものの1つであり、これが彼らのやり方です。これには、ヒープオーバーフローとダングリングポインタの脆弱性を連鎖させることが含まれていました。
「クライアント側のセキュリティ」の問題はCWE-602です。サーバー側のセキュリティのクライアント側の強制は、サーバー側がクライアントを秘密のリソース（パスワードなど）で信頼している場合、またはプレーヤーなどの機密情報に関するレポートを送信する場合に作成されます。フラッシュゲームで 得点します。
クライアント側の問題を探す最良の方法は、トラフィックを調べることです。WireSharkは、ブラウザ以外のクライアント/サーバープロトコルに最適です。ただし、 TamperDataは、FlashやJavaScriptなどのブラウザベースのプラットフォームに使用できる最高のツールです。プロセスのクラッシュを簡単に確認できるバッファオーバーフローとは異なり、クライアント側の信頼の問題はすべてコンテキストに関するものであり、ネットワークトラフィックを調べて問題を把握するには、熟練した人間が必要です。
愚かなプログラマーは、パスワードをアプリケーションにハードコーディングすることがあります。アプリを逆コンパイルしてデータを取得するのは簡単です。フラッシュ逆コンパイルは非常にクリーンで、完全な変数名とコードコメントも取得できます。もう1つのオプションは、OllyDBGなどのデバッガーを使用して、メモリ内のデータを検索することです。IDA-Proは、C /C++アプリケーションに最適な逆コンパイラです。
Writing Secure Code, 2nd editionには、脅威のモデリングとテストに関する情報が少し含まれています。