これが話題になっているのかどうかはわかりませんが、.NET WinForms に固有のものであるため、Security stackexchange サイトよりもこちらの方が理にかなっていると思います。
(また、これはセキュア コーディングに厳密に関連しており、サイト全体で見られる一般的な Web サイトの脆弱性について尋ねる質問と同じくらい話題になっていると思います。)
何年もの間、私たちのチームは Web サイト プロジェクトの脅威モデリングを行ってきました。私たちのテンプレートの一部には、OWASPトップ 10 とその他のよく知られた脆弱性が含まれているため、脅威のモデリングを行うときは、これらの一般的な脆弱性のそれぞれに対処するための文書化されたプロセスがあることを常に確認しています。
例:
SQL インジェクション (Owasp A-1)
- 標準的な慣習
- データへのアクセスが可能な場合は、ストアド パラメーター化プロシージャを使用する
- ストアド プロシージャが実行できない場合は、パラメーター化されたクエリを使用します。(私たちが変更できないサードパーティの DB を使用)
- 上記のオプションが実行できない場合にのみ、一重引用符をエスケープします
- データベースのアクセス許可は、最小特権の原則に従って設計する必要があります
- デフォルトでは、ユーザー/グループはアクセスできません
- 開発中に、各オブジェクト (テーブル/ビュー/ストアド プロシージャ) に必要なアクセスと、アクセスに対するビジネス ニーズを文書化します。
- [をちょきちょきと切る]
とにかく、Web サイトに固有の一般的に知られている脆弱性の出発点として、OWASP トップ 10 を使用しました。
(最後に質問へ)
まれに、Web アプリがニーズを満たさない場合に、WinForms または Windows サービス アプリケーションを開発します。WinForms アプリの一般的に知られているセキュリティ脆弱性の同等のリストがあるかどうか疑問に思っています。
頭のてっぺんから、いくつか思いつくことができます....
- SQL インジェクションは依然として懸念事項です。
- 通常、バッファー オーバーフローは CLR によって防止されますが、マネージ コードと混在する非マネージ コードを使用する場合は、より可能性が高くなります。
- .NET コードは逆コンパイルできるため、app.config で暗号化するのではなく、機密情報をコードに保存できます...
独自のリストを作成するために借用できるようなリスト、またはそのようなリストのいくつかのバージョンはありますか? もしそうなら、どこでそれを見つけることができますか?
私はそれを見つけることができませんでしたが、それがあれば、私たちだけでなく、他の WinForms 開発者にとっても大きな助けになるでしょう。