Android アプリケーションは、デバッグ バイナリを生成するように設定できます。これらのバイナリは詳細なデバッグ メッセージを提供するため、実運用環境では使用しないでください。debuggable 属性 (<application> タグの属性) は、コンパイルされたバイナリにデバッグ情報を含めるかどうかを定義します。

デバッグ バイナリを使用すると、アプリケーションが、それ自体に関するできるだけ多くの情報をユーザーに提供します。デバッグ バイナリは、開発環境またはテスト環境で使用することを目的としており、実運用環境にデプロイするとセキュリティ リスクを引き起こす可能性があります。攻撃者はデバッグ出力から得た追加情報を利用して、フレームワークやデータベースなど、アプリケーションで使用されるリソースを標的に攻撃を仕掛けることがあります。

証明書の検証モードを None に設定すると、証明書の検証プロセス全体が無効になり、アプリケーションを中間者 (Man-in-the-Middle) 攻撃の危険にさらすことになります。このモードは、実運用環境では使用しないでください。

cookie は通常、個人情報、認証トークン、ユーザーのアクティビティの履歴など、ユーザーに関する重要な情報を保存するために使用されます。この情報が平文で保存されていると、アプリケーションとの対話に使用されるマシンにアクセスできる人であれば、誰でも cookie に保存されている情報にアクセスできます。さらに、攻撃者が cookie に保存されているデータを任意に変更することを許可されている場合、攻撃者はアプリケーションに提供された情報を改ざんし、その動作を思いどおりに変更できてしまいます。

多くの場合、アプリケーションは cookie からの入力を、使用されるコンテキストに応じてプログラミングで検証できますが、ASP.NET の検証フレームワークは、cookie の内容を保護し、cookie に想定外の変更が加えられていないことを確認するための優れた手法を提供します。このアプローチがなければ、すべての入力が検証されていることを高いレベルの信頼性で確立することは困難であり、多くの場合不可能です。

ASP.NET アプリケーションは、デバッグ バイナリを生成するように設定できます。これらのバイナリは詳細なデバッグ メッセージを提供するため、実運用環境では使用しないでください。debug 属性 (<compilation> タグの属性) は、コンパイルされたバイナリにデバッグ情報を含めるかどうかを定義します。

デバッグ バイナリを使用すると、アプリケーションが、それ自体に関するできるだけ多くの情報をユーザーに提供します。デバッグ バイナリは、開発環境またはテスト環境で使用することを目的としており、実運用環境にデプロイするとセキュリティ リスクを引き起こす可能性があります。攻撃者はデバッグ出力から得た追加情報を利用して、フレームワークやデータベースなど、アプリケーションで使用されるリソースを標的に攻撃を仕掛けることがあります。

セッションを開いたままの時間が長いほど、攻撃者がユーザー アカウントを侵害するチャンスは増えます。セッションをアクティブなままにしておくと、攻撃者がユーザーのパスワードを総当たり攻撃で盗んだり、ユーザーのワイヤレス暗号鍵を解読したり、開いているブラウザーからセッションを乗っ取る可能性があります。認証タイムアウトが長くなると、メモリが解放されなくなり、作成されるセッションが多くなりすぎて最終的に Denial of Service 攻撃が発生する可能性があります。

例 1: 次の例は、認証タイムアウトが 1 時間に設定された ASP.NET MVC を示しています。

...
<configuration>
  <system.web>
  <authentication>
    <forms
      timeout="60" />
  </authentication>
  </system.web>
</configuration>
...

タイムアウト属性が指定されていない場合、認証タイムアウトのデフォルト値は 30 分です。

プログラムは、3 つの方法のいずれかで X.509 証明書を検証するように設定できます。デフォルトでは、証明書は信頼チェーンを介して検証され、信頼されたルート機関に戻ります。この設定は ChainTrust と呼ばれ、証明書が有効であることを最大レベルで保証します。デフォルトでは、すべての証明書は ChainTrust を使用して検証されます。

信頼されたルート機関が発行したものではない証明書を利用するには、PeerTrust または PeerOrChainTrust を設定することで、ピアが発行した証明書を信頼するようにプログラムを設定できます。これらの設定は、証明書によって付与されるセキュリティのレベルを大幅に低下させるため、実運用環境では使用しないでください。

cookie は通常、個人情報、認証トークン、ユーザーのアクティビティの履歴など、ユーザーに関する重要な情報を保存するために使用されます。この情報が平文で保存されていると、アプリケーションとの対話に使用されるマシンにアクセスできる人であれば、誰でも cookie に保存されている情報にアクセスできます。さらに、攻撃者が cookie に保存されているデータを任意に変更することを許可されている場合、攻撃者はアプリケーションに提供された情報を改ざんし、その動作を思いどおりに変更できてしまいます。

多くの場合、アプリケーションは cookie からの入力を、使用されるコンテキストに応じてプログラミングで検証できますが、ASP.NET の検証フレームワークは、cookie の内容を保護し、cookie に想定外の変更が加えられていないことを確認するための優れた手法を提供します。このアプローチがなければ、すべての入力が検証されていることを高いレベルの信頼性で確立することは困難であり、多くの場合不可能です。

web.config にある configuration/system.web/authentication/forms 要素の cacheRolesInCookie 属性が true に設定されている場合、各ユーザーのロールは cookie にキャッシュされます。この情報が平文で保存されていると、アプリケーションとの対話に使用されるマシンにアクセスできる人であれば、誰でも cookie に保存されている情報にアクセスできます。さらに、攻撃者が cookie に保存されているデータを任意に変更することを許可されている場合、攻撃者はアプリケーションに提供された情報を改ざんし、その動作を思いどおりに変更できてしまいます。

多くの場合、アプリケーションは cookie からの入力を、使用されるコンテキストに応じてプログラミングで検証できますが、ASP.NET の検証フレームワークは、cookie に想定外の変更が加えられていないことを確認するための優れた手法を提供します。このアプローチがなければ、すべての入力が検証されていることを高いレベルの信頼性で確立することは困難であり、多くの場合不可能です。

ASP.NET Web サービスは、Web サービスとの通信方法を説明するドキュメントを自動的に生成することにより、Web サービス クライアントの開発を容易にします。

ドキュメント プロトコルが有効になっている Web サービスは、ブラウザーのリクエストを受信すると HTML 形式のページを生成します。

この HTML 形式のページでは、次の情報について説明しています。
1.サポートされている操作
2.各操作が受け入れるパラメーター
3.これらのパラメーターで渡される必要があるデータのタイプ

ドキュメント プロトコルは、XML 形式の Web サービス記述言語 (WSDL) ファイルも生成します。このファイルは、アプリケーションが Web サービスへのリクエストを構造化する方法を理解できるように設計されています。この情報は、開発者、特にパブリック Web サービスのクライアントを作成する開発者にとって非常に役立ちます。しかし、プライベート Web サービスの機能に関する詳細情報を公開すると、悪意のある攻撃者が Web サービスを悪用するリスクが高まります。ドキュメント プロトコルは、Web サービスのすべての関数とパラメーターを必ず記述します。これは、それらの関数のサブセットのみをパブリック アクセス可能にすることが意図されている場合も同じです。

ASP.NET アプリケーションを、フレームワークのデフォルトのページではなく、カスタム エラー ページを使用するように設定する必要があります。デフォルトのエラー ページには発生したエラーに関する詳細情報が表示されるため、実運用環境では使用しないでください。mode 属性 (<customErrors> タグの属性) は、カスタムとデフォルトのどちらのエラー ページを使用するかを定義します。

攻撃者は、デフォルトのエラー ページから得た追加情報を利用して、フレームワークやデータベースなど、アプリケーションで使用されるリソースを標的に攻撃を仕掛けることがあります。

デフォルトでは、ASP.NET は、ペイロード (ViewState、FormsAuth cookies、ScriptResource.axd URL など) を復号化する前に暗号シグネチャを内部的に検証し、得た値をアプリケーションに渡してさらに処理します。ただし、この機能を aspnet:UseLegacyEncryption 設定を使用して変更し、ペイロードを復号化する前に暗号シグネチャの検証を無効にすることが可能です。これにより、悪意のあるクライアントが暗号化されたデータを復号化、偽造、または改ざんする可能性があります。

例 1: 次の例では、aspnet:UseLegacyEncryption が true に設定されています。

...
  <appSettings>
    <add key="aspnet:UseLegacyEncryption" value="true" />
  </appSettings>
...

ASP.NET アプリケーションは、ユーザー名とパスワードのペアを、ASP.NET アプリケーションの web.config ファイルにある <credentials> 要素に格納できます。パスワード形式は、平文、MD5、および SHA1 がサポートされます。

平文または弱い暗号化アルゴリズムを使用して保存されたパスワードは、アプリケーションの設定ファイルにアクセスできる人なら誰でもアクセスできます。これには、アプリケーションがホストされているマシンや、アプリケーションがあるソース コード リポジトリなどが含まれます。

例 1: 以下の web.config エントリは、パスワードを誤って平文で保存しています。

<configuration>
  <system.web>
    <authentication>
      <forms protection="All">
	   <credentials passwordFormat="Clear">
   		<user name="user1" password="my_password"/>
		<user name="user2" password="my_password1"/>
        </credentials>
    	 </forms>
    </authentication>
  </system.web>
</configuration>

ASP.NET は、configuration/system.web/authentication/forms/credentials 要素の passwordFormat 属性で指定される、3 つの形式で保存された資格情報パスワードをサポートしています。この属性に使用できる値は次のとおりです。

Clear - パスワードが平文で保存されていることを示します (最も安全性が低い)
MD5 - パスワードの MD5 ハッシュが保存されていることを示します
SHA1 - パスワードの SHA1 ハッシュが保存されていることを示します (最も安全性が高い)

MD5 ハッシュは平文よりも安全ですが、研究者によると、MD5 ハッシュ アルゴリズムに対するブルートフォース攻撃も発見されています。現時点で、SHA1 ハッシュは、引き続きこのような攻撃に対して適切な保護を提供しています。

ASP.NET アプリケーションの脆弱性の主要な原因は、未検証の入力です。Cross-Site Scripting、Process Control や SQL Injection などのさまざまな脆弱性の原因は入力の未検証です。

そのような攻撃を防止するため、ASP.NET 検証フレームワークを使用してすべてのプログラム入力を確認してからアプリケーションに処理させます。

検証フレームワークの使用例には、次の点を確認する検証が含まれます。

- 電話番号フィールドには、電話番号で有効な文字だけが含まれる。
- ブール値は「T」と「F」のいずれかだけである。
- 自由入力の文字列は適切な長さと形式にする。

web.config にある configuration/system.web/authentication/forms 要素の cacheRolesInCookie 属性が true に設定されている場合、各ユーザーのロールは cookie にキャッシュされます。この情報が平文で保存されていると、アプリケーションとの対話に使用されるマシンにアクセスできる人であれば、誰でも cookie に保存されている情報にアクセスできます。さらに、攻撃者が cookie に保存されているデータを任意に変更することを許可されている場合、攻撃者はアプリケーションに提供された情報を改ざんし、その動作を思いどおりに変更できてしまいます。

多くの場合、アプリケーションは cookie からの入力を、使用されるコンテキストに応じてプログラミングで検証できますが、ASP.NET の検証フレームワークは、cookie に想定外の変更が加えられていないことを確認するための優れた手法を提供します。このアプローチがなければ、すべての入力が検証されていることを高いレベルの信頼性で確立することは困難であり、多くの場合不可能です。

ほとんどの Web アプリケーションは、セッション ID を使用してユーザーを一意に識別します。これは通常 cookie に保存され、サーバーと Web ブラウザー間で透過的に送信されます。


属性の値が true または UseUri に設定されている場合、ブラウザーまたはデバイスが cookie をサポートしているかどうかに関係なく、アプリケーションは cookie を使用しません。属性の値が AutoDetect または UseDeviceProfile に設定されている場合、要求元のブラウザーまたはデバイスの構成によっては cookie が使用されません。

セッション ID を cookie に保存しないアプリケーションは、HTTP リクエスト パラメーターとして、または URL の一部としてセッション ID を送信することがあります。URL で指定されたセッション ID を受け入れると、攻撃者はセッション ID 固定化攻撃を実行しやすくなります。

URL にセッション ID を含めると、アプリケーションに対するセッション ハイジャック攻撃の成功率も高くなります。セッション ハイジャック攻撃は、攻撃者が被害者のアクティブなセッションまたはセッション ID を制御すると発生します。Web サーバー、アプリケーション サーバー、および Web プロキシが要求された URL を保存するのは一般的な動作です。セッション ID が URL に含まれている場合、それらはログにも記録されます。セッション ID が表示および保存される場所が増えると、攻撃者に侵害される可能性も高くなります。

ASP.NET アプリケーションは、トレースデバッグ情報を出力するように設定できます。Trace Output には、現在のページに対して行われたリクエスト、ヘッダー情報、ページで使用されたメソッドおよびコントロール、そしてアクティブセッションの状態が含まれます。攻撃者はトレース出力から得た追加情報を利用して、フレームワークやデータベースなど、アプリケーションで使用されるリソースを標的に攻撃を仕掛けることがあります。

トレース情報は、<page> ディレクティブの Trace 属性を true に設定することによってページ レベルで有効にするか、web.config ファイルに trace 要素を追加し、enabled 属性を true にすることによってアプリケーション レベルで有効にします。

偽装された資格情報を使用すると、ASP.NET アプリケーションを、実行しているクライアントの特権、またはその設定で付与された任意の特権のいずれかで実行できます。

ASP.NET アプリケーションは、ユーザー名とパスワードのペアを、ASP.NET アプリケーションの web.config ファイルにある <credentials> 要素に格納できます。パスワード形式は、平文、MD5、および SHA1 がサポートされます。

平文または弱い暗号化アルゴリズムを使用して保存されたパスワードは、アプリケーションの設定ファイルにアクセスできる人なら誰でもアクセスできます。これには、アプリケーションがホストされているマシンや、アプリケーションがあるソース コード リポジトリなどが含まれます。

例 1: 以下の web.config エントリは、パスワードを誤って平文で保存しています。

<configuration>
  <system.web>
    <authentication>
      <forms protection="All">
	   <credentials passwordFormat="Clear">
   		<user name="user1" password="my_password"/>
		<user name="user2" password="my_password1"/>
        </credentials>
    	 </forms>
    </authentication>
  </system.web>
</configuration>

ASP.NET は、configuration/system.web/authentication/forms/credentials 要素の passwordFormat 属性で指定される、3 つの形式で保存された資格情報パスワードをサポートしています。この属性に使用できる値は次のとおりです。

Clear - パスワードが平文で保存されていることを示します (最も安全性が低い)
MD5 - パスワードの MD5 ハッシュが保存されていることを示します
SHA1 - パスワードの SHA1 ハッシュが保存されていることを示します (最も安全性が高い)

MD5 ハッシュは平文よりも安全ですが、研究者によると、MD5 ハッシュ アルゴリズムに対するブルートフォース攻撃も発見されています。現時点で、SHA1 ハッシュは、引き続きこのような攻撃に対して適切な保護を提供しています。

カスタマーマネージド キーは、保存データの暗号化には使用されません。

デフォルトでは、暗号化が有効になっている場合、AWS は AWS が管理するキーを使用して保存データを暗号化します。カスタマーマネージド キーを使用すると、組織は、選択した暗号鍵を使用してデータを暗号化できます。これにより、組織は暗号化プロセスをより適切に制御し、ログに記録できます。

そのため、カスタマーマネージド キーは通常、次のような要件 (これに限らない) に対処するソリューションの一部です。
- 機密データへのアクセスの監査ログ
- データ所在地
- キーの交換、無効化、または破棄

aws/service-name 形式のキーは、AWS 管理のキー用に予約されていることに注意してください。

アクセス設定が緩いと、システムが公開され、組織の攻撃対象領域が広がる可能性があります。一般に公開されているサービスは、通常、悪意のあるエンティティによるほぼ継続的なスキャンとプロービングの対象になります。

これは、公開されたサービスのゼロデイ エクスプロイトが発見され、公表された場合 (Heartbleed など) に、特に問題になります。攻撃者は、パッチが適用されていない、公開されたシステムを積極的に追跡、検索して、それを悪用できます。