データベースの Access Control エラーが発生するのは次の場合です。

1. 信頼できないソースからデータがプログラムに入り込んだ場合。

2. データが LDAP クエリのデータ値を指定するために使用される場合。
例 1: 現在認証されているユーザーの従業員 ID は、クライアントサイドインターフェイスからの各リクエストで自動的に送信されます。次のコードは、LDAP クエリの構築に使用する前に、整数として従業員 ID を適切に検証します。この検証により、LDAP Injection の脆弱性を防ぐことができますが、コードは脆弱なままとなります。

...
env.put(Context.SECURITY_AUTHENTICATION, "none");
DirContext ctx = new InitialDirContext(env);

String empID = request.getParameter("empID");

try
{
  int id = Integer.parseInt(empID);

  BasicAttribute attr = new BasicAttribute("empID", empID);

  NamingEnumeration employee =
            ctx.search("ou=People,dc=example,dc=com",attr);
...

この問題は、開発者が empID に攻撃者が別の値を指定したときにどのような動作が起こりうるかを検討していない点にあります。このインターフェイスは、現在のユーザーの従業員 ID を自動的に送信しますが、攻撃者は悪意あるリクエストの一部として別の値を送信できる場合があります。この例のコードは、匿名バインドでクエリを実行しているため、現在認証されているユーザーの ID に関わらず、すべての有効な従業員 ID のディレクトリエントリを返します。

直接呼び出し元のクラスローダーチェックを使用してタスクを実行するJava APIは、注意して使用する必要があります。これらのAPIは、実行チェーン内のすべての呼び出し元が必要なセキュリティ権限を持っていることを確認するSecurityManagerチェックをバイパスします。直接呼び出し元のクラスローダーだけにアクセスチェックを実行すると権限昇格の問題が発生し、実行チェーン内の一部の呼び出し元が必要な権限なしでリソースにアクセスできる可能性があります。したがって、これらの API は信頼のないコードで呼び出すべきではありません。システムのセキュリティを損なう恐れがあります。



信頼のないソースから、または信頼のない環境内のJava AppletはこれらのAPIにアクセスし、悪意のあるコードを実行してシステムのセキュリティを損ないます。

単一の <security constraint> 要素は、プログラムがロールベースのアクセス制御を採用していないことを示しています。これは、安全な Web アプリケーションで機密性の高い操作を保護するため、一般的に受け入れられているベスト プラクティスです。アプリケーションが機密性の高い操作やデータへのアクセスを提供している場合に、権限のないユーザーによるアクセスを防ぐための十分な制御策が講じられていないことがあります。さらに、<url-pattern> にワイルドカード (*) が含まれている場合、パターンが広すぎることを示している可能性があります。

AccessibleObject API によって、プログラマは Java アクセス指定子によって行われる Access Control チェックを回避できます。特に、これによってプログラマは、反映されたオブジェクトが Java Access Control を迂回することでプライベートフィールドの値を変更するかまたはプライベートメソッドを呼び出せるようにすることができます。通常これらは許可されない挙動です。

多くのアプリケーションは、cookie を使用してユーザーのセッション ID を伝達します。アプリケーションが HTTPS 経由でアクセスされる場合、cookie は保護されます (攻撃者は cookie を盗聴できません)。ただし、開発者が、アプリケーションの機密性の低い部分への HTTP アクセスを許可すると、セッション ID が盗まれる可能性があります。ユーザーがサイトの保護されていない部分を閲覧すると、セッション ID を含む cookie が平文で送信されます。攻撃者は、トラフィックの盗聴時にセッション ID を閲覧し、それを使用してユーザーのセッションを制御します。


次の例は、安全でないチャネルと安全なチャネルが混在した設定を示しています。

  <property name="filterInvocationDefinitionSource">
    <value>
      CONVERT_URL_TO_LOWERCASE_BEFORE_COMPARISON
      \A/secure/.*\Z=REQUIRES_SECURE_CHANNEL
      \A/acegilogin.jsp.*\Z=REQUIRES_SECURE_CHANNEL
      \A/j_acegi_security_check.*\Z=REQUIRES_SECURE_CHANNEL
      \A.*\Z=REQUIRES_INSECURE_CHANNEL
    </value>
  </property>

Acegi Security では、セキュア オブジェクトのコールバック フェーズ中に、SecurityContext の Authentication オブジェクトを一時的に置き換えることができます。これは、元の Authentication オブジェクトが AuthenticationManager および AccessDecisionManager によって正常に処理された場合にのみ発生します。RunAsManager はこの認証オブジェクトを作成します。
通常開発者は、メソッド呼び出しの間、RunAsManager を使用して、認証済みユーザー用に 1 つ以上の追加のロールを設定します。これは、リモート アプリケーションへのアクセスが必要なセキュア Bean に役立ちます。リモート アプリケーションは異なる資格情報を要求する場合があるため、これにより、呼び出し元のロールとリモート アプリケーションに必要なロールを変換して、リモート アクセスを成功させることができます。新しい Authentication オブジェクト (RunAsUserToken と呼ばれる) は、それ以上の認証または承認のチェックを受けずに、有効な Authentication オブジェクトとしてそのまま受け入れられます。
新しい Authentication オブジェクトに新しいロールまたは特権を追加すると、ユーザーの特権が一時的に引き上げられ、ユーザーが不正なアクションを実行できるようになる可能性があります。
次の設定は、RunAsManager を使用してロール "ROLE_PEON" を持つユーザーにロール "UBER_BOSS" を追加することで、このユーザーの権限を一時的にマネージャー特権に引き上げます。これにより、すべての Peon が PrivateCatalog からデータを取得できるようになります。

<bean id="bankManagerSecurity" class="org.acegisecurity.intercept.method.aopalliance.MethodSecurityInterceptor">
...
 <property name="objectDefinitionSource">
   <value>
     com.example.service.PrivateCatalog.getData=ROLE_PEON,RUN_AS_UBER_BOSS
...
   </value>
 </property>
</bean>

デフォルトでは、Fusion アプリケーションのタスク フローは GET リクエストから直接アクセスできません。URL がタスク フローを呼び出そうとするたびに、HTTP 403 ステータス コードを受け取ります。しかし、暗黙的な設定に依存すると明確性に欠け、デフォルト設定が変更された場合、望ましくない動作が発生する可能性があります。

例 1: タスク フロー定義ファイルの次のスニペットは、暗黙のデフォルト url-invoke-disallowed 設定を使用して設定されたタスク フローの例を示します。

...
    <task-flow-definition id="password">
        <default-activity>PasswordPrompt</default-activity>
        <view id="PasswordPrompt">
            <page>/PasswordPrompt.jsff</page>
        </view>
        <use-page-fragments/>
    </task-flow-definition>
...