SQL Injection: Poor Validation

HTML、XML、またはその他のタイプのエンコーディングに頼って信頼できない入力を検証すると、攻撃者によるステートメントの改変や任意の SQL コマンドの実行が可能になることがあります。

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 攻撃に対して安全になるわけではありません。