.NETセキュリティは簡単です

セキュリティ分野の有力な専門家であるウラジミール・コチェトコフ（ Positive Technologiesのアプリケーションセキュリティ分析研究部長）とミハイルシュチェルバコフ（情報セキュリティ分野の独立した開発者およびコンサルタント）とのインタビューを提供します。

この記事の目的は何ですか？ マイケルのレプリカの1つを引用します。

「安全なアプリケーションの開発は、エラーをまったく含まないアプリケーションを開発する特別なケースです。 さらに、アプリケーションは、セキュリティも保証されていないサードパーティライブラリを使用し、OSおよびハードウェア上で実行されます。 多くの場合、どのOSとどのハードウェアかさえわかりません。 そして、これらはすべて時間の経過とともに変化します！」

ウラジミール・コチェトコフ -2006年以来、彼は情報セキュリティの分野で働いていました。 彼は、Webアプリケーションセキュリティ分析グループの第一人者として、2012年にPositive Technologiesに入社しました。 彼は、アプリケーションセキュリティの分析プロジェクトに参加し、アプリケーションテスト技術を研究しました。 Vladimirの参加により、製品PT Application Inspectorが実装されました。 2014年から2016年にかけて、彼はコンパイル済みアプリケーション用のアナライザーの開発グループを率い、バイナリコード分析モジュールの開発プロジェクトを率いました。 2016年9月以来、彼はアプリケーションセキュリティ分析の研究部門を率いています。 彼は、アプリケーションセキュリティ分析と有望な企業製品のプロトタイピングの方向の理論的研究に直接関与しています。 雑誌HITB Magazine、「Hacker」、およびRSDN Magazineの記事の著者。 Positive Hack Days国際フォーラム（主催者および講演者）およびDotNext .NET開発者会議に繰り返し参加し、ユーザーグループ開発者会議で定期的に講演しています。 彼はRSDNのロシア語を話す開発者のコ​​ミュニティの開発に参加しています。 Positive Development User Groupの主催者の1人は、開発者をアプリケーション保護の分野に没頭させることを目的としたイニシアチブです。 彼にはブログkochetkov.github.ioがあります。

モスクワは、 レポート「Winning Injections」でDotNext 2017に到着します。


Mikhail Shcherbakov -Microsoft .NET MVP、.NET Core Bug Bounty Programのメンバー、.NETプログラマコミュニティの共同主催者、独立した開発者およびコンサルタント。 専門分野：静的および動的コード分析、情報セキュリティ、コードデバッグの自動化、.NET CLR内部デバイスの調査。

モスクワは、ASP.NET Core：Attack Prevention Mechanisms 2.0のプレゼンテーションでDotNext 2017に到着します。

---

-現在、.NET Frameworkには通常どのような種類の脆弱性がありますか？

Mikhail Shcherbakov ：ここでは、.NET Framework自体と.NETプラットフォームに基づいて作成されたアプリケーションの脆弱性を共有する必要があります。 .NET Frameworkは、Webサイトやサービスからデスクトップアプリケーションまで、さまざまな種類のアプリケーションを開発するためのプラットフォームです。 また、これはWindowsオペレーティングシステムの不可欠な部分であるため、.NET FrameworkセキュリティはOSとして扱う必要があります。 この脆弱性の主な部分は、通常のWeb開発者XSS、CSRF、SQL / XML / JSONおよびその他のインジェクションではなく、任意のコードの実行、ユーザー特権の増加、情報漏えい、およびサービス拒否です。

-ASP.NETおよび.NET Coreで最近発見された脆弱性について、何を知っていますか？

マイケル ：詳細な話は1時間は解決しませんでした:)「大きな」.NETフレームワークの脆弱性について1年前にDotNextモスクワで報告しました。 エクスプロイトのデモンストレーションとこれらの脆弱性につながるバグの解析。 もちろん、45分以内に必要なものが含まれることが判明したため、開発者が製品、主にWebアプリケーション、ASP .NETで許可する脆弱性に焦点を当てようとしました。 DoS、特権の昇格、XXE、情報開示、データの逆シリアル化に対する攻撃の例がありました。

今年、.NET Coreの大きなパッチがリリースされました。このパッチでは、DoS、特権の昇格、保護メカニズムのバイパスなど、いくつかの脆弱性が修正されました。 オープンリダイレクトに対する保護で見つかった脆弱性CVE-2017-0256を含みます。 よくある問題は、ユーザー入力の検証が不十分だったことです。 また、ケストレルにも注意を払う価値があります。私は今、このコードを自由な時間にレビューし、マイクロソフトと.NET Foundationの立場と一致します。 必ずいくつかのリバースプロキシ（Nginx、Apache、IIS）で閉じてください。 これについてはすぐにお話できると思います。

Vladimir Kochetkov ：過去数年にわたって、XMLドキュメントの処理に関連するプラットフォームの脆弱性が急増しています。 2013年に、BlackHat EU会議でXML外部エンティティの実装を攻撃するためのOOBテクニックに関するレポートをすでに作成しました。これは、System.Xmlドットネットを含むさまざまなXMLライブラリの多数の脆弱性の排除を伴いました。 ただし、進歩はまだ止まっておらず、数年後、再び.NETで一連の非常に伝統的なXML処理の脆弱性を確認しています：XXE（CVE-2016-3255）、XMLドキュメントの署名の改ざん（CVE-2016-0132）、DoS through特別な細工がされたXSLTドキュメントにより、再帰的な変換が行われます（CVE-2016-0033）。 より高いレベルのセキュリティを直接決定するOSレベルの脆弱性がないわけではありません。 そのため、win32k.sys（本質的にはWindowsカーネル）の脆弱性CVE-2016-0145により、攻撃者はドキュメントに埋め込まれた特別に細工されたフォント（!!）を使用してシステム上で任意のコードを実行できます。 もちろん、この脆弱性により、適切な形式のドキュメントで動作する.NETアプリケーションも攻撃される可能性があります。

別に、今年.NETで発見されたリモートの任意のコード実行の2つの脆弱性、 CVE-2017-0160とCVE-2017-8759に注目する価値があります。 最初の詳細な分析（およびその操作の概念実証コード）は、次の場所にあります。 https://www.exploit-db.com/exploits/41903/ 。 2つ目は、FireEyeブログの別の記事です。 この脆弱性は、特に、FinSpy政府のスパイウェアシステムを実装するために使用されたことは注目に値します。これは、WikiLeaksの別の出版物のおかげで知られるようになりました。

-そもそも攻撃している.NET Frameworkの標的は何ですか？ 攻撃者の標的は、たとえば5年間で変化しましたか？

Michael ：主な目標は、攻撃者が操作できる入力データを操作するさまざまなパーサーであるWebアプリケーションで使用されるコンポーネントです。 .NET Frameworkはすべての最新バージョンのWindowsで利用できるため、情報セキュリティ研究者にとってローカルコンポーネント特権エスカレーション攻撃を実装するためのコンポーネントは潜在的に興味深いものです。 たとえば、CVE-2014-0257を使用してInternet Explorer 11 Sandboxを終了し、CVE-2014-4073をClickOnceから終了しました。 サンドボックスで実行されたコードから.NETオブジェクトへのアクセスは、Managed DCOMを介して実装されました。 今年、DCOMの物語が繰り返され、攻撃手法が似ているCVE-2017-7293が発見されました。 Google Project Zeroチームのブログで、魅力的なストーリー全体を読むことができます。

過去数年間、攻撃者は.NET Sandboxを終了するために攻撃を使用することに関心を失ってきました。これは、テクノロジー自体が使用される製品が少ないためです。 .NET Coreには含まれていませんでした。ASP.NETチームは最終的にIIS内のアプリケーションを分離するためにサンドボックスの使用を放棄し、Silverlightはほぼ死にました。IEの最新バージョンは、サードパーティのXBAPアプリケーションコードの実行についてユーザーに警告し始めました。 4年前、CVE-2013-0073を悪用して、特別に準備されたページをブラウザーで開くだけで、ユーザーのコンピューターでリモートコード実行攻撃を行うことができました。 DotNext Moscow 2014でこのエクスプロイトの例を示しました。

私は.NET Coreに言及したので、それに取り組むとき、RyuJITコンパイラの脆弱性が修正されました：CVE-2015-2479、CVE-2015-2480、CVE-2015-2481。 最大15,000ドルの報酬を持つ .NET Coreの脆弱性を検索するためのオープンエンドのBug Bountyプログラムが現在公開されており、.NET Coreのコンポーネントはもちろん、情報セキュリティ研究者の優れたターゲットになりました。

ウラジミール ：まず第一に、攻撃者が誰であり、どのような攻撃を行うかに依存します。 自動大量攻撃の場合、目標は、たとえば、できるだけ多くのネットワークホストを制御することです。 したがって、この場合、プラットフォームの新しい脆弱性、一般的なフレームワーク、エンジン、およびライブラリがランダムに攻撃され、小さな辞書を使用して既知のエントリポイントの資格情報も選択されます。

標的を絞った標的型攻撃の場合、悪名高いキルチェーンの最高の伝統に従ってシナリオが展開されます：偵察が実行され、エクスプロイトが準備され、システムで実装が実行され、システムで修正され、攻撃者の目標を達成するためのアクションが実行されます。 この場合の目標は、原則として、機密情報の1回限りの受信または継続的な監視です。 .NETの場合、これは、攻撃されたアプリケーション（プラットフォーム自体のソースを含む）に関連する利用可能なソースの攻撃者による綿密な分析を意味し、データベース（System.Data、ORMと直接やり取りするコードに重点を置いた、特定のゼロデイ脆弱性の使用） ）または抽出された情報の他の外部リポジトリ。

純粋に技術的な観点から見ると、攻撃者の目標は過去5年間ほとんど変化していません-同じ脆弱性、攻撃、脅威のセットであり、年によってわずかに異なります（WebアプリケーションについてはOWASP Top 10を参照）。 注目すべき変更点-過去2、3年で、Windowsシステムでの修正技術の重要な開発に向かう傾向がありました。これは、.NETアプリケーションの脆弱性の悪用の成功に必然的に影響します。

「基本的な種類の攻撃を知ることは、安全なアプリケーションの開発に役立ちますか？

マイケル ：助けになるよ。 多くの場合、開発者の見解は、「テンプレート」Web脆弱性（XSS、パストラバーサル、さまざまなインジェクション）に関する知識によってあいまいにされ、アプリケーションセキュリティ違反につながる論理エラーにはほとんど注意を払いません。 したがって、開発中のプラットフォームで成功した攻撃の例は、視野を広げ、コードを再確認することを可能にします。 しかし、安全なアプリケーションを開発するには、体系的なアプローチが必要です。 ウラジミールと私は、.NETアプリケーションのセキュリティに特化した最初のSPB .NETコミュニティ会議の1つを開催し、理論的側面と実践的側面の両方からトピックを明らかにしようとしました。 この会議のオンラインビデオがあります。

ウラジミール ：「自分自身をハックする」という原則について話すと、それは単に機能しません。 開発者がアプリケーションを効果的に保護するには、攻撃者の観点から考えて、少なくとも平均的な攻撃者がプロであるという点で、彼はこの点でプロでなければなりません。 開発者にとって、これは実際には2番目の専門分野を取得することを意味します。 攻撃との戦いは、彼らの責任範囲ではありません。 開発フェーズの主な目的は、アプリケーションのセキュリティを確保するという観点から、 さまざまな攻撃に対する脆弱性につながる、アプリケーションセキュリティドメインコントロールコントロールの非効率的な実装である欠陥と戦うことです。 このトピックは、昨年4月にモスクワで開催されたCodeFreezeコミュニティの会議で十分詳細に議論されました 。 また、欠陥ではなく攻撃に対する開発者の闘いが、アプリケーションの脆弱性にどのようにつながるかについて、いくつかの例を検討しました。

もちろん、開発者は、少なくとも一般的な開発については、主な種類の攻撃を知っている必要があります。 ただし、アプリケーションの保護に関する決定を行うためにこの知識を使用しないでください。 ASP.NETアプリケーションに対する特定の攻撃に関心のある開発者は、私の記事「 ASP.NETのサイトをハックしますか？ 難しいですが、可能です！ 」、ハッカー誌の第165号に掲載（p。63）。

-開発者は、.NET Frameworkのどのセキュリティ面に焦点を当てる必要がありますか？

Michael ：開発者にとって、これはまず第一に、すべての入力データの検証、出力データのサニタイズです。 彼らは学校から入力の検証について話してきました。 ユーザー（セキュリティモデルの要件を含む）に準拠しているかどうかを確認する必要があります。 そして、主なことはそれを正しく行うことです：可能な場合はホワイトリストチェックを使用して、入力データ形式の文法を正しく記述します（これは、 正規表現で XMLまたはHTMLを解析する必要がないということです）。 これは、 Secure by Design / Default / Deployのすべての疲れた原則に従っています。

さらに、 OWASP開発者ガイド 、 ASP.NETでしてはならないこと、代わりに行うことなど、安全なアプリケーションを開発するための一連のベストプラクティスがあります 。 それらを知って従うことは、SOLIDのアーキテクチャパターンと原則を知ることと同じくらい重要です。

ウラジミール ：まず第一に、入力データと出力データの予備処理に焦点を当てています。 .NETの場合、これは次のことを意味します。

a）外部から受信したすべてのデータの強力なタイピング。 System.Stringの形式で受信したすべての外部データは、ビジネスロジックの特定のエンティティに変換してからこのフォームで使用する必要があります（もちろん、入力データのセマンティクスが、これらの文字列エンティティ、フォーラム»）。 ただし、すべての入力データを入力する必要があるにもかかわらず、非プリミティブ型に関しては、SSRF、逆シリアル化の脆弱性などの深刻なセキュリティ問題を引き起こす可能性があることを覚えておく必要があります。

b）入力されたすべての外部データの意味検証。 理想的には、各エンティティの不変条件を定義し、CodeContractsやPostSharp Contractsなどのコントラクトプログラミングツールを使用して不変条件を適用する必要があります。

c）ホストの文法に従って与えられたすべてのデータの構文衛生。 ここで、特定のサニタイザーの使用の必要性は、受信側の文法だけでなく、データが送信されるコンテキストにも依存することを覚えておく必要があります。 そのため、たとえば、JavaScriptコードなどで送信されるデータにHttpUtility.UrlEncode



を使用すると、アプリケーションがXSS攻撃に対して脆弱になります。 ほとんどの.NETサニタイザーは、クラスHttpUtility



、 HttpServerUtility



、 WebUtility



およびSystem.Web.Security.AntiXss



集中しています。 また、 LibProtectionライブラリにも注意を払う価値があります。LibProtectionライブラリの最初の公開リリースは今年の11月13日に予定されており、今後のDotNext Moscow 2017での私のレポートが対象です。

-.NET Frameworkのどのタイプの脆弱性があなたの仕事に干渉しますか（または、以前に干渉しましたか）、名前を付けることができますか？

Michael ：どんな脆弱性も、干渉よりも私の仕事に役立ちます:) .NET FWの脆弱性を分析するとき、コードを書くための新しいタイプの攻撃と（アンチ）パターンを調べることができます。 これは、安全なアプリケーションの開発とセキュリティシステムの分析に役立ちます。

ウラジミール ：私の仕事の性質上、.NETの脆弱性はそれを妨げるのではなく、貢献するものです。 しかし、お気に入りの.NET脆弱性について話すと、これは明らかに、ASP.NET WebForms（CVE-2010-3332）の暗号化されたトークンパターンの実装におけるOracleに対するセンセーショナルな攻撃であり、2010年にセンセーショナルであり、任意のWebサーバーファイルと偽の認証を読み取ることができますトークン。 この攻撃の詳細な分析は、 プレゼンテーションで見つけることができます。

-.NET Frameworkアプリケーション開発者が最も頻繁に行うセキュリティの側面のエラーは何ですか？

Michael ：Webプロジェクトのセキュリティレビューを行った私の経験では、これらはすべての種類の「広義の」インジェクションです。XSS、SQLi、XXE、パストラバーサル、およびアプリケーション構成の問題です。 これは、今年の有名なOWASPトップ10格付けと情報セキュリティ会社の報告書が作成された基礎となるデータによっても確認されています。

注入は、入力データの検証が不十分で、週末の不適切な衛生状態でのみ可能です。これについては、上記で説明しました。 設定のエラーは、ベストプラクティスに従って脆弱性スキャナーを使用することで解決されます。

ウラジミール ：上で言ったように、セキュリティの問題の非常に重要な部分は、データの非効率的な前処理に関連しています。 これは、Positive Technologiesが公開している脆弱なWebアプリケーションの年次統計でも確認されています。 したがって、 2016年のデータによると、 ASP.NETアプリケーションの最も特徴的なのは、クロスサイトスクリプティング攻撃、資格情報の選択、および情報漏えいに対する脆弱性です。

-名前を付けられる.NETアプリケーションへの攻撃に対抗する最も効果的な方法は何ですか？

Michael ：通常、ソフトウェアメーカーの目標は攻撃と戦うことではなく、安全なアプリケーションを開発し、ユーザーデータの機密性を保証することです。 したがって、セキュリティでは、攻撃ではなく保護の観点からアプローチする必要があります。

安全なアプリケーションの開発は、何よりもまず思慮深いリスク管理です。 開発者の資格のおかげで、「偶然」で最も安全なアプリケーションを開発することはできません。 アプリケーションの各コンポーネントのセキュリティレベルは同じ要件であり、その実現には開発段階とテスト段階の両方でリソースが必要です。 各コンポーネントに対する攻撃のリスクの価格を理解し、これに基づいて、このリスクの防止に費やす努力を決定する必要があります。 そして、いずれにせよ、リスクが実現した場合の行動計画、すなわち アプリケーションが正常に攻撃されました。

まだ追加の費用が必要な場合は、体系的なアプローチが重要です。 セキュア開発ライフサイクル（SDL）技術を開発プロセスに体系的に導入し、社内の開発文化を改善する必要があります：製品レビュープロセスにセキュリティレビューステージを追加し、セキュアアプリケーションを作成するためのベストプラクティスを開発および実装し、社内の開発者をトレーニングし、その段階でセキュリティに注意を払いますテスト、侵入テスト（内部および外部の両方）を実施し、常に「ホワイトボックス」スキャナーと「ブラックボックス」スキャナーを使用して、可能な限り脆弱性を見つけるプロセスを自動化し、 Webアプリケーションファイアウォール（WAF）の使用などの予防措置。

ウラジミール ：.NETの仕様に関係なく、アプリケーションのセキュリティを確保するための一般原則は次のとおりです。

• ソフトウェア開発サイクル全体にSSDL（Secure Software Developent Lifecycle）を組み込む。
• コードの欠陥と戦うために開発者に焦点を合わせます。
• 運用段階でのアプリケーションレベルのファイアウォールの使用。

さらに、.NETアプリケーションの開発者は、 OWASP .NETセキュリティチートシートと、暗号化の偏りがある.NETアプリケーションのセキュリティ保護の詳細を明らかにするStan Drapkin のすばらしい本「Security Driven .NET」に特に注意を払う必要があります。

-独自の.NETアプリケーションのハッキングに遭遇しましたか？ もしそうなら、これについてもっと教えてください。 たぶん、おなじみの開発者のアプリケーションで同様の状況に関するいくつかのケースを伝えることができますか？

マイケル ：面白い例はありませんでした。 最初に思い浮かぶのは、SCADA Strangeloveチームによる研​​究で、Siemens WinCC SCADA / HMIシステムに対する攻撃を「シミュレート」しました。 WinCC Web Navigatorサーバーは.NETプラットフォームで記述されており、研究者はXPathインジェクション、パストラバーサル、20以上のXSS、CSRF、SQLiなどの脆弱性を発見しました。 これらの脆弱性を使用して、実世界のように、攻撃者が攻撃されたネットワークの境界の背後にいる場合、実際のSCADAシステムに対する攻撃がどのように見えるかを提案しました。 この攻撃に関するPHDaysからのレポートを見ることができます。

Vladimir ：最も記憶に残るケースは、2014年5月のRSDN.org Webサイトのフォーラムのユーザーに対する攻撃でした。そのエンジンは現在ASP.NET MVCで実行されています。 モデレートポリシーに腹を立てた常連の1人は、他のユーザーの資格情報を徹底的に総当たり攻撃し、それらを使用して無意味なメッセージまたはin辱的なメッセージの雪崩を公開しました。 当時、サイトエンジンは使用するパスワードの複雑さを制御する手段を使用していなかったため、攻撃者は攻撃が停止する前に12個以上のアカウントのパスワードを取得することができました。 登録およびパスワード変更フォームでは、その複雑さの制御が実装され、攻撃者が取得したアカウントを持つユーザーのパスワードがリセットされました。

その後、ユーザーパスワードハッシュのデータベースを取得し、〜250Kの要素の辞書を使用してパスワード選択に対してオフライン攻撃を実行しました。 その結果、その時点で登録された83,015人のユーザーが11,017人を占め、そのパスワードは妥当な時間内に見つかりました。 パスワードもリセットされ、パスワード回復手順を実行する必要があるという通知がメールに送信されました。

このすべての後、攻撃者がまだログインに管理しているアカウントと、攻撃の整理に使用した認証Cookieを使用する機会があったことは注目に値します。 実際のところ、ASP.NET認証トークンは、いわゆる 「切断された認証」は、ASP.NETの設計により、特定のユーザーからそれを思い出すことなく、一生有効です。

したがって、影響を受けるユーザーのパスワードを変更した後でも、攻撃者はまだ認証トークンを使用していたため、将来これらのユーザーの下に自由に入力できます。 彼が利用できるすべてのトークンを無効にするには、認証チケットの暗号化に使用するマシンキーを変更する必要がありました。これにより、以前に発行されたすべてのトークンが使用できなくなり、すべてのサイトユーザーの強制的な大量再認証の理由になりました。

-.NET Frameworkを使用して100％安全なアプリケーションを作成することは可能ですか？ これには何が必要ですか？

マイケル ：いいえ。 どのプラットフォームでも100％安全なアプリケーションを作成することはできません。 魔法と悪魔との取引を使用して100％安全なアプリケーションを作成すると、さらに悪いことに、100％安全であることを証明することはできません！ セキュリティ要件を含め、十分な時間で重要なアルゴリズムを検証することは理論的に不可能です。

安全なアプリケーションの開発は、エラーをまったく含まないアプリケーションを開発する特別なケースです。 すべての開発者は、これが達成不可能な理想的な結果であることを直感的に理解していると思います。 さらに、アプリケーションは、セキュリティも保証されていないサードパーティライブラリを使用し、OSおよびハードウェア上で実行されます。

多くの場合、どのOSとどのハードウェアかさえわかりません。 そして、これらはすべて時間の経過とともに変化します！ 100％に到達しようとする試みは、非常に多くの未知数で失敗する運命にあると思います。

私の意見では、.NET Frameworkは安全なアプリケーションを構築するのに適した選択肢です。 私はすでに.NET Coreに賭けていました。 これは、セキュアなシステムの開発に豊富な経験を持つ大企業がサポートする、小さなクロスプラットフォームのオープンソースフレームワークです。 最後のフレーズについてはLinuxの懐疑論が予想されます:)発見され修正された脆弱性の統計に入らない場合、「Windows vs. Linux」はZeroNightsの 1つであり、最終的に聴衆はそれがより安全なプラットフォームであると判断しました...大多数がWindowsに投票しました！

ウラジミール ：少し夢見て、これが本当に可能であると想像してみましょう。 言い換えれば、ルールの有限セットがあると仮定します。これにより、開発者は出力で安全なアプリケーションを受け取ることが保証されます。 そのような各ルールは何ですか？ これは、開発者のアクションを段階的に説明して、開発者のための安全なアプリケーションを作成する特定のアルゴリズムです。 すでに合意したように、このようなアルゴリズムのセットはすべて有限であるため、列挙可能および決定可能です。 このセットの補完、つまり アプリケーションのセキュリティに影響を与えない、理論的に可能な他の多くのアルゴリズム。 明らかに、それは無限であり、非常に特定の非自明で不変のプロパティの存在に基づくアルゴリズムが含まれています。 そしてこれは、ライスの定理では解決できないことを意味します。 しかし、それは解決不可能であるため、ポスト定理の結果としての補完（つまり、安全なアプリケーションを開発するための非常に多くのルール）は列挙できません。 したがって、有限にすることはできません。

理論面から適用面に移行すると、制御コードと厳密な型制御の概念により、.NET開発者は、メモリ破損、nullポインターの逆参照、フォーマット文字列、型の混合などに関連する低レベルのセキュリティ問題について考える必要がなくなります。 ただし、データの前処理、アクセス制御、およびリソースへのマルチスレッドアクセスに関連するすべての高レベルのセキュリティ上の欠陥は依然として可能です。 ビジネスロジックの欠点は言うまでもなく、現時点では明確な分類や正式なモデルさえ存在しないため、それらを回避する方法に関する推奨事項はありません。

-あなたの意見では、セキュリティの観点から.NETに欠けているものは何ですか？

マイケル ：プログラマーがこのデータが挿入されるコンテキストを考えないように、データをサニタイズするプロセスを開発者にとってより透過的にしたいと考えています。 これは現在のアプローチで部分的に実装できます。 たとえば、cshtmlページのパーサーは、データが挿入されるコンテキストを認識します。つまり、解析ツリーの現在のノードのネストされたすべての文法を認識します。 これは、注入の理論的な可能性さえも回避するために、このコンテキストでデータを正しくサニタイズできることを意味します。 プログラマーはこれを処理し、適切な衛生アルゴリズムを選択する必要があります。 エンコーダーの呼び出しまたは一連の呼び出し。

.NET Coreは完全にオープンなプロジェクトであるため、近い将来、少なくともこのアイデアの概念実証実装に私の手が届くことを願っています。 または、読者の誰もがこのアイデアを取り上げてそれを実装してくれれば幸いです。

次に、セッションデータを保護します。 この問題は、「大きな」.NET Framework以来知られています。 .NET Coreでは、少し悪化し、攻撃者はセッション固定攻撃を実行する機会が増えました。 これについては、DotNext 2017 Moscowのレポート「ASP.NET Core：Attack Prevention Mechanisms 2.0」で数日以内に詳しく説明します 。

そして3番目に、私の意見では、ASP.NETテンプレートは、安全なシステムを開発するための適切なアプローチを教え込むために、デフォルトでWebアプリケーションを書く際に最高のセキュリティパターンを課すべきです。 基本的に、含まれて適切に構成されたCSP、すべてのPOST / PUT / DELETE要求に対するCSRF保護、サーバー応答にセキュリティヘッダーを追加するなど、小さな変更が必要です。 ただし、多くの場合、これらの小さなものが存在しないことが、アプリケーションへの攻撃を成功させる可能性があります。

ウラジミール ：まず第一に、セキュリティに関連し、フレームワークの最初のバージョンから持続する「小児疾患」の排除。 少なくともBinarySerializer（同じRemotingで使用）を取得します。 デシリアライズするとき、このシリアライザーは、インスタンス化する前に、期待されるタイプとデシリアライズされたタイプをチェックしません。 これにより、攻撃者は任意の型をデシリアライザーに渡すことができ、その結果、この型のコンストラクターが実行され、そのすべてのプロパティが設定され、そのファイナライザーが後で実行されます。 これは、BinarySerializerを使用して入力データを逆シリアル化するアプリケーションにとって、攻撃者によって制御されるSMBサーバー上の任意のファイルおよびSSRFの削除に対する攻撃に対して無条件に影響を受けやすく、また（特定の条件が満たされた場合）任意のコードの実行に対する攻撃に対しても十分です： https://blog.scrt.ch/2016/05/12/net-serialiception/ BinarySerializerで、予想される型とデシリアライズされたBEFOREインスタンス化との対応の予備チェックを実装することを妨げるものは何もありません。 また、下位互換性のために現在の動作をオプションにします。

C＃について話すと、セキュリティの観点から見ると、組み込みのコントラクトプログラミングツールが実際にはありません。 少なくとも、Nemerle言語で実装されるレベルでは、どのメソッドまたはクラスに対しても関数を定義でき、メソッドの事前および事後条件の充足を確認したり、クラスの場合は不変式の制御を提供したりできます。 C＃では、さらに先へ進んで、そのような「厳格な」メソッドとクラスを定義し、「strict」タイプのキーワードでそれらをマークすることができます。そのためには、契約の明示的なチェックが必須です。 これは、データの前処理の欠点とビジネスロジックの脆弱性の両方に関連する問題の大部分をカバーします。