魔法の名言

マジッククォートはPHP スクリプト言語の機能で、文字列は渡される前に自動的にエスケープされます(特殊文字の前にバックスラッシュが付けられます)。これは、初心者が手動でエスケープする必要なく機能する SQL コマンドを記述できるようにするために導入されました。後に、経験の浅い開発者がSQL インジェクション攻撃に対して脆弱なコードを記述するのを防ぐことが目的であると説明されました。

この機能はセキュリティ上の懸念から、PHP 5.3.0 で正式に非推奨となり、PHP 5.4 では削除されました。^[1]

PHP マニュアルの現在の改訂版では、マジック クォートの背後にある理論的根拠は「初心者が書いたコードが危険にならないようにするため」であると述べられています。^[2]ただし、マジック クォートは元々 PHP 2 で msql の php.h コンパイル時設定として導入され、単一引用符のみをエスケープして「フォーム データを msql クエリに直接渡すのを容易にしました」。^[3]元々は「セキュリティ機能ではなく、利便性機能」として意図されていました。^{[4] [5]}

PHP 3 では、マジック クォートの使用範囲が拡張されました。ユーザーが入力したすべてのデータ内のシングル クォート、ダブル クォート、バックスラッシュ、および null 文字には、スクリプトに渡される前に、グローバル変数 、 、 でバックスラッシュが先頭に追加されます$_GET。$_REQUEST開発$_POST者$_COOKIEは、理論的には、文字列連結を使用して、ユーザーが入力したデータで安全な SQL クエリを構築できます。(これは、PHP 2 および PHP 3 が最新だったときに最も正確でした。主なサポート対象データベースでは 1 バイトの文字セットしか使用できなかったためです。)

PHP 3 および 4 の新規インストールでは、マジック クォートはデフォルトで有効になっていますがmagic_quotes_gpc、設定ディレクティブで無効にすることもできます。マジック クォートの動作はバックグラウンドで行われ、すぐにはわからないため、開発者はマジック クォートの存在や、マジック クォートが引き起こす可能性のある問題に気付いていない可能性があります。PHP のドキュメントでは、いくつかの落とし穴が指摘されており、デフォルトで有効になっているにもかかわらず、マジック クォートを無効にすることを推奨しています。^[6]

マジッククォートに関する問題は次のとおりです:

• ユーザーが入力するデータはすべてデータベースに挿入されるわけではありません。画面に直接表示されたり、セッションに保存されたり、保存前にプレビューされたりすることがあります。その結果、不要な場所にバックスラッシュが追加され、エンドユーザーに表示される可能性があります。このバグは、広く使用されているソフトウェアにも潜んでいることがよくあります。^[7]
• ユーザーが提供し、データベース クエリで使用されるすべてのデータが、マジック クォートで保護されたソースから直接取得されるわけではありません。たとえば、ユーザーが提供した値がデータベースに挿入され、マジック クォートで保護され、その後データベースから取得されて、その後のデータベース操作で使用される場合があります。後者の使用はマジック クォートで保護されず、マジック クォートに依存することに慣れた初心者のプログラマーは、明示的に保護する必要があることに気付かない可能性があります。
• マジッククォートはPHPの関数が提供する汎用的な機能も使用しますがaddslashes()、これはUnicodeに対応しておらず、一部のマルチバイト文字エンコーディングでは依然としてSQLインジェクションの脆弱性の影響を受けます。mysql_real_escape_string()可能であれば、バインドされたパラメータを持つ準備されたクエリなどのデータベース固有の関数が推奨されます。^{[8] [9]}
• 多くのデータベース管理システムではバックスラッシュによる引用符のエスケープをサポートしていますが、標準では別の引用符の使用が求められています。マジック クォートは、バックスラッシュによる引用符のエスケープをサポートするように設定されていないデータベースに対しては保護を提供しません。
• アプリケーションがマジック クォートが有効になっていることを前提としてコーディングされ、その後マジック クォートが無効になっているサーバーに移動された場合、またはその逆の場合、移植性が問題になります。
• マジッククォートを追加し、その後適切な場所でそれを削除すると、わずかですが不要なパフォーマンスのオーバーヘッドが発生します。
• マジッククォートは、クロスサイトスクリプティング攻撃やSMTP ヘッダーインジェクション攻撃などの他の一般的なセキュリティ脆弱性からは保護しません。

2005年11月、PHPのコア開発者は、これらの問題のため、マジッククォート機能をPHP 6から削除することを決定しました。^[10] PHP 6の開発が行き詰まり、代わりに5.xブランチで開発が継続されたため、この機能はPHP 5.3.0で非推奨となり、5.4で削除されました。^[1]

• Perl ^[11]やRuby ^[12]などの一部の言語では、データ汚染を伴うアプローチが選択されます。このアプローチでは、ユーザー入力などの信頼できないソースからのデータは「汚染されている」とみなされ、通常は検証またはエンコード後に明示的に信頼できるとマークされるまで、危険な操作には使用できません。このコンテキストではSQLクエリの構築が「危険」と見なされるため、プログラマーは問題に対処する必要があります。汚染によって問題が解決されるわけではありませんが、問題があるインスタンスが強調表示され、プログラマーが適切に解決できるようになります。
• ジョエル・スポルスキーは、データが安全か安全でないかを示すハンガリー記法を使用することを提案した。 ^[13]
• 最新のデータベース エンジンとライブラリは、パラメーター化されたクエリを使用して、SQL コマンドとは別にデータをデータベースに渡すため、クエリを構築する前にデータをエスケープする必要性が大幅に軽減されます。

• 傾斜つまようじ症候群

• マジッククォートに関する PHP マニュアル