2

だから私はかなり妄想的でmysql_real_escape_string()、PDO を使用しています。私は実際には PDO で準備済みステートメントを使用していないため、入力をサニタイズする必要があります。

自分のサーバーでホストするときは、ローカル マシンに特権のないユーザーを作成して、mysql_real_escape_string()失敗して変数を空にしないようにします (これはサニタイズです!)。データベースに一致する文字セットがない場合、サニタイズする意味がまったくないため、これはかなり失敗したソリューションであることに気づきましたが、暫定的には機能しました。

現在、私の新しいホストでは、パスワードも特権も持たないデータベース用のユーザーを作成できません...そしてmysql_real_escape_string()、ローカル マシンに mysql サーバーがないために失敗します。php.ini を編集して、デフォルト データベースのホスト名/ユーザー/パスを設定できません。

私に何ができる？

これを書いているときにブレインストーミングを行っていると、php が構成の実行時の変更を許可するかどうか疑問に思っています...多分... hrm. 編集：うーん... ini_set()？:O

4

2 に答える 2

16

このように 2 つのデータベース ライブラリを混在させるのは良くない考えであり、安全ではない可能性があります。

mysql_real_escape_string()完全に安全であるためには、既存の古典的なmysql_connect()データベース接続 (文字セット情報を取得できる) が必要です。PDO 接続は分離され、文字セット設定が異なる可能性があり、最終的にセキュリティが低下します。

mysql_real_escape_string() を使用する前に MySQL 接続が必要です。そうしないと、レベル E_WARNING のエラーが生成され、FALSE が返されます。link_identifier が定義されていない場合、最後の MySQL 接続が使用されます。

ずっと PDO を使用してください。代替手段はありません。

準備済みステートメントを使用したくない場合はPDO::quote、正しい関数にする必要があります。

SQL ステートメントに渡しても理論的に安全な引用符付き文字列を返します。

ただし、その関数のマニュアル ページでさえ、代わりに準備済みステートメントを使用することを推奨していることに注意してください。

于 2011-05-31T18:26:24.753 に答える
7

PDO を使用する利点は、エスケープに関する心配がないことです。

prepare を使用して、PDO に汚い仕事をさせることをお勧めします。

于 2011-05-31T18:24:54.933 に答える