Java Language Specification では、オブジェクトの finalize() メソッドを finalizer 外部からコールすることができます。通常は、これは良い考えではありません。たとえば、finalize() をコールすることは、finalize() が 2 回以上コールされることを明示的に意味しています。一回目は明示的なコールで、最後はオブジェクトがガベージコレクトされた後に行われるコールです。

例 1: 次のコードフラグメントは、finalize() を明示的にコールします。

// time to clean up
widget.finalize();

React の dangerouslySetInnerHTML 属性は、ブラウザー DOM での innerHTML の使用に代わるものです。API 名は、これを使用することによる潜在的な危険性を伝えるために変更されています。一般に、コードから HTML を設定することは危険です。ユーザーを誤って Cross-Site Scripting (XSS) 攻撃にさらす可能性が高いためです。
例 1: 次のコードは、HTML をコードから dangerouslySetInnerHTML 属性に設定します。

      function MyComponent(data) {
        return (
          <div
            dangerouslySetInnerHTML={{__html: data.innerHTML}}
          />
        );
      }
    

一般的に、Direct Open SQL 書き込み操作 (Insert/Update/Modify/Delete) は好ましくない方法ですので避けてください。これは、システムの完全性と安全性を台無しにするので使用すべきではありません。



Direct Open SQL 書き込み操作は、エラーを発生し易いので、システムが予期しない動作をする可能性があります。SAP で注意すべき問題は以下のとおりです。

- 複数のデータベース LUW にまたがる可能性がある SAP LUW (論理作業単位) 内でのデータの整合性を確保するために、「バンドルの更新」テクニックの使用をお勧めします。バンドルを更新せずにテーブル エントリを変更すると、SAP トランザクションが一貫性のないままになる可能性があります。

- Direct Open SQL 書き込み操作では、データベース レベルのロックのみを設定し、SAP アプリケーションのロックをバイパスします。これによって、デッドロックが発生し、データが破損する可能性があります。

- Direct Open SQL 書き込み操作では、アプリケーション プログラム内での SAP 認証チェックをバイパスします。

- テーブル エントリの書き込み、チェックの編集、監査トレールに標準のメカニズムが使用される場合、その後の更新 (たとえば、ドキュメントの変更など) のすべてが正しく実行されます。これは、Direct Open SQL 書き込み操作が使用される場合には該当しません。

実行者権限または AUTHID CURRENT_USER パッケージでは、現在のユーザースキーマに対して識別子が最初に解決されます。その結果、識別子がどのスキーマに属しているのかをコードの定義が明示していない場合、予期せぬ動作が引き起こされる可能性があります。

例: 次のコードは権限テーブルでユーザーを検索して、ユーザーがアクションを実行する権限を持っているかどうかを確認します。大半のユーザーは SYS.PERMISSIONS に対してのみ読み取りアクセスが許可されるようになり、定義済みの権限を変更できません。

CREATE or REPLACE FUNCTION check_permissions(
  p_name IN VARCHAR2, p_action IN VARCHAR2)
  RETURN BOOLEAN
  AUTHID CURRENT_USER
IS
  r_count NUMBER;
  perm BOOLEAN := FALSE;
BEGIN
  SELECT count(*) INTO r_count FROM PERMISSIONS
    WHERE name = p_name AND action = p_action;
  IF r_count > 0 THEN
    perm := TRUE;
  END IF;
  RETURN perm;
END check_permissions

check_permissions 関数をコールするユーザーがスキーマで PERMISSIONS テーブルを定義する場合、データベースが識別子を解決して、ローカルテーブルを参照します。ユーザーは新しいテーブルに対する書き込み権限を付与されるため、データベースを変更することによって本来付与されないはずの権限を取得できるようになります。

Apache Struts 2.x は、新しい Aware インターフェイスにより、開発者が、Actions コードに、関連する実行時情報を持つマップを容易に挿入できます。このインターフェイスには、org.apache.struts2.interceptor.ApplicationtAware、org.apache.struts2.interceptor.SessionAware、org.apache.struts2.interceptor.RequestAware があります。Actions コードに挿入されたこれらのデータマップのいずれかを取得するには、開発者は、インターフェイスで指定されたセッター (たとえば SessionAware インターフェイスでは setSession) を実装する必要があります。

public class VulnerableAction extends ActionSupport implements SessionAware {

  protected Map<String, Object> session;

  @Override
  public void setSession(Map<String, Object> session) {
    this.session = session;
  }

一方、Struts 2.x は、Action で定義されているパブリックアクセッサーにより、ユーザーから受信したリクエストデータを Action のプロパティに自動的にバインドします。Aware インターフェイスでは、そこで定義されたパブリックセッターの実装が必要なので、このセッターも自動的に、Aware インターフェイスのセッター名に一致するリクエストパラメーターにバインドされます。このことにより、SessionAware、RequestAware、ApplicationAware のインターフェイスで示したように、影響を受けたインターフェイスを実装しているアプリケーションに対する巧妙なパラメーターを使用して、リモートの攻撃者が実行環境のデータ値を修正する可能性があります。

次の URL では、攻撃者がセッションマップ中の "roles" 属性を上書きできるため、攻撃者が管理者として振る舞う可能性があります。

http://server/VulnerableAction?session.roles=admin


これらのインターフェイスは、セッターアクセッサーの実装のみを必要としますが、対応するゲッターも実装されている場合、マップコレクションに対する変更は、現在のリクエスト範囲のみでなく、セッション範囲にも及びます。

Struts 2 には「Dynamic Method Invocation」という機能があり、これにより Action によって execute() 以外のメソッドを開示できます。! (感嘆符) 文字または method: プレフィックスを Action URL に使用して、「Dynamic Method Invocation」が有効に設定されていれば Action でどの public メソッドでも呼び出すことができます。この機能を知らない開発者は、内部のビジネスロジックを攻撃者に対して無防備に開示してしまう可能性があります。

たとえば、Action に getUserPassword() という public メソッドが含まれており、何の引数もともなわず「Dynamic Method Invocation」機能を無効にできない場合、攻撃者はこれに目を付けて以下の URL を閲覧できます。 http://server/app/recoverpassword!getPassword.action

Apache Struts 2.x は、新しい Aware インターフェイスにより、開発者が、Actions コードに、関連する実行時情報を持つマップを容易に挿入できます。このインターフェイスには、org.apache.struts2.interceptor.ApplicationtAware、org.apache.struts2.interceptor.SessionAware、org.apache.struts2.interceptor.RequestAware があります。Actions コードに挿入されたこれらのデータマップのいずれかを取得するには、開発者は、インターフェイスで指定されたセッター (たとえば SessionAware インターフェイスでは setSession) を実装する必要があります。

public class VulnerableAction extends ActionSupport implements SessionAware {

  protected Map<String, Object> session;

  @Override
  public void setSession(Map<String, Object> session) {
    this.session = session;
  }

一方、Struts 2.x は、Action で定義されているパブリックアクセッサーにより、ユーザーから受信したリクエストデータを Action のプロパティに自動的にバインドします。Aware インターフェイスでは、そこで定義されたパブリックセッターの実装が必要なので、このセッターも自動的に、Aware インターフェイスのセッター名に一致するリクエストパラメーターにバインドされます。このことにより、SessionAware、RequestAware、ApplicationAware のインターフェイスで示したように、影響を受けたインターフェイスを実装しているアプリケーションに対する巧妙なパラメーターを使用して、リモートの攻撃者が実行環境のデータ値を修正する可能性があります。

次の URL では、攻撃者がセッションマップ中の "roles" 属性を上書きできるため、攻撃者が管理者として振る舞う可能性があります。

http://server/VulnerableAction?session.roles=admin


これらのインターフェイスは、セッターアクセッサーの実装のみを必要としますが、対応するゲッターも実装されている場合、マップコレクションに対する変更は、現在のリクエスト範囲のみでなく、セッション範囲にも及びます。