Oracle ADF Faces コンポーネントの属性値は、通常は、サーバーでのみ設定できます。ただし、多数のコンポーネントにより開発者はクライアント上で設定可能な属性のリストを定義できます。これらのコンポーネントの unsecure 属性によりこのようなリストを指定できます。

現在、unsecure 属性内に表示できる属性は、disabled のみです。この属性を使用して、クライアントはどのコンポーネントを有効または無効にするかを定義できるようになります。本来サーバーでのみ設定可能にする必要がある属性値を、クライアントが制御できるようにするのは良いアイデアではありません。

例 1: 次のコードは、ユーザーからパスワード情報を収集して unsecure 属性を使用する inputText コンポーネントを示しています。

...
    <af:inputText id="pwdBox"
                  label="#{resources.PWD}"
                  value=""#{userBean.password}
                  unsecure="disabled"
                  secret="true"
                  required="true"/>
...

Cookie は、RFC 2109 による厳格な HTTP メカニズムです。 Cookie が file:// を含む HTTP 以外のプロトコルに対して動作するはずがありません。 それらのプロトコルの動作や適用されるセキュリティ区分化のルールは不明です。 たとえば、インターネットからローカル ディスクにダウンロードされた HTML ファイルは、ローカルにインストールされた HTML コードと同じ cookie を共有するのでしょうか?

開発者がドキュメントに記載されていない、または非表示の API を使用してアプリケーションを構築することはお勧めしません。 Google がこれらの API を今後削除または変更しないという保証がないため、使用を避ける必要があります。そのようなメソッドやフィールドを使用すると、アプリケーションが破壊されるリスクが高くなります。

このコードは、Camera オブジェクトがすでに解放された後でこのオブジェクトの使用を試みます。リソースを再取得しないまま Camera オブジェクトをさらに参照すると例外が発生し、この例外がキャッチされない場合にはアプリケーションがクラッシュする可能性があります。

例 1: 次のコードは、トグル ボタンを使用してカメラのプレビューをオン/オフしています。ユーザーがこのボタンを 1 度押すと、カメラのプレビューは停止し、カメラのリソースは解放されます。ただし、再びボタンを押すと、以前に解放された Camera オブジェクトで startPreview() がコールされます。

public class ReuseCameraActivity extends Activity {
  private Camera cam;

  ...
  private class CameraButtonListener implements OnClickListener {
      public void onClick(View v) {
          if (toggle) {
              cam.stopPreview();
              cam.release();
          }
          else {
              cam.startPreview();
          }
          toggle = !toggle;
      }
  }
  ...
}

このコードは、メディアオブジェクトがすでに解放された後でこのオブジェクトの使用を試みます。リソースを再取得しないままこのメディアオブジェクトをさらに参照すると例外が発生し、この例外がキャッチされない場合にはアプリケーションがクラッシュする可能性があります。

例 1: 次のコードは、一時停止ボタンを使用してメディアの再生を切り替えています。ユーザーがこのボタンを 1 度押すと、楽曲または動画の再生が一時停止し、カメラ リソースは解放されます。ただし、再びボタンを押すと、以前に解放されたメディア リソースで start() がコールされます。

public class ReuseMediaPlayerActivity extends Activity {
  private MediaPlayer mp;

  ...
  private class PauseButtonListener implements OnClickListener {
      public void onClick(View v) {
          if (paused) {
              mp.pause();
              mp.release();
          }
          else {
              mp.start();
          }
          paused = !paused;
      }
  }
  ...
}

このコードは、Android SQLite データベースハンドラがすでに閉じられた後でこのオブジェクトの使用を試みます。データベース接続を再確立しないままハンドラをさらに参照すると例外が発生し、この例外がキャッチされない場合にはアプリケーションがクラッシュする可能性があります。

例 1: 次のコードは、ユーザー値を一時的にメモリにキャッシュするプログラムの一部だと考えられますが、ディスクへの変更をコミットするために flushUpdates() をコールすることができます。このメソッドは、データベースに更新を書き込んだ後、データベース ハンドラを適切に閉じます。しかし、再び flushUpdates() がコールされると、再初期化の前にデータベース オブジェクトが再び参照されます。

public class ReuseDBActivity extends Activity {
  private myDBHelper dbHelper;
  private SQLiteDatabase db;

  @Override
  public void onCreate(Bundle state) {
      ...
      db = dbHelper.getWritableDatabase();
      ...
  }
  ...

  private void flushUpdates() {
      db.insert(cached_data);     // flush cached data
      dbHelper.close();
  }
  ...
}

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

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

縮小化によってファイルサイズが減少するため、JavaScript ファイルを含むアプリケーションのページロード回数が向上します。縮小化とは、不用な空白、コメント、セミコロン、カッコを削除して、ローカル変数の名前を短縮し、使用しないコードを削除するプロセスです。

例 1: 次の ASPX コードには、Microsoft の jQuery ライブラリの縮小されていないバージョンが含まれています。

...
<script src="http://applicationserver.application.com/lib/jquery/jquery-1.4.2.js" type="text/javascript"></script>
...

正しい順序でミドルウェア パイプラインに追加されていない ASP.NET Core ミドルウェアは、意図したとおりに機能せず、その結果、アプリケーションはさまざまなセキュリティの問題にさらされたままになります。

例 1:UseCookiePolicy() メソッドは、Cookie ポリシー ミドルウェアをミドルウェア パイプラインに追加します。これにより、カスタマイズした Cookie ポリシーが許可されます。ここに示すように、間違った順序で指定されると、プログラマーによって指定された Cookie ポリシーはすべて無視されます。

...
var builder = WebApplication.CreateBuilder(...);
var app = builder.Build(...);
app.UseStaticFiles();
app.UseRouting();
app.UseSession();
app.UseAuthentication();
app.UseAuthorization();
app.UseEndpoints(endpoints =>
{
    ...
}

app.UseCookiePolicy();
...

正しい順序でミドルウェア パイプラインに追加されていない ASP.NET Core ミドルウェアは、意図したとおりに機能せず、その結果、アプリケーションはさまざまなセキュリティの問題にさらされたままになります。

例 1:UseHttpsRedirection() メソッドは、HTTPS リダイレクション ミドルウェアをミドルウェア パイプラインに追加します。これにより、安全でない HTTP リクエストを安全な HTTPS リクエストにリダイレクトすることが可能になります。ここに示すように、間違った順序で指定されると、リダイレクト前にリストされたミドルウェアを介したリクエスト処理の前に、意味のある HTTPS のリダイレクションは行われません。これにより、HTTP リクエストを、安全な HTTPS 接続にリダイレクトされる前にアプリケーションで処理できるようになります。

...
var builder = WebApplication.CreateBuilder(...);
var app = builder.Build(...);
app.UseStaticFiles();
app.UseRouting();
app.UseSession();
app.UseAuthentication();
app.UseAuthorization();
app.UseEndpoints(endpoints =>
{
    ...
}

app.UseHttpsRedirection();
...

正しい順序でミドルウェア パイプラインに追加されていない ASP.NET Core ミドルウェアは、意図したとおりに機能せず、その結果、アプリケーションはさまざまなセキュリティの問題にさらされたままになります。

例 1:UseHttpLogging() メソッドは、HTTP ロギング ミドルウェアをミドルウェア パイプラインに追加します。これにより、ミドルウェア コンポーネントによるログ記録が可能になります。ここに示すように、間違った順序で指定されると、UseHttpLogging() への呼び出しの前にパイプラインに追加されたミドルウェアはログを記録しません。

...
var builder = WebApplication.CreateBuilder(...);
var app = builder.Build(...);
app.UseStaticFiles();
app.UseRouting();
app.UseSession();
app.UseAuthentication();
app.UseAuthorization();
app.UseEndpoints(endpoints =>
{
    ...
}

app.UseHttpLogging();
...

例 2:UseWC3Logging() メソッドは、W3C ロギング ミドルウェアをミドルウェア パイプラインに追加します。これにより、ミドルウェア コンポーネントによるログ記録が可能になります。ここに示すように、間違った順序で指定されると、UseWC3Logging() への呼び出しの前にパイプラインに追加されたミドルウェアはログを記録しません。

...
var builder = WebApplication.CreateBuilder(...);
var app = builder.Build(...);
app.UseStaticFiles();
app.UseRouting();
app.UseSession();
app.UseAuthentication();
app.UseAuthorization();
app.UseEndpoints(endpoints =>
{
    ...
}

app.UseWC3Logging();
...

証明書の検証モードを 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> タグの属性) は、カスタムとデフォルトのどちらのエラー ページを使用するかを定義します。

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