4

簡単なもの。

mysqlを使用する古いWebアプリケーションをmysqliに移行中です。私は以前、次のように書いたカスタムサニテーション関数を使用してSQLインジェクションから保護していました。

    function sani($text=""){
    if (!is_array($text)) { 
        $text = str_replace("<", "&lt;", $text); 
        $text = str_replace(">", "&gt;", $text); 
        $text = str_replace("\"", "&quot;", $text); 
        $text = str_replace("'", "&#039;", $text); 
        return $text; 
    } 
}

彼らは私がこれを使用していた方法：

mysql_query("SELECT * FROM `table` WHERE `username` = '" . $sani($userinput) . "'");

基本的には、htmlエンコーディングへのインジェクションに使用できるシンボルを変更するだけです。これまでは問題なく動作していましたが、mysqliに移行しているので、プリペアドステートメントがこの関数よりも安全かどうかを知りたいと思いました。

また、準備されたステートメントと準備されていないステートメントの速度の違いについてたくさん読んだことがありますが、それは本当に目立ちますか？私は1秒間に約100回のクエリを実行するので、大きな影響を受けるとは思えません。

ありがとう！

4

3 に答える 3

4

はい、プリペアドステートメントは確かにこの関数よりも安全であり、データベースからデータを取得するときにデータをデコードする必要がないという追加の利点もあります。ちなみに、古いmysqlライブラリの場合mysql_real_escape_stringでも、カスタムビルドのサニテーション関数ではなく、実際に依存する必要があります:)

プリペアドステートメントは、プリペアドされていないステートメントよりもはるかに高速である可能性があり、通常の使用状況では、1秒あたり100クエリを「ちょうど」実行している場合でも、これを利用できます。

于 2012-05-29T18:41:47.870 に答える
3

プリペアドステートメントのセキュリティは、実際、プリペアドステートメントではクエリとデータが別々に送信されることに起因します。これが、第1タイプのSQLインジェクションを実行できなくなる理由です（第2タイプ（または間接）インジェクションは、クエリがデータベース内のデータから連結された場合に発生するものです）。

あなたの「保護機能」の問題は、それがすべての場合をカバーしていないということです。この問題について詳しく知りたい場合は、 SQLインジェクションに関する最近のプレゼンテーションのスライドまたはSQLインジェクションに関するスライドのスライドを読むことができます。AND1 =1だけではありません。

于 2012-05-29T19:01:46.317 に答える
2

決してそうしないでください。

プリペアドステートメントを使用してデータをそのまま保存します。これにより、悪意のあるコードが含まれている場合でも、データベースに元のデータが常に存在します。問題はありません。実際、あなたは彼らがあなたや何かをハッキングしようとした方法を見たいと思っています。

安全でない（ユーザーが送信した）データを出力するときに単純なフィルターを作成して、<>などの不要な文字を置き換えます。

于 2012-05-29T18:41:32.850 に答える