PHPのAddSlashesとMySQL（i）_escape_stringの違いは何ですか？ [複製

Question

可能な複製：
mysql_real_escape_string vs addslashes

彼らがまったく同じことをしない場合、違いは何ですか？ mysqlクエリ内の値の区切り文字は ' ではない？または多分 " しかし、それはまた、Addslashesで逃げます。

他のデータベースエンジンでは、私が理解しています（そして間違いなくPDOのようなDBラッパー内）が、なぜ多くの人々がAddSlashesの代わりにMySQL（i）_escape_stringを使用することを称賛しているのですか？

Answer 1

初めに： 使ってはいけません mysql_escape_string, 、それは（理由で）非推奨です！

データベースに接続するレガシーアプリケーションをサポートする必要がある場合 mysql 拡張機能（これ 非推奨されています）、 使用する mysql_real_escape_string 代わりは。さもないと すぐに切り替えます に mysqli, 、準備されたステートメントとバインドされたパラメーターが、ユーザー入力を逃れるためのより堅牢なメカニズムを提供します。

とはいえ、答えはの説明を読むことで見つけることができます mysql_real_escape_string と addslashes:

違い＃1

addslashes MySQL接続エンコーディングについて何も知りません。 MySQL接続で使用されるエンコード以外のエンコードを表すバイトを含む文字列を渡すと、喜んで逃げます 文字の値を持つすべてのバイト ', ", \ と \x00. 。これは同じではないかもしれません すべてのキャラクター ', ", \ と \x00 8ビットエンコーディングとUTF-8以外のエンコーディングを使用している場合。その結果、MySQLが受信した文字列が破損します。

このバグをトリガーするには、使用してみてください iconv 変数をUTF-16に変換してから逃がします addslashes. 。データベースが受信するものをご覧ください。

これが理由の1つです addslashes 逃げるために使用しないでください。

違い＃2

とは対照的に addslashes, mysql_real_escape_string また、キャラクターを逃れます \r, \n, 、 と \x1a. 。 MySQLと話すとき、これらのキャラクターも逃げる必要があるようです。

これが他の理由です addslashes 逃げるために使用しないでください。

Answer 2

クリス・シフレット SQLを使用して逃げる現実世界のケースを示します addslashes() 失敗します mysql_real_escape_string() 行く唯一の方法です。

これはどのように役立ちますか？ MySQLデータベースに対するSQLインジェクション攻撃を試みたい場合は、バックスラッシュで脱出した単一の引用符が残念です。ただし、addslashes（）を使用している場合、私は幸運です。私がする必要があるのは、0xBF27のようなものを挿入し、AddSlashes（）を変更して、これを変更して、有効なマルチバイト文字である0xBF5C27になり、1回の引用が続きます。言い換えれば、私はあなたが逃げているにもかかわらず、単一の引用を正常に注入することができます。これは、0xBF5Cが2つではなく単一の文字として解釈されるためです。おっと、バックスラッシュがあります。

....

AddSlashes（）の使用にもかかわらず、有効なユーザー名やパスワードを知らずに正常にログインすることができます。 SQLインジェクションの脆弱性を単純に活用できます。

このタイプの脆弱性を回避するには、mysql_real_escape_string（）、作成されたステートメント、または主要なデータベース抽象化ライブラリを使用してください。

現在、これは明らかにまれなエッジケースですが、なぜ人々がデータベース固有のエスケープ関数を使用することに非常に断念しているのかを示すデモンストレーションです。 データベースライブラリのみが、どのような脱出が必要かを確実に知ることができます。 さまざまなラッパー、キャラクターセット、SQLフレーバー（MS SQL Serverなど）は、異なる脱出が必要です。その事実を無視することは、脆弱性がどのように生まれるかです。

Answer 3

信頼できないデータからSQLを構築するのではなく、プレースホルダーを使用する必要があるため、どちらも使用してはならないという点で同一です。

見る http://bobby-tables.com/php.html それを正しい方法で行う方法のために。

Answer 4

これは、チャーセットの問題です。何 addslashes() データが純粋に純粋である場合、SQLコマンドと混合されたデータを逃がすのに十分です ascii. 。しかし、UTF-8エンコードバリエーションに加えて、一部の構成のMySQLは、UCS2（UTF-16）やGB/Big5中国の炭火などのフリンジ充電も許可します。生のASCIIコードから逃げるだけでは不十分です ' の中へ \'. 。そして、弦を逃がすMySQLの方法は、最初からSQL-Standardsに準拠することは決してありませんでした。 MySQLサーバーの将来のリリースでは廃止される可能性があります。