次の場合に SQL Injection エラーが発生します。

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

この場合、データのソースが信頼できると Fortify Static Code Analyzer は判断できません。

2. データが SQL クエリの動的な構築に使用された場合。

例 1: 次のコードは、指定された名前に一致するアイテムを検索する SQL クエリを動的に構築し、実行します。このクエリでは、認証済みユーザーのユーザー名と所有者が一致するアイテムだけが表示されます。

...
        String userName = ctx.getAuthenticatedUserName();
        String itemName = request.getParameter("itemName");
        String query = "SELECT * FROM items WHERE owner = '"
                                + userName + "' AND itemname = '"
                                + itemName + "'";
        ResultSet rs = stmt.execute(query);
...

このコードによって実行されるクエリは次のようになります。

        SELECT * FROM items
        WHERE owner = <userName>
        AND itemname = <itemName>;

ただし、クエリは定数ベースのクエリ文字列とユーザー入力の文字列を連結して動的に構築されるため、itemName に単一引用符が含まれない場合のみクエリは正しく動作します。ユーザー名 wiley を持つ攻撃者が文字列「name' OR 'a'='a」を itemName に入力すると、クエリは次のようになります。

        SELECT * FROM items
        WHERE owner = 'wiley'
        AND itemname = 'name' OR 'a'='a';

OR 'a'='a' 条件を追加すると、where 句は常に真 (true) の評価をします。そのため、このクエリは次のような単純なクエリと論理的に等しくなります。

        SELECT * FROM items;

このクエリの単純化により攻撃者は、クエリが返すのは認証済みユーザーが所有するアイテムのみでなければならないという要件を回避できます。クエリは、特定の所有者に関係なく、items テーブルに格納されているすべてのエントリを返すようになりました。

例 2: この例では、Example 1 で構築および実行されたクエリに悪意のある別の値が渡された場合の影響を検討します。ユーザー名 wiley を持つ攻撃者が文字列「name'; DELETE FROM items; --」を itemName に入力すると、クエリは次の 2 つのクエリになります。

        SELECT * FROM items
        WHERE owner = 'wiley'
        AND itemname = 'name';

        DELETE FROM items;

        --'

Microsoft(R) SQL Server 2000 などの多くのデータベースサーバーでは、セミコロンで区切って入力した複数の SQL ステートメントをまとめて実行することができます。このような悪意のある文字列は、セミコロンで区切った複数ステートメントのバッチ処理を許可しない Oracle などのデータベースサーバーではエラーになりますが、バッチ処理を許容するデータベースの場合、攻撃者はデータベースに対して任意のコマンドを実行できます。

末尾の 2 つのハイフン (--) に注意してください。多くのデータベースサーバーでは、これ以降のステートメントはコメントとなり、実行されません [4]。この例では、変更されたクエリの末尾に残っている単一引用符が、コメント文字により削除されます。コメントをこのように使用することが許されていないデータベースでも、Example 1 と同様の技法を使用すると一般的な攻撃を有効にできます。攻撃者が文字列「name'); DELETE FROM items; SELECT * FROM items WHERE 'a'='a」を入力すると、次の 3 つの有効なステートメントが作成されます。

        SELECT * FROM items
        WHERE owner = 'wiley'
        AND itemname = 'name';

        DELETE FROM items;

        SELECT * FROM items WHERE 'a'='a';

一部には、モバイルの世界では SQL Injection のような古典的な Web アプリケーションの脆弱性は意味がなく、自分に降りかかる攻撃をするはずがない、という見方があります。しかし忘れてはならないモバイルプラットフォームの基本は、さまざまなソースからアプリケーションをダウンロードして同じデバイス上で一緒に実行することです。このため、たとえばバンキングアプリケーションのすぐ隣でマルウェアの一部を実行する可能性が高くなり、モバイルアプリケーションの攻撃面を拡張し、プロセス間通信なども含める必要があります。

例 3: 次のコードでは、Android プラットフォームにExample 1 を応用しています。

...
        PasswordAuthentication pa = authenticator.getPasswordAuthentication();
        String userName = pa.getUserName();
        String itemName = this.getIntent().getExtras().getString("itemName");
        String query = "SELECT * FROM items WHERE owner = '"
                                + userName + "' AND itemname = '"
                                + itemName + "'";
        SQLiteDatabase db = this.openOrCreateDatabase("DB", MODE_PRIVATE, null);
        Cursor c = db.rawQuery(query, null);
...

SQL Injection の攻撃を阻止する従来からの手段に、これらを入力検証の問題として扱う方法があります。安全な値の許可リストにある文字だけを受け入れるか、悪意のあることが疑われる値をリストで識別して回避するか (拒否リスト) のどちらかを行います。許可リストをチェックする方法は、入力検証ルールの厳密な適用に非常に効果的ですが、パラメーター化された SQL ステートメントを使用する方がメンテナンスしやすく、セキュリティ上の安全性も高まります。ほとんどの場合と同様、拒否リストを実装する方法には SQL Injection の攻撃に対する防御を無効にできる抜け穴が多く存在します。たとえば、攻撃者は次のことを実行できます。

- 引用符で囲まれていないフィールドをターゲットとする。
- 特定のメタ文字をエスケープする必要性を回避する方法を見つけ出す。
- ストアドプロシージャを使用して、挿入されたメタ文字を隠す。

SQL クエリへの入力文字を手動でエスケープすることは便利ですが、アプリケーションを SQL Injection 攻撃の危険にさらすことになります。

その他、SQL Injection の攻撃への一般的な対処として、ストアドプロシージャを使用する方法があります。ストアドプロシージャは特定のタイプの SQL Injection 攻撃を阻止するためには有効ですが、他の多くの攻撃に対しては無力です。ストアドプロシージャは通常、パラメーターに渡されるステートメントのタイプを制限することで SQL Injection の阻止を助けます。ただし、この制限を回避する方法は多数あり、問題になりそうな多くのステートメントをストアドプロシージャに渡すことができます。ストアドプロシージャは悪用の一部を阻止することができますが、アプリケーションが SQL Injection 攻撃に対して安全になるわけではありません。

mysql_real_escape_string() などのエンコーディング関数を使用すると、ある程度は SQL Injection の脆弱性に対する攻撃を防ぐことはできますが、完全に防ぐことはできません。このようなエンコーディング関数に頼ることは、脆弱な拒否リストを使用して SQL Injection を阻止しようとするのと同じことであり、攻撃者によるステートメントの改変や任意の SQL コマンドの実行が可能となる場合があります。動的に解釈されるコードの特定のセクション内のどこに入力が現れるのかを静的に判断することは必ずしも可能ではないため、Fortify Secure Coding Rulepacks は検証された動的 SQL データを「SQL Injection: Poor Validation」の問題として提示します。これは、検証によってコンテキスト内での SQL Injection を十分に防ぐことができるとしても同様です。

次の場合に SQL Injection エラーが発生します。

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



2. データが SQL クエリの動的な構築に使用された場合。

例 1: 次の例は、データベースの設定によって mysqli_real_escape_string() の動作が変更される場合について示したものです。 SQL モードが「NO_BACKSLASH_ESCAPES」に設定されている場合、バックスラッシュ文字はエスケープ文字ではなく、通常の文字として扱われます [5]。 mysqli_real_escape_string() はこのことを考慮するため、次のクエリは SQL Injection に対して脆弱となります。これは、データベースの設定によって " が \" にエスケープされなくなるためです。

  mysqli_query($mysqli, 'SET SQL_MODE="NO_BACKSLASH_ESCAPES"');
  ...
  $userName = mysqli_real_escape_string($mysqli, $_POST['userName']);
  $pass = mysqli_real_escape_string($mysqli, $_POST['pass']);
  $query = 'SELECT * FROM users WHERE userName="' . $userName . '"AND pass="' . $pass. '";';
  $result = mysqli_query($mysqli, $query);
  ...

攻撃者が password フィールドを空白のままにして、userName に対して " OR 1=1;-- と入力すると、引用符はエスケープされず、クエリの結果は次のようになります。

  SELECT * FROM users
  WHERE userName = ""
  OR 1=1;
  -- "AND pass="";

OR 1=1 によって where 句は常に真 (true) の評価を行い、二重ハイフンによってステートメントの残りの部分はコメントとして扱われるため、このクエリは次のような単純なクエリと論理的に等しくなります。

  SELECT * FROM users;

SQL Injection の攻撃を阻止する従来からの手段に、これらを入力検証の問題として扱う方法があります。安全な値の許可リストにある文字だけを受け入れるか、悪意のあることが疑われる値をリストで識別して回避するか (拒否リスト) のどちらかを行います。許可リストをチェックする方法は、入力検証ルールの厳密な適用に非常に効果的ですが、パラメーター化された SQL ステートメントを使用する方がメンテナンスしやすく、セキュリティ上の安全性も高まります。ほとんどの場合と同様、拒否リストを実装する方法には SQL Injection の攻撃に対する防御を無効にできる抜け穴が多く存在します。たとえば、攻撃者は次のことを実行できます。

- 引用符で囲まれていないフィールドをターゲットとする。
- 特定のメタ文字をエスケープする必要性を回避する方法を見つけ出す。
- ストアドプロシージャを使用して、挿入されたメタ文字を隠す。

SQL クエリへの入力文字を手動でエスケープすることは便利ですが、アプリケーションを SQL Injection 攻撃の危険にさらすことになります。

その他、SQL Injection の攻撃への一般的な対処として、ストアドプロシージャを使用する方法があります。 ストアドプロシージャは特定のタイプの SQL Injection 攻撃を阻止するためには有効ですが、他の多くの攻撃に対しては無力です。 ストアドプロシージャは通常、パラメーターに渡されるステートメントのタイプを制限することで SQL Injection の阻止を助けます。 ただし、この制限を回避する方法は多数あり、問題になりそうな多くのステートメントをストアドプロシージャに渡すことができます。 ストアドプロシージャは悪用の一部を阻止することができますが、アプリケーションが SQL Injection 攻撃に対して安全になるわけではありません。

SubSonic に関連した SQL Injection エラーが発生するのは、次の場合です。

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

2. データがクエリの動的な構築に使用された場合。
例 1: 次のコードは、指定された名前に一致するアイテムを検索する SubSonic クエリを動的に構築し、実行します。このクエリでは、認証済みユーザーのユーザー名と owner が一致するアイテムだけが表示されます。

...
string userName = ctx.getAuthenticatedUserName();
string query = "SELECT * FROM items WHERE owner = '"
				+ userName + "' AND itemname = '"
				+ ItemName.Text + "'";

IDataReader responseReader = new InlineQuery().ExecuteReader(query);
...

このコードによって実行されるクエリは次のようになります。

	SELECT * FROM items
	WHERE owner = <userName>
	AND itemname = <itemName>;

ただし、クエリは定数ベースのクエリ文字列とユーザー入力の文字列を連結して動的に構築されるため、itemName に単一引用符が含まれない場合のみクエリは正しく動作します。ユーザー名 wiley を持つ攻撃者が文字列「name' OR 'a'='a」を itemName に入力すると、クエリは次のようになります。

	SELECT * FROM items
	WHERE owner = 'wiley'
	AND itemname = 'name' OR 'a'='a';

OR 'a'='a' 条件を追加すると、where 句は常に真 (true) の評価を行います。そのため、このクエリは次のような単純なクエリと論理的に等しくなります。

	SELECT * FROM items;

このクエリの単純化により攻撃者は、クエリが返すのは認証済みユーザーが所有するアイテムのみでなければならないという要件を回避できます。クエリは、特定の所有者に関係なく、items テーブルに格納されているすべてのエントリを返すようになりました。

例 2: この例では、Example 1 で構築および実行されたクエリに悪意のある別の値が渡された場合の影響を検討します。ユーザー名 wiley を持つ攻撃者が文字列「name'); DELETE FROM items; --」を itemName に入力すると、クエリは次の 2 つのクエリになります。

	SELECT * FROM items
	WHERE owner = 'wiley'
	AND itemname = 'name';

	DELETE FROM items;

	--'

Microsoft(R) SQL Server 2000 などの多くのデータベースサーバーでは、セミコロンで区切って入力した複数の SQL ステートメントをまとめて実行することができます。このような悪意のある文字列は、セミコロンで区切った複数ステートメントのバッチ処理を許可しない Oracle などのデータベースサーバーではエラーになりますが、バッチ処理を許容するデータベースの場合、攻撃者はデータベースに対して任意のコマンドを実行できます。

末尾の 2 つのハイフン (--) に注意してください。多くのデータベースサーバーでは、これ以降のステートメントはコメントとなり、実行されません [4]。この例では、変更されたクエリの末尾に残っている単一引用符が、コメント文字により削除されます。コメントをこのように使用することが許されていないデータベースでも、Example 1 と同様の技法を使用すると一般的な攻撃を有効にできます。攻撃者が文字列「name'); DELETE FROM items; SELECT * FROM items WHERE 'a'='a」を入力すると、次の 3 つの有効なステートメントが作成されます。

	SELECT * FROM items
	WHERE owner = 'wiley'
	AND itemname = 'name';

	DELETE FROM items;

	SELECT * FROM items WHERE 'a'='a';

SubSonic Injection の攻撃を阻止する従来からの手段に、これらを入力検証の問題として扱う方法があります。安全な値からなる許可リスト内の文字だけを受け入れるか、悪意のあることが疑われる値をリストで識別して回避する (拒否リスト) かのどちらかを行います。許可リストをチェックする方法は、入力検証ルールの厳密な適用に非常に効果的ですが、パラメーター化された SubSonic ステートメントを使用する方がメンテナンスしやすく、セキュリティ上の安全性も高まります。ほとんどの場合と同様、拒否リストを実装する方法には SubSonic SQL Injection の攻撃に対する防御を無効にできる抜け穴が多く存在します。たとえば、攻撃者は次のことを実行できます。

- 引用符で囲まれていないフィールドをターゲットとする。
- 特定のメタ文字をエスケープする必要性を回避する方法を見つけ出す。
- ストアドプロシージャを使用して、挿入されたメタ文字を隠す。

SubSonic クエリへの入力文字を手動でエスケープすることは便利ですが、アプリケーションを SubSonic SQL Injection 攻撃の危険にさらすことになります。

その他、SubSonic Injection の攻撃への一般的な対処として、ストアドプロシージャを使用する方法があります。ストアドプロシージャは特定のタイプの SubSonic Injection 攻撃を阻止するためには有効ですが、他の多くの攻撃に対しては無力です。ストアドプロシージャは通常、パラメーターに渡されるステートメントのタイプを制限することで SubSonic SQL Injection の阻止を助けます。ただし、この制限を回避する方法は多数あり、問題になりそうな多くのステートメントをストアドプロシージャに渡すことができます。ストアドプロシージャは悪用の一部を阻止することができますが、アプリケーションが SubSonic Injection 攻撃に対して安全になるわけではありません。

機密情報やリモート管理パネルなどの特権機能が含まれるサーバーでは、アクセスに認証が必要です。そうでない場合、攻撃者は一般的なユーザー名を推測するだけで機密情報を盗んだり、ターゲット ホストを制御したりすることができます。

クライアントは NoneAuth 認証方法を使用して、使用可能な認証方法を判断することができます。

例 1: 次の Paramiko コードは、「なし」認証要求を使用してサーバーに認証しようとします。

    client = SSHClient()
    client.connect(host, port, auth_strategy=NoneAuth("user"))

次の場合に String Termination Error が発生します。

1.出力を NULL ターミネートしていない関数を経由してデータがプログラムに入り込む場合。

2.入力が NULL ターミネートされる必要のある関数にデータが渡される場合。
例 1: 次のコードでは、cfgfile から読み取ったデータを、strcpy() を使用して inputbuf にコピーしています。このコードは、inputbuf が常に NULL ターミネータを含むと誤って想定しています。

#define MAXLEN 1024
...
char *pathbuf[MAXLEN];
...
read(cfgfile,inputbuf,MAXLEN); //does not null-terminate
strcpy(pathbuf,inputbuf); //requires null-terminated input
...

Example 1 のコードは、cfgfile から読み取ったデータが想定どおり NULL ターミネートされている場合は正しく動作します。しかし、攻撃者がこの入力を変更して、想定されている null 文字を含まないようにできる場合、strcpy() のコールは任意の null 文字に遭遇するまでメモリからのコピーを続けます。つまり、コピー先バッファがオーバーフローする確率が高くなります。また、攻撃者が inputbuf の直後のメモリ内容を制御できる場合、アプリケーションはバッファ オーバーフロー攻撃にさらされた状態のままになる可能性があります。

例 2: 次のコードでは、まず path というバッファに保持されているシンボリック リンクの名前を readlink() で展開し、シンボリック リンクが参照するファイルの絶対パスを buf というバッファに格納しています。次に、結果として得られる値の長さが strlen() を使用して計算されます。

...
char buf[MAXPATH];
...
readlink(path, buf, MAXPATH);
int length = strlen(buf);
...

Example 2 のコードは、readlink() によって buf に読み込まれた値が NULL ターミネートされないため、正しく動作しません。テストでは、このような脆弱性は見つかりません。buf の使用されていない内容とその直後のメモリが null になる可能性があり、strlen() が正しく動作しているように見えるからです。しかし実環境では、strlen() はスタック上で任意の null 文字に遭遇するまでメモリを検索し続けます。その結果 length の値は buf の値よりはるかに大きくなり、それ以降もこの値を使用し続けると Buffer Overflow を引き起こす可能性があります。

例 3: 次のコードは snprintf() を使用してユーザー入力文字列をコピーし、複数の出力文字列に配置します。sprintf() に類似した追加のガードレール、特に最大出力サイズの指定を提供しているにもかかわらず、snprintf() 関数は、指定された出力サイズが想定される入力よりも大きい場合に、依然として文字列のターミネーション エラーの影響を受けやすくなります。文字列のターミネーション エラーは、メモリ リークやバッファ オーバーフローなどの下流の問題を引き起こす可能性があります。

...
char no_null_term[5] = getUserInput();

char output_1[20];
snprintf(output_1, 20, "%s", no_null_term);

char output_2[20];
snprintf(output_2, 20, "%s", no_null_term);


printf("%s\n", output_1);
printf("%s\n", output_2);
...

Example 3 のコードはメモリ リークを示します。output_2 に no_null_term が設定されている場合、snprintf() は null 文字が検出されるか指定されたサイズ制限に達するまで、no_null_term の位置から読み取る必要があります。no_null_term にはターミネーションがないため、snprintf は output_1 のデータの読み取りを続け、最終的に snprintf() の最初の呼び出しによって提供された null ターミネート文字に到達します。メモリ リークは、output_2 の printf() によって示されます。これには、no_null_term の文字シーケンスが 2 つ含まれています。

文字列は、慣習的に null 文字でターミネートされたデータを含むメモリ領域として表現されています。多くの場合、古い文字列処理メソッドは文字列長の判断をこの null 文字に依存しています。NULL ターミネータを含んでいないバッファがそのような関数のいずれかに渡されると、その関数はバッファの末尾を越えて読み込みを続けます。

悪意あるユーザーは通常、想定されていないサイズまたは内容のデータをアプリケーションに挿入することにより、このタイプの脆弱性を悪用します。つまり、直接プログラムに入力するか、間接的にアプリケーションリソース (たとえば、設定ファイル) を変更することによって悪意ある入力を行います。攻撃者がアプリケーションにバッファーの境界を越えて読み込みを実施させた場合、その結果として生じるBuffer Overflowを利用して任意のコードをシステムに挿入して実行させることができます。

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


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

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


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

Action Fields に、対応する検証定義がありません。各フィールドには、ActionClass-validation.xml で参照される明示的な検証ルーチンが必要です。

開発者は、アクションフォームマッピングの削除または名前の変更を実行した際に検証ロジックの更新を忘れることがあります。検証ロジックが適切に保守されていないことを示すものの 1 つが、検証機能の欠落です。

検証ロジックの保守と保存は、アプリケーションのその他の部分と同期していることが非常に重要です。今日最も被害が大きく最も一般的なソフトウェアのセキュリティ問題の根本原因が入力の未検証です。Cross-Site Scripting、SQL Injection、Process Control の脆弱性は、いずれも入力検証が不完全だったり、行われなかったりしたことが原因となっています。J2EE アプリケーションでは一般にメモリ破壊攻撃の可能性はありませんが、J2EE アプリケーションが、配列の上限と下限のチェックを実行しないネイティブコードとインターフェイスを取る場合は、攻撃者が J2EE アプリケーションの入力検証ミスを利用して Buffer Overflow 攻撃を実行できる可能性があります。

ActionClass-validation.xml に同じ名前のフィールド バリデーター定義が複数存在します。同じ名前の検証定義が重複していると、予期しない動作が発生する可能性があります。

例 1: 次のエントリは、2 つの重複するフィールド バリデーター定義を示しています。

   <field name="emailField">
      <field-validator type="email" short-circuit="true">
          <message>You must enter a value for email.</message>
      </field-validator>
      <field-validator type="email" short-circuit="true">
          <message>Not a valid email.</message>
      </field-validator>
  </field>
  

検証ロジックを保守し、アプリケーションの他の部分と同期させることが非常に重要です。入力の未検証は、現在見られる、いくつかの最も最悪かつ一般的なソフトウェア セキュリティ問題の根本的な原因です。Cross-Site Scripting、SQL Injection、Process Control の脆弱性はいずれも、入力検証が不完全であったり、行われなかったりすることが原因です。J2EE アプリケーションは通常はメモリ破損攻撃の影響を受けませんが、J2EE アプリケーションが配列の境界チェックを実行しないネイティブ コードと情報をやりとりする場合、攻撃者が J2EE アプリケーションでの入力検証ミスを使用してバッファ オーバーフロー攻撃を行う可能性があります。

この Struts2 Action 定義に対して、2 つ以上の ActionClass-validation.xml ファイルが検出されました。ActionClass の形式で定義されている各 Struts2 Action について、Struts2 は検証に必要な制限事項を確認するために、対応する ActionClass-validation.xml を検索します。配置に含まれている 1 つの Action に複数の検証定義がある場合、予期せぬ動作の原因となる可能性があります。

同じ名前の検証フォームが 2 つある場合、Struts Validator は任意でいずれかのフォームを選択して入力の検証に使用し、もう一方は破棄します。この判断がプログラマの予想と一致しないことがあります。また、これは検証ロジックが保守されていないことを示し、さらに他の非常に小さな検証エラーが存在することも示している可能性があります。

検証ロジックの保守と保存は、アプリケーションのその他の部分と同期していることが非常に重要です。今日最も被害が大きく最も一般的なソフトウェアのセキュリティ問題の根本原因が入力の未検証です。Cross-Site Scripting、SQL Injection、Process Control の脆弱性は、いずれも入力検証が不完全だったり、行われなかったりしたことが原因となっています。J2EE アプリケーションでは一般にメモリ破壊攻撃の可能性はありませんが、J2EE アプリケーションが、配列の上限と下限のチェックを実行しないネイティブコードとインターフェイスを取る場合は、攻撃者が J2EE アプリケーションの入力検証ミスを利用して Buffer Overflow 攻撃を実行できる可能性があります。

複数のバリデーター定義が validators.xml で発見されました。同じ名前の検証定義が複数あると、予期しない動作が発生する可能性があります。

2 つの検証クラスが同じ名前で定義されている場合、Struts バリデーターは、入力検証に使用するためにどちらかの形式を任意に選択し、もう 1 つを破棄します。この決定が、プログラマの想定と合っていない可能性があります。さらに、検証ロジックが保守されていないことを示し、他のよりわかりにくい検証エラーが存在する可能性もあります。

検証ロジックを保守し、アプリケーションの他の部分と同期させることが非常に重要です。入力の未検証は、現在見られる、いくつかの最も最悪かつ一般的なソフトウェア セキュリティ問題の根本的な原因です。Cross-Site Scripting、SQL Injection、Process Control の脆弱性はいずれも、入力検証が不完全であったり、行われなかったりすることが原因です。J2EE アプリケーションは通常はメモリ破損攻撃の影響を受けませんが、J2EE アプリケーションが配列の境界チェックを実行しないネイティブ コードと情報をやりとりする場合、攻撃者が J2EE アプリケーションでの入力検証ミスを使用してバッファ オーバーフロー攻撃を行う可能性があります。

Struts2 では、カスタム バリデーターを、アクション バリデーター定義で使用する前に validators.xml で定義する必要があります。バリデーター定義がない場合、検証が最新ではないことを意味します。

例 1: 次のアクション バリデーターは、validators.xml で定義されていません。

<validators>
    <validator name="required" class="com.opensymphony.xwork2.validator.validators.RequiredFieldValidator"/>
</validators>

検証ロジックを保守し、アプリケーションの他の部分と同期させることが非常に重要です。入力の未検証は、現在見られる、いくつかの最も最悪かつ一般的なソフトウェア セキュリティ問題の根本的な原因です。Cross-Site Scripting、SQL Injection、Process Control の脆弱性はいずれも、入力検証が不完全であったり、行われなかったりすることが原因です。J2EE アプリケーションは通常はメモリ破損攻撃の影響を受けませんが、J2EE アプリケーションが配列の境界チェックを実行しないネイティブ コードと情報をやりとりする場合、攻撃者が J2EE アプリケーションでの入力検証ミスを使用してバッファ オーバーフロー攻撃を行う可能性があります。

J2EE アプリケーションの脆弱性の主な原因は、未検証の入力です。Cross-Site Scripting、Process Control や SQL Injection などのさまざまな脆弱性の原因は入力の未検証です。J2EE アプリケーションでは一般にメモリ破壊攻撃の可能性はありませんが、J2EE アプリケーションが、配列の上限と下限のチェックを実行しないネイティブコードとインターフェイスを取る場合は、攻撃者が J2EE アプリケーションの入力検証ミスを利用して Buffer Overflow 攻撃を実行できる可能性があります。

そのような攻撃を防止するため、Struts Validation フレームワークを使用してすべてのプログラム入力を確認してからアプリケーションに処理させます。Fortify Static Code Analyzer を使用すると、Struts Validator の設定の不備な点を確実になくすことができます。

Validator を使用すると、次のような点をチェックできます。

- 電話番号フィールドには、電話番号で有効な文字だけが含まれる。

- ブール値は「T」と「F」のいずれかだけである。

- 自由入力の文字列は適切な長さと形式にする。

Struts2 検証ファイルが、対応する Struts2 アクションなしで検出されました。各 ActionClass について、Struts2 は対応する ActionClass-validation.xml を検索し、必要な検証の制約を探します。この場合、ActionClass-validation.xml という形式の検証ファイルが見つかりましたが、ActionClass が Struts2 設定ファイルで定義されたアクションと一致しません。

開発者は、アクション フォーム マッピングを削除または名前変更するときに、検証ロジックの更新を忘れがちです。検証ロジックが適切に保守されていないことを示す兆候の 1 つは、未使用の検証フォームが存在することです。

Struts2 バリデーターの定義が、存在しないアクション フィールドを参照しています。

開発者は、アクション フォーム マッピングを削除または名前変更するときに、検証ロジックの更新を忘れがちです。検証ロジックが適切に管理されていないことを示す 1 つの兆候は、孤立したバリデーター定義の存在です。

form-bean の名前の重複には意味がありません。複数の <form-bean> タグで同じ名前が使用されていても、最後のエントリのみが登録されるためです。

例 1: 次の設定には、同じ名前の form-bean エントリが 2 つあります。

<form-beans>
  <form-bean name="loginForm" type="org.apache.struts.validator.DynaValidatorForm">
    <form-property name="name" type="java.lang.String" />
    <form-property name="password" type="java.lang.String" />
  </form-bean>
  <form-bean name="loginForm" type="org.apache.struts.validator.DynaActionForm">
    <form-property name="favoriteColor" type="java.lang.String" />
  </form-bean>
</form-beans>

Struts は path 属性を使用して、リクエストの処理に必要なリソースを見つけます。パスはモジュールと関連する場所であるため、"/" 文字で始まらない場合はエラーになります。

例 1: 次の設定には、空のパスが含まれています。

<global-exceptions>
  <exception key="global.error.invalidLogin" path="" scope="request" type="InvalidLoginException" />
</global-exceptions>

例 2: 次の設定は、"/" 文字で始まらないパスを使用しています。

<global-forwards>
  <forward name="login" path="Login.jsp" />
</global-forwards>

名前付きアクションから検証エラーが返される場合は、Struts の仕様により input 属性が求められます [2]。input 属性は、検証エラーが発生した場合のエラー メッセージの表示に使用するページを指定します。
例 1: 次の設定は、名前付き検証アクションを定義していますが、input 属性は指定していません。

<action-mappings>
  <action   path="/Login"
            type="com.LoginAction"
            name="LoginForm"
            scope="request"
            validate="true" />
</action-mappings>