データベース防御の最後の言葉であると思われるパラメーター化されたクエリを読んだだけで、次のことを疑問に思っていました。
すべての入力 (バーのチェックボックスとラジオ ボタン) が real_escape_string の対象となる既存の PHP/MySQL 自作 CMS があります。sha1 で暗号化されたパスワードと一致するユーザー名を介してアクセスできる管理セクションがあり、信頼できる人々の小さな (3) グループがコンテンツ (tinyMCE) を更新したり、写真をアップロードしたりできます。私のクエリはどれもパラメータ化されていませんが、エスケープ後にのみ実行されます。
一般からの入力はありませんが、後でユーザーが送信したフォームに公開したいと考えています。
私のホストは私立で、非常に良い成績を収めています。
他のすべてが等しい場合、私はどのくらい安全ですか?
mysql_real_escape_stringSQL インジェクション攻撃からすぐには保護されません。私は最近、小さなサイトの開発者を助けました。この開発者は、mysql_real_escape_stringすべての入力を呼び出しても安全だと思っていましたが、それでも pwn'd になりました。彼の場合、彼は (GET 文字列を介して) 変数が整数であることを期待していましたが、そのように検証していませんでした。次に、攻撃者はその ID フィールドを利用してカスタム クエリを作成し、データベース全体へのアクセス権を取得しました。
物語の教訓？検証、検証、検証。外部から来る可能性のあるすべてのデータは (たとえそれ<input type="hidden">が入力したものであっても)、セキュリティ対策をバイパスする試みであると想定する必要があります。これは、検証コンポーネントが組み込まれているため、Codeigniter などのフレームワークの使用が役立つ場所です。すべてを自分で行いたい場合は、注意して、すべての入力変数を確認してください。
むしろ、パラメーター化された/準備されたステートメントを使用したいと思います。入力をエスケープするだけの場合と比較して、便利なタイプを指定でき（たとえば、日時の値をサーバー固有の形式に変換する必要がありません）、さまざまなRDMSによる変換エラーの処理のあいまいさも解決されます。たとえば、クエリSELECT * FROM table1 WHERE int_field='aaa'（int_fieldは整数）は、Mysqlではint_fieldが0に等しいレコードを返し、OracleとSQLServerではエラーを発生させ、SQliteでは空のセットを返します。