12

これが話題になっているのかどうかはわかりませんが、.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 開発者にとっても大きな助けになるでしょう。

4

3 に答える 3

12

Web環境とデスクトップ環境には大きな違いがあります。Web サイトやサービスを開発する場合、信頼できないのはユーザー (ユーザー入力) です。デスクトップ アプリケーションを実行する場合、信頼されていないのはアプリケーション自体です。少なくともシステム管理者は、アプリケーション自体が害を及ぼさないかどうかを知りたいと考えています。これは、ローカル コンピューターで実行されるコードがリスクであるためです。それ自体で。

つまり、ある意味では、デスクトップ アプリケーションの開発者にとって、実行するアプリケーションはブラック ボックスではなくホワイト ボックスであるため、セキュリティ ルールが常に適用されるわけではありません。Web サービス/サイトでは、攻撃が内部状態を変更できないことが予想されますが、任意のデスクトップ アプリ (Java、.NET、ネイティブ) では、アプリケーションが動作している間にアプリケーションの状態を変更するのは「非常に」簡単です。アプリケーションのデバッグと逆コンパイルは非常に簡単です。

つまり、デスクトップ アプリケーションが完全に危険にさらされていると見なす必要があり、これがリスクである場合は、セキュリティで保護する必要があるすべてのもの (認証、承認、検証) を外部 (Web) サービスに抽出する必要があります。このサービスには、「通常の」OWASP ルールが適用されます。

注意すべきことは、デスクトップ アプリケーションがデータベースに直接接続する場合、データ レイヤーを完全に保護することは非常に難しいということです。たとえば、この場合、SQL インジェクションはデスクトップ アプリケーションの問題ではありません。アプリケーションがデータベースに直接接続できる場合は、ユーザーも接続できるからです。また、ユーザーがデータベースに接続できれば、任意のクエリを実行できます。これは SQL インジェクションの極端な形ですが、アプリケーションを完全にスキップします。

2 層アプリケーションを保護しようとすることは、多くの場合、ストアド プロシージャを中間 (サービス) 層として使用することを意味します (そして、テーブルへの直接アクセスを防ぎます)。ストアド プロシージャの開発と保守は、.NET (Web) サービスの開発よりもはるかにコストがかかります。

于 2012-07-05T15:13:16.987 に答える
4

おそらく、セキュリティの脆弱性をチェックする既存のツールを調査したいと思うでしょう。彼らは時々、チェックする欠陥のリストを持っています。

開発者はあらゆる種類の穴を開ける可能性があるため、マネージ コードには依然としてあらゆるセキュリティ リスクが存在します。フレームワーク (.NET) 自体はリスクではありませんが、開発者にはリスクがあります。

ここにツールのリストがあり、ツールがチェックするセキュリティ リスクを確認できます。

静的コード解析一覧

しかし、もちろん、以下に示すように、既知の脆弱性があります。

technet リモートコード実行

特権の昇格

よく知られているセキュリティ サイトで見つけることができる、より多くの既知の未解決の欠陥があります。(ゼロデイ エクスプロイトを含む)

**詳細な情報、それは私がコメントで言及したチェックリストでした**

MS セキュリティ チェックリスト (これはほとんど中立的な情報であるため、これが「廃止」された理由がわからない

Web アプリケーション セキュリティ プロジェクトを開く

MS アンチ クロスサイト スクリプティング

MS ASP セキュリティ リファレンス実装 (非常に優れた情報サイト)

CAT.NET ... MS 静的セキュリティ分析ツール

于 2012-07-06T08:19:54.637 に答える
1

ユーザーはいつでもアプリをクラックできるため、実際に安全なローカルの winform アプリを構築することは不可能です。

しかし、クラッキングプロセスを遅らせるためのテクニックがいくつかあります。手法のほとんどは、ジャンク コードやパッキングなど、アセンブリ レイヤーで発生しました。

もう 1 つの手法は、実行可能コード (つまり、プログラムが実行されているときにメモリに入るコード) を時間とともに変化させることです。ただし、最初に他のすべてのコード (実行されないコード) が安全であることを確認する必要があります。これは暗号化によって行うことができます。ただし、暗号化プログラムがより高度に保護されていることも確認する必要があります. 暗号化プログラムは常に ROM に固定され、物理的な手段で保護されています。

もう 1 つの方法は、ネットワークを活用することです。ローカル アプリを頻繁に更新し、古いバージョンを禁止します。このようにして、クラッキング プロセスを打ち負かすのに十分な速さでコードが変更される可能性があります。

ああ...私はゴミを投げていますか、それともトピックから外れていますか? 私の謝罪の気持ち。

于 2012-07-15T07:01:49.763 に答える