PHPでmagic_quotes_gpcをオンにすることは、なぜ悪い習慣と見なされるのですか?
6 に答える
I don't think I can explain it any better than the makers of PHP itself (with followup comments on that page): Why not to use Magic Quotes
- Portability: Assuming it to be on, or off, affects portability. Use
get_magic_quotes_gpc()
to check for this, and code accordingly. - Performance: Because not every piece of escaped data is inserted into a database, there is a performance loss for escaping all this data. Simply calling on the escaping functions (like
addslashes()
) at runtime is more efficient. Although php.ini-development enables these directives by default, php.ini-production disables it. This recommendation is mainly due to performance reasons. - Inconvenience: Because not all data needs escaping, it's often annoying to see escaped data where it shouldn't be. For example, emailing from a form, and seeing a bunch of \' within the email. To fix, this may require excessive use of
stripslashes()
.
Note - This feature has been DEPRECATED as of PHP 5.3.0 and REMOVED as of PHP 5.4.0.
記事によると、PHP と php.ini のマジック クォート GPC (magic_quotes_gpc) とは何ですか? 、多くの欠点があります。
- フォーム送信がブラウザに送り返される場合は、stripslashes() を呼び出して手動でスラッシュを削除する必要があります。
- このサーバーでマジック クォートがオフになっている場合、またはマジック クォートが有効になっていないサーバーにコードが移動された場合、スクリプトは失敗します。さらに悪いことに、すぐに失敗せず、奇妙な動作を示すだけです。
- 送信された変数に対するすべての文字列操作は、単純な 'if' ステートメントであっても、コンテンツ内でスラッシュがワープする可能性を考慮する必要があります。
- マジック クォートは、開発者のずさんさを助長します。(私の意見では) SQL クエリに挿入された変数をエスケープすることは、開発者が知って考えておくべきことです。すべてがおしゃれだと思い込むだけではありません。
そのオプションが有効になっていないサーバーに誰かがスクリプトを移動できるため、アプリケーションに何百ものセキュリティ ホールが即座に開かれます。また、マジック クォートを有効にするとアプリケーションが安全になると考えている人が多すぎます。そうではありません。アプリケーションに入力されるすべての入力を調べて検証する必要があります。見積もりの問題がなくても、クロス サイト スクリプティングの問題などが発生する可能性があります。
この機能が PHP の将来のバージョンで削除されるという事実にもかかわらず。
オフにしておくと、より安全なコードを作成する必要があるためです。
O'Malley 氏がサイトに登録すると、magic_quotes_gpc が彼の姓を O\'Malley に変換し、それをデータベースに挿入すると、すべてがうまくいきます。
問題は、magic_quotes が addslashes に由来することです。これは必ずしもデータベース システムのエスケープとして機能するとは限りません。O'Malley が機能する可能性がありますが、このエスケープを回避して SQL インジェクションを行うことも可能です。
magic_quotes がオンでない場合、文字列 O'Malley が取得され、次のような SQL ステートメントが壊れます。
INSERT INTO users (...) VALUES (...,'O'Malley',...)
文字列が実際には O の後に終了していることに注意してください。
さらに、そのほうがいいです。たとえば、彼の名前で電子メールを送信する場合は、スラッシュを削除する必要があります-正当な理由はありません. そうしないと、Mr. O\'Malley から電子メールが届きます。
(もちろん、非常に安全なデータベース処理コードの場合は、パラメーター化されたクエリを使用することをお勧めします。これが SQL インジェクションを防ぐ最善の方法だからです。また、パラメーター化する場合は、とにかくスラッシュは必要なく、無駄になります。 PHPにそれらを追加する時が来ました。)
「マジック クォート」は、開発者がよくわからないときに SQL インジェクションで自分自身を撃つことを防ぐための PHP の試みでした。PHP 5.3 で非推奨となり、PHP 6 で削除される予定です。
すべてをエスケープしてデータベースに決して配置されないものをエスケープ解除するよりも、明示的にエスケープする必要があるものをエスケープする方が良いと私は言います。魔法の引用符は、よりよく知っているべき人々を保護しようとして、解決するよりも多く (またはそれ以上) の問題を生み出します。
とても簡単な質問です。
ユーザーのデータを電子メールで送信したいとします。または、Cookie からユーザーの名前をフォーム入力に挿入します。Bob \"Buffalo\" Bill のような名前を付けるのは良い考えだと思いますか? 私はそうは思わない