PHPおよびMySQLでのSQLインジェクションに対する保護

驚いたことに、私はHabréに注射に対する保護のトピックに関する包括的な記事を見つけませんでした。 したがって、私は自分で書くことにしました。





注射に対する保護のトピックに興味を持ち始めたとき、私は常に包括的でコンパクトなルールのセットを策定したかったのです。 時間が経つにつれて、私は成功しました：

注射から私たちを保証するルール

1. プレースホルダーを介してのみリクエストにデータを代入します
2. コードで規定されているホワイトリストの識別子とキーワードのみを置換します。

2点のみ。

もちろん、これらのルールの実用的な実装には、より詳細なカバレッジが必要です。

しかし、このリストには大きなメリットがあります-正確で包括的です。 「mysql_real_escape_stringを介してユーザー入力を実行する」または大衆意識に根ざした「常に準備された式を使用する」ルールとは異なり、私のルールセットは壊滅的な誤acy（最初のような）または不完全な（2番目のような）ではありません。



しかし、先に進みましょう-詳細な分析に移りましょう。

プレースホルダー-データ置換

原則として、すべてがシンプルです。データはリクエストに直接入力されるべきではなく、何らかの代表的なワイルドカード表現を介して取得される必要があります。

リクエストは、たとえば、

SELECT * FROM table WHERE id > ? LIMIT ?
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

データは個別に追加および処理されます。

しかし、「通常のエスケープ」よりも優れているのは何ですか？ そして皆に：

• まず、「エスケープ」はセキュリティとはまったく関係ありません。 想像してみて！
• 第二に、コードが短くなります。 mysql_real_escape_string（）もintval（）もありません-すべての処理は内部に隠されています。
• 第三に、コードが簡単になっています。 リクエストの異なる部分をフォーマットするための異なるルールを覚える必要はありません
• 第4に、プレースホルダーを使用すると（プレースホルダーが正しく処理される場合）、データを介したインジェクションが保証されます。 「これは明らかです！」-あなたは言う-「別のポイントをフェンスすることは価値がありましたか？」 同じエスケープ保護は保証しません。 さらに、フォーマット規則を1つに減らす-ここで何かを混乱させるのは難しいだろう
• 5番目、そして最も重要なことは、データを必要な場所で正確に処理することです！ これは多くの人が理解していない非常に重要なポイントです。 古典的な「楽しい」教科書では、SQLのデータ形式はコード全体に散らばっています。 また、PHPの古いバージョンでは、コード実行の開始前でさえ開始されていました。これは、まったくゲートには入りません！ この状況では、必要に応じて、わずかな利点なしに、一部のデータが2回フォーマットされ、他のデータが半分だけ、さらには他のデータがまったくまたはまったくフォーマットされないという事実につながります。 同時に、SQL用にフォーマットされたデータがHTMLまたはCookieに突然表示されますが、これもユーザーや開発者に喜びを与えません。

したがって、最適なオプションは、リクエストを実行する直前にデータをフォーマットすることです-このようにして、データが正しくフォーマットされていることを常に確認します、これは一度だけ行われ、フォーマットされたデータは意図したとおりになります-データベースにどこにも行かない

そして、それはまさにそのような-タイムリーで安全で正しい-データ処理の目標であり、プレースホルダーが提供することで、セキュリティを保証すると同時にコードを簡素化します。

使用例：

マニュアルから：

 $stmt = $dbh->prepare("SELECT * FROM REGISTRY where name LIKE ?"); $stmt->execute(array("%$_GET[name]%")); $data = $stmt->fetchAll();
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

努力すべき例：

 $ban = $db->getRow("SELECT 1 FROM ban WHERE ip = inet_aton(s:)", $ip);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ご覧のとおり、難しいことではありません。また、巧みに使用すれば、手でリクエストを行うよりもはるかに短くなります。 あなたはまだ昔ながらの方法で書きたいですか？



重要な注意：もちろん、データソースやその他の条件に関係なく、プレースホルダーを介したデータ置換は常に実行する必要があります。

識別子とキーワード-ホワイトリスト

注射に関する記事の大部分は、この点を完全に見逃しています。 しかし現実には、クエリではデータだけでなく、他の要素（識別子（フィールドとテーブルの名前）、さらには構文要素、キーワード）を置換する必要があります。 DESCやANDのように重要ではない場合でも、そのような置換のセキュリティ要件は、それほど厳しくはないはずです！



かなり平凡なケースを調べてみましょう。

製品のデータベースがあり、それはHTMLテーブルの形式でユーザーに表示されます。 ユーザーは、このテーブルをいずれかのフィールドで任意の方向に並べ替えることができます。

つまり、少なくともユーザー側からは、列名と並べ替え方向を取得します。

それらを要求に直接代入することは、保証された注入です。 通常のフォーマット方法はここでは役に立ちません。 識別子もキーワードもない準備された式は、エラーメッセージ以外は何も導きません。

唯一の解決策はホワイトリストです。

もちろん、これはニュートンの二項式ではなく、多くの開発者は外出先でこのパラダイムを簡単に実装します。最初にクエリのフィールド名を置き換える必要がありました。 ただし、この規則のない注入保護に関する記事は不完全であり、保護自体は漏れやすいものです。



このメソッドの本質は、 すべての可能な選択肢をコードにしっかりと記述し、ユーザーの入力に基づいてそれらのみをリクエストに含める必要があることです。

適用例：

 $order = isset($_GET['order']) ? $_GET['order'] : ''; //     $sort = isset($_GET['sort']) ? $_GET['sort'] : ''; $allowed = array("name", "price", "qty"); //  $key = array_search($sort,$allowed); //      $orderby = $allowed[$key]; //  (,     - ) . $order = ($order == 'DESC') ? 'DESC' : 'ASC'; //    $query = "SELECT * FROM `table` ORDER BY $orderby $order"; // 100% 
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

以前は、プレースホルダで識別子に十分であると想定していました。 しかし、時間が経つにつれて、この方法の欠点が理解されるようになりました。

• まず、無効なフィールド名の場合、リクエストによりエラーが発生します。 そして間違いは常に悪い
• 第二に、はるかに重要です：予備フィルタリングなしでフィールド名を自動的に置換する場合、自動的にエスケープするだけで、異なる種類のインジェクションを取得できます-結局、ユーザーは変更しないはずのフィールド名を入力できます！ たとえば、$ _POST配列に基づいてSQLクエリを自動的に生成する場合（フィールド名を正しくフォーマットしている間に！）、ハッカーは、登録時に値「1」のadminフィールドをフォームに追加し、管理者になります

だから今、私は両方の方法を使用します：

最初に、ホワイトリストから識別子を取得します。

そして、プレースホルダーを介して追加します-手動の書式設定を処理しないようにするためです。 そして均一性のために。 この場合、最後の行は次のようになります

 $query = "SELECT * FROM `table` ORDER BY n: $order";
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

基本的に、この情報は完全に安全なクエリを書き始めるのに十分です。 しかし、いつものように、実際の生活にはさまざまなニュアンスがあり、プレースホルダーのメカニズムをより詳細に理解したいと思います。

プレースホルダーを使用する

最初に、プレースホルダーを実装するための2つのオプション（サーバーとクライアント）があることを理解する必要があります。

• 最初のケースでは、リクエストはプレースホルダーとともにサーバーに送信され、データはそれとは別に送信されます。 英語では、「ネイティブ」準備済みステートメント-「ネイティブ」準備済みステートメントと呼ばれます。つまり、プレースホルダーの処理は、サーバー上のDBMS自体によって実行されます。 簡潔にするために、ネームサーバーサーバーのプレースホルダーを使用します。
• 2番目の場合、データはフォーマットされ、クライアント上の直接のプレースホルダーの代わりにクエリ文字列に置換され、従来のSQLクエリを形成し、通常の方法でデータベースに送信されます。

それぞれの方法には長所と短所があり、以下で検討します。

また、PDOはこれらの2つの椅子に同時に座っていることを覚えておく必要があります。デフォルトでは、2番目のオプションに従って動作し、最初のオプションのみをエミュレートします。 この機能を無効にするには、PDOにリクエストとは別にサーバーにデータを送信させる必要があります。

 $dbh->setAttribute( PDO::ATTR_EMULATE_PREPARES, false );
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ただし、エミュレーションさえプログラマーの参加なしで行われるため、以下ではPDOをサーバープレースホルダーの代表として考えます。

サーバーのプレースホルダー

まず始めに、なぜ注射が可能なのでしょうか？

実際、SQLクエリはプログラムです。 完全なプログラム-演算子、変数、および文字列リテラル。 問題は、外出先でこのプログラムを動的に収集することです。 一度だけ記述され、着信データに基づいて変化しないPHPスクリプトとは異なり、SQLクエリは毎回動的に再生成されます。 そして、その結果、誤ってフォーマットされたデータはリクエストを台無しにしたり、場合によっては変更したりして、当社が提供していない演算子を置き換えます。 実際、これはまさに注射の本質です。



プレースホルダーのサーバー処理は何を提供しますか？

非常に簡単なこと：... 変数のようなものをプログラムに導入します ！ はい、プレースホルダーは通常の変数であり、SQLの「スクリプト」にハードコーディングされており、データによっては変化しません。 また、データ自体はリクエストとは別にサーバーに送られ、決して交差することはありません。 リクエストが解釈された後にのみ、データは実行段階で直接使用されます。

実際には、次のようになります：prepare（）を呼び出すと、リクエストはこの形式でサーバーに直接送られます-プレースホルダー/変数を使用して、サーバーはそれを解析し、「すべてが正常で、データを受信する準備ができている」ことを通知します（まあ、またはエラーを報告します）。 そして、execute（）が実行されると、データはすでにサーバーに送られ（テキスト形式ではなく、バイナリパッケージで、クエリ結果が返されるものと構造が似ています）、すでに実行に直接関与しています。



理論的には、非常に魅力的です。

ただし、実際には、残念ながら、PHPでMysqlを操作するための既存のライブラリでは、準備された式を操作する実装はまだ理想からはほど遠いものです。

たとえば、次の事実を引用するだけで十分です。

• 準備された式を使用したクエリの結果文字列を配列（mysql_fetch_array（）のアナログ）に入れるなどのありふれた機能は、バージョン5.3（！）でのみmysqliに追加されました。 このバージョンより前は、ライブラリは実際には不安定で、 地獄のような倒錯がありませんでした。
• 同じことがPDOでの接続のエンコーディングの設定にも適用されます-これは同じ5.3でのみ可能になりました。 以前のすべてのバージョンでは、PDOで接続のエンコードを指定することは単に不可能でした（公平性を考慮して、互換性モードがオフになっている場合、これは大きな問題ではありませんが-穴！）。
• mysqliは、フィールドがデータベースにできるだけ収まるように、できるだけ多くのメモリを予約しようとする場合があります。中程度のテキストには注意してください。

これらの事実は、両方のライブラリがまだかなり未加工であり、他の必要な機能がないことを期待できることを示しています。

既存のライブラリの主な欠点をリストします。

• 冗長性
• いくつかの有用なプレースホルダーの欠如
• デバッグ目的で従来のSQLクエリを取得できない
• 考えられるパフォーマンスの問題*（この問題については以下で説明します）

より詳細に分析します

冗長性。

たとえば、クエリ結果のすべての行を2次元配列に入れるなどの一般的な操作を考えてみましょう。 mysqliにはそのような関数はまだありません。 または、たとえば、変数をプレースホルダーにバインドできるのは、別個の関数のみです。

その結果、1つのリクエストのデータを配列に取得するには、少なくとも9行（！）のコードが必要です。

 $data = array(); $query = "SELECT Name, Population, Continent FROM Country WHERE Continent=? ORDER BY Name LIMIT 1"; $stmt->prepare($query); $stmt->bind_param("s", $continent); $stmt->execute(); $result = $stmt->get_result(); while ($row = $result->fetch_array(MYSQLI_NUM)) { $data[] = $row; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

さらに、このコードのほとんどはセマンティックロードを持たず、実行されたすべてのクエリでまったく同じであり、何百ものスクリプトで何度も繰り返されます。

データを取得するには2行だけで十分であるという事実にもかかわらず：

 $query = "SELECT Name, Population, Continent FROM Country WHERE Continent=? ORDER BY Name LIMIT 1"; $data = $db->getAll($query,$continent);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

PDOの方がこれに少し優れています-配列を実行（）に渡すことができ、fetchAll（）メソッドがあるかどうかがわかりました。 しかし、最も単純な操作のために、不必要な単調なコードをたくさん書く必要があります。

特に、記事のトピックであるバインディングに戻ります。 ここに変数$ _GET ['id'];があります。 プレースホルダーに添付します。 すばらしい、execute（）で直接行うことができますが、配列にすることによってのみ可能です。 なんで？ ドライバー自体が私のためにこれを行うことはできませんか？

機能不全

最近の記事のコメントで既に提起されている別の問題は、IN（）演算子です。 置換を行うことは非常に簡単な作業です。 プレースホルダーが発明されたのはまさにそのような場合であるように思えますが：

 $conts = array('Europe','Africa','Asia','North America'); $query = "SELECT * FROM Country WHERE Continent IN(?) ORDER BY Name LIMIT 1"; $data = $db->getAll($query,$conts);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

数十行の不自然なコードの代わりに。

これからどのような結論を導き出すことができますか？ 終了する必要があります。

SQLクエリを取得できない

誰かが彼はそれを必要としないと言うでしょう、誰かが向きを変えて彼の手で要求を書くか、cなソフトウェアを使用します。 これらの人々の意見を尊重しますが、事実は残ります-完成したリクエストの出力の機能はデバッグに便利であり、サーバーのプレースホルダーはそれを許可しません。

性能

通常、サーバー側で準備された式の謝罪者は、リクエストの解析が一度だけ行われるという事実を強調しています。

残念ながら、Webアプリケーションの場合、これは機能しません。 prepare（）を実行したスクリプトのコピーは、このリクエストに対してexecute（）を正確に1回実行し、安全に終了します。 新しいコピーが再度準備されます。 その結果、保存したい場所により多くの作業が発生します。

最近の記事に対するコメントで、別の潜在的な速度向上-クエリプランのキャッシュ-が指摘されました。 実際、各クエリを準備しても、データベースは異なるデータに対して同じクエリをキャッシュできます。 解析せずに、単純な文字列比較で実行計画を取得します！

残念ながら、私はMySQLの内部構造において、メカニズム自体の存在とその実用的な有効性の両方を確認または否定するほど強くはありません。

同時に、私が知る限り、実際の負荷が大きいと、サーバーが準備した式は標準のSQLクエリの速度を失います。

いずれにせよ、トピックは公開されており、まだ研究者を待っています。 最終的に、DBMSバージョンが大きくなり、テスト結果が古くなってしまいます。



一般に、DBMSとそれを操作するためのドライバーが提供するツールは、広告に見られるほど良くないことがわかりました。 そして疑問が生じます-自分でプレースホルダーとの作業を実装できますか？ そして答えが生まれます-私たちはできます！

プレースホルダーの独立した実装

実際、プレースホルダーに煩わされることなく、既存のライブラリの使いやすさを改善することを妨げるものは誰もいません。 たとえば、独自のPDOプレースホルダー（または1年前にHabréで公開されたライブラリで行われたmysqli）を使用して、不足している機能を実装するPDOのラッパーを作成します。



ただし、自家製のプレースホルダーを検討する理由はいくつかあります。

まず、すでに見たように、標準ライブラリで利用可能なプレースホルダーのセットでは明らかに十分ではありません。

第二に、何らかの理由でサーバーのプレースホルダーが適切でない場合があります。

第三に、プレースホルダーの独立した処理の例では、SQLクエリを正しくフォーマットすることのニュアンスを考慮します。

SQLクエリのさまざまな要素の書式設定の原則

自家製のプレースホルダーを実装するのは簡単です。 プリミティブパーサーは既にPHPに組み込まれています。 必要なのは、リクエストのさまざまな要素を区別する方法を学ぶことだけです。 しかし、これは非常に重要なポイントであり、より詳細に説明する必要があります。

フォーマット規則は要素のタイプに依存するため、まず、どの特定の要求要素に置換するのかを明確に理解する必要があります。 次に、この情報を何らかの方法でプレースホルダープロセッサに伝える必要があります。



まず、クエリを構成する要素を決定しますか？

たとえば、次のようなSQLを考えます。

 INSERT INTO `db`.`table` as `t1` VALUES('string',1,1.5,NOW());
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

要素の3つの主要なグループを区別できます。

• SQL言語要素自体-演算子、組み込み関数、変数など
• 識別子（データベース、テーブル、およびフィールドの名前）
• いくつかの異なるタイプのリテラル（クエリに直接代入されるデータ）。

特別な書式設定のみが必要なため、最後の2つのポイントに興味があります。



次に、ハンドラーの代わりに使用されるデータのタイプに関する情報を報告する方法について考えてみましょう。 利用可能なソリューションは、それを曲がりくねって実行します（これはもはや驚くことではありません）。 2つのオプションがあります：バインディング関数を呼び出すことによってタイプを設定する必要がある（コードを時々すぐに複雑にする）か、実行するためにデータを直接渡す場合（PDOのようにまったく設定しない）。 ただし、型なしでは実行できないため、実行するために転送されるすべてのPDOデータは文字列として扱われます。 PDOが互換モードで動作する場合、これは面白い結果につながります：LIMITを実行するためのパラメーターを渡そうとすると（）、PDOはエラーメッセージでクラッシュします。



一般に、別のソリューションが必要です。 そしてそれは！ ただし、以下で説明しますが、今のところはフォーマットルールについて検討します。

識別子のフォーマット

一般に、識別子の命名規則は非常に広範囲です。 ただし、セキュリティのために、ホワイトリストとフォーマットのみのプレースホルダーを使用することを考慮すると、次の2つで十分です。

• 識別子は、一重引用符（バッククォート）で囲む必要があります
• そのような引用符が名前に含まれる場合、二重にすることでエスケープする必要があります。

 function escapeIdent($value) { return "`".str_replace("`","``",$value)."`"; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

叙情的な余談：

識別子をフォーマットする必要はありますか？ 実際、ほとんどの場合、これは必要ありませんか？

リクエストが手書きで書かれている場合、必要性はその場で判断できます。リクエストは機能します-フォーマットすることはできません。 識別子のエラーでクラッシュします-フォーマットする必要があります。

プレースホルダーを使用する場合、つまり識別子をリクエストに動的に追加する場合、リクエストでどのフィールド名が置換されるか、したがってフォーマットが必要かどうかがわからないため、フォーマットする必要があります。 したがって、すべてをフォーマットします。



実際、一般的なプレースホルダーの使用について話す場合、一貫性のある例外なくフォーマット規則を適用することで、インジェクションおよび重要なエラーに対する保護の保証について話すことができます。 結局、フォーマットは主にリクエストの構文の正確さを保証するために行われます。 そして、注射に対する保護は単なる副作用です。

したがって、「エスケープ」よりも「フォーマット」という用語を使用することを好みます

フォーマット文字列リテラル

最もハックされたトピックのように思えます。しかし、最近の記事の議論が示しているように、多くは理解していなくても、少なくとも言葉遣いではまだ混乱しています。それでは、SQLで文字列をフォーマットするためのルールを定式化しましょう。

• 文字列は引用符で囲む必要があります（単一または二重ですが、識別子には二重を使用できるため、常に単一を使用することをお勧めします）
• 行のリストの特殊文字をエスケープする必要があります。このため、APIは特別な機能を提供します。この関数が正しく機能するには、接続エンコードが正しく設定されている必要があります。

しながら

• これらのルールは、1つだけでなく、常に一緒に適用する必要があります
• それらのいずれも行以外のデータには適用しないでください

それは単純なルールのようですか？しかし、どれだけ多くの人がすべきではないかは驚くべきことです。

PHPドキュメントのmysql_real_escape_string（）に関する記事でも、ゲームは次のように述べています。「この関数を使用しないと、クエリはSQLインジェクションによるハッキングに対して脆弱になります。「-数値または識別子に使用すると、少なくとも何かに役立つように！



しかし、PDO開発者は賞賛することができます-彼らは両方のルールに従って、非常に論理的に行動しました：PDO :: quote（）関数は作業の半分ではなく、全体-文字列をエスケープし、引用符で囲みます。同じことを行います。

  function escapeString($value) { return "'".mysqli_real_escape_string($this->connect,$value)."'"; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

「エンコーディングが正しく設定されている」ことができるのは、関数mysqli_set_charset / mysql_set_charsetおよびPDO-DSN のみであるということを追加するだけです。

数値の書式設定

理論的には、ほとんどの場合、数字は文字列としてフォーマットできます。その後、タスクは以前のものに削減されます。しかし、3つの問題があります

• mysqlのSTRICT MODEモード。有効にすると、文字列を数値として渡そうとしたときにエラーがスローされる場合があります。
• LIMIT演算子。文字列の使用はまったく提供されていません
• mysqlの専門家によると、リテラルのタイプは非常に重要であり、クエリの計画と実行に重要であるとコメントしています。私自身はこれが得意ではないので、詳細なコメントをいただければうれしいです。

一般に、数値もフォーマットします。さらに、プレースホルダーの助けを借りて、これは問題ではありません。

別の問題は、PHPの組み込み型変換メカニズムのビット深度が不十分であることで表されます。したがって、PHP_INT_MAXより大きい整数値を使用する必要がある場合は、検証に正規表現を使用してください。さて、通常の場合、intval（）を使用できます。



PHPにはMySQLの非常に便利なDECIMAL型に似たデータ型がないため、定期的な間隔でのみ小数点付きの数値をチェックすることをお勧めします。

レイジープレースホルダー

それでは、実装に取り​​かかりましょう。

最初に思い浮かぶオプションはsprintf（）です。実際、この関数ファミリーのワイルドカード表現は実際のプレースホルダーです。そしてtipizovannyeプレースホルダ！つまり、データの処理方法は、プレースホルダー自体によって決定されます。実際、これはそれほど重要なことではありません。PDOの作者もmysqliの作者もそのように考えていません。また、特別な関数を呼び出すことによってのみ、これらのライブラリで置換されるデータのタイプを指定できます。



一般に、sprintfは文字列を除くすべてのデータ型を処理します。もちろん、sprintfは行をフォーマットしませんが、そのまま表示します。しかし、これは私たちには適していません-厳格なフォーマット規則があります。そして、それはルールだと、ルールではありません。私たちが思い出すように、逃げることは戦いの半分に過ぎません。

しかし、私たちはプログラマーに引用符を追加することにそれほど重要な仕事を与えることができないので、私たちのコードはそれを自分でやらなければなりません。愚かな文字列の置換。これは理想的なソリューションではありませんが、トレーニングコードに適しています。



さらに、関数に転送されたすべてのデータをエスケープします。はい、それは間違っています。しかし、これによる害はありませんが、sprintf（）の主な利点、つまり文字列を解析するという事実を維持します。

なぜ害がないのですか？結局のところ、私はあなたに、ライン以外のものをエスケープすることは役に立たず危険であると言っただけです！はい、残りのデータを処理しなくなった場合。ただし、プレースホルダーの残りのオプションは数値のみであるため、インジェクションはそれらを通過しません。

その結果、関数を得ました

 function query(){ $query = array_shift($args); $query = str_replace("%s","'%s'",$query); foreach ($args as $key => $val) { $args[$key] = mysql_real_escape_string($val); } $query = vsprintf($query, $args); if (!$query) return FALSE; $res = mysql_query($query) or trigger_error("db: ".mysql_error()." in ".$query); return $res; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

リクエストにデータを代入するという義務にうまく対処します。

さらに、万全を期すために：プレースホルダーを混同し、たとえば、％dの代わりにLIMIT演算子に％sを入れると、開発段階でリクエストエラーが発生しますが、インジェクションは発生しません（エスケープの場合に発生します）。



もちろん、printf（）に基づいた実装には欠点がないわけではありません。リクエストに直接書き込まれたいいね！に加えて、3種類のプレースホルダーのみを確認する必要があります。

しかし、OOPが本当に嫌いな人のために、ここで何年も前に書いた機能を紹介します。設定ファイルにコピーして使用を開始し、クエリを実行する安全な方法を取得します。 4回。



使用例：

 $name = dbget(1,"SELECT name FROM users WHERE id=%d",$_GET['id']); //      $user = dbget(2,"SELECT * FROM users WHERE id=%d",$_GET['id']); //     $sql = "SELECT * FROM news WHERE title LIKE %s LIMIT %d,%d"; $news = dbget(3,$sql,"%$_GET[search]%",$start,$per_page); //  
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

いくつかの厄介さにも関わらず、この関数はよく知られている原則に厳密に準拠して書かれているため、私の心に愛されています。KISSに耐えることができれば、そのアプリケーションはコードを非常に乾燥させます。



しかし、私たちは皆、これが行き止まりのブランチであることを理解しています。そして、完全なクラスが必要です。

残念ながら、記事の量はすでにすべての妥当なサイズを超えており、クラスの作成は別の投稿で行う必要があります。いくつかの質問だけを取り上げます。



まず、私たちのクラスは上記の機能の相続人となり、繰り返しのコードをなくすという高い使命を果たします。したがって、クラスは、プレイホルダーのサポートに加えて、データベースから情報を目的の形式ですぐに取得するための一連のヘルパー関数を提供します。スカラー、1次元配列、2次元配列、1次元配列のフィールドによってインデックス付け、2次元配列のフィールドによってインデックス付け



第二に、クラスでは、型付きプレースホルダーという本当に素晴らしいアイデアを使用します。同時に、PDOという名前のプレースホルダーから利益を得ます。

プレースホルダーを次の形式にします

 [az]:[az]*
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

例えば

 i:
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

または

 s:name
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

最初のケースでは匿名プレースホルダーになり、2番目のケースでは名前付きになります。

最初の文字はタイプを設定し、コロンはプレースホルダーを行の他の要素と区別し、名前はオプションです。



第三に、IN（）演算子（文字列用）の待望のプレースホルダー

 function createIN($data) { if (!is_array($data)) { throw new E_DB_MySQL_parser("Value for a: type placeholder should be array."); } if (!$data) { throw new E_DB_MySQL_parser("Empty array for a: type placeholder."); } $query = $comma = ''; foreach ($data as $key => $value) { $query .= $comma.$this->escapeString($value); $comma = ","; } return $query; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして、それに関するいくつかのコメント。

ご覧のとおり、パーサーは空の配列に例外をスローします。なんで？

mysqlは空のIN（）を誓うので、とにかくリクエストを実行するのは無意味です。

どこかで破裂音と引用符がエッジの周りに付いた機知に富んだバージョンを見ましたが、これはできません。空の文字列は正直な値ですが、配列で明示的に渡された場合にのみ探すのが理にかなっています。



dbSimpleライブラリのDmitryKoterovは、この問題をかなりうまく解決しています。IN演算子を含むブロック全体が中括弧で囲まれ、空の配列の場合、リクエストから完全に削除されます。私はこの決定の正しさを確信していませんが、少なくとも非常に機知に富んでいます。



更新：

zerkmsとdavid_mzがファイルされたというアイデアのおかげで、空の配列の問題は非常に簡単に解決されることがわかりました！

 IN(NULL)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

エラーをスローせず、常にFALSE-空の配列の理想的な表現を返します。

つまり、それをNULLに置き換えるだけです。

 function createIN($data) { if (!is_array($data)) { throw new E_DB_MySQL_parser("Value for a: type placeholder should be array."); } if (!$data) { return 'NULL'; } $query = $comma = ''; foreach ($data as $key => $value) { $query .= $comma.$this->escapeString($value); $comma = ","; } return $query; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このような考慮事項から、最初の例外を残すことにしました。

理論的には、スカラーを配列に変換し、通常の方法でさらに処理することができます。しかし、このような隠しタイプの変換は、言語には馴染みがありますが、論理的なエラーに満ちています。

その結果、配列がコード内で形成される場合、このチェックは開発段階で形成のすべてのエラーをキャッチするのに役立ちます。さて、配列が外部から来た場合、さらに例外をスローする必要があります。

</ update>



私自身は、アレイの予備検証を行ったバリアントを作成しました。別のクラスメソッドがこれに役立ちます-解析（）は、プレースホルダーで文字列を解析し、渡されたパラメーターを置換し、既製のSQLクエリを生成します...またはその一部（結局、サーバー側のプレースホルダーの場合とは異なり、リクエストの任意の部分を簡単に解析できます！ ）そして、1つ目がデバッグに役立つ場合、2つ目は私たちのような場合です。

 if (is_array($array) and $array) { $sql .= $db->parse(" AND type IN(a:)",$array); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

また、このメソッドを使用して、複数階の条件付きWHEREを構成できます。

 $w = array(); $where = ''; if (!empty($_GET['type'])) $w[] = $db->parse("type = s:", $_GET['type']); if (!empty($_GET['rooms'])) $w[] = $db->parse("rooms IN (a:)",$_GET['rooms']); if (!empty($_GET['max_price'])) $w[] = $db->parse("price <= i:", $_GET['max_price']); if (count($w)) $where = "WHERE ".implode(' AND ',$w); $data = $db->getArr("SELECT * FROM table $where LIMIT i:,i:",$start,$per_page);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ちなみに、前述のDbSimpleライブラリは、ここで提示されているほとんどのアイデアの簡単な実装の例として個別の段落として言及する価値があります（特に、100,500種類以上のネイティブの型付きプレースホルダへの自己記述プレースホルダの翻訳）。たぶん10年前ですが、何らかの理由で広く流通しませんでした。

迷信暴露セッション

誤解について少し話しましょう。

私は、Web開発のこのようなトピックについては知りません。それは、同様の数の妄想や迷信で大きくなりすぎていたでしょう。それが標準化のテーマですか？

どうやら、ここでのメカニズムはこれです：我々は非常に早い段階で、非常に初期の注射に対する保護の基本を知るようになります。そして、学んだルールは、揺るぎない真実の基礎として記憶されています。そして、今後はこの問題の検討に戻りません。そしてそれは必要でしょう。

加えて、いつものように、インターネット上にはほとんど意味のある情報はありませんが、怠inessはそれを自分でテストして理解することです。その結果、既存の迷信に加えて、新しい、それほどプロフェッショナルではない迷信がインターネットに放り込まれています（そして大衆に取り上げられています！）それらのいくつかに対処してみましょう。

Mysql_ *関数はPHPで長らく廃止されました

悲しいトピック。

怠lazと無知が美しい図書館を埋める物語。



まず、「機能」ではなく、拡張全体です。

第二に、非推奨ではありませんが、落胆し、そしてずっと前ではありませんが、最近では。砂糖でもありませんが、配合をより正確にする必要があります。

第三に、この美しく安定したライブラリを放棄する本当の理由はありません。そして、彼らが彼女を言語から除外したい唯一の理由は、それをしたいメンテナがいなかったからです。まあ、それに加えて、社会自体がそれを正しく処理する方法を学んでいないという事実によってのみ発展した否定的な世論。ただし、スクラップに対する議論はありません。マニュアルの大きな赤い警告は、mysql拡張機能から緊急に移行する必要があることを示しています。



しかし、このフレーズにはもう1つ微妙なニュアンスがあり、これは非常に重要です。多くの初期開発者が理解していないもののカテゴリーから。

「mysql_ *関数」について具体的に説明する場合、アプリケーションコードでは実際にそうすべきではありません。 mysqli_ *、pdo_ *関数、またはその他のベアAPI呼び出し。ここでは、コードではなくアプリケーションコードについて説明していることに注意してください。API関数へのすべての呼び出しはライブラリにパッケージ化する必要があり、アプリケーションコードではライブラリ関数にアクセスする必要があります。そして、これらすべてのmysql（i）_query（）、およびmysql（i）_fetch_array（）を使用して特定のクエリを実行すると、残念ながらプロ意識が失われます。

この理由は基本的に非常に単純です：API関数は非常に冗長です。データベースからデータの行を取得するには、1ダース行を書き込む必要があります。そして、これは、エラー処理、ロギング、リクエストのプロファイリングなど、必要なものを考慮していません。その結果、API関数をコードで直接使用すると、一方ではひどく冗長になり、他方では十分に機能しなくなります。

PDO作成者はライブラリをより使いやすくしようとしましたが、私の意見では、十分ではありません。また、PDOへの呼び出しは、独自のクラスのメソッドで同じ方法でカプセル化する必要があります。

別の引数-ここで、mysql_ *を別のものに変更する必要があります。単一のライブラリファイルでは、これは数十のプロジェクトよりもはるかに簡単です。

特効薬はありません

ご覧のとおり、あります。実装と従いやすい非常にシンプルなルールのセット。

私もすぐに成功しなかったと言わなければなりません。最初はリストは網羅的ではなく、その後コンパクトでした。

逃げる

迷信がたくさんあります。上記の説明の後、質問が残っていないことを願っていますが、念のため：

• 「mysql_real_escape_string関数の問題は、まったく使用されないことです」-これはナンセンスです。mysql_real_escape_string（）関数の唯一の問題は、非常に多くの人々がそれが何のためにあるのか理解していないことです。
• 「受信データにはエスケープが必要です」-もちろん、そうではありません。文字列にはエスケープが必要です
• « „“ „“» — . «» . , , , , —
• « - » — , ? . , .
• « » — , , . , — . — , SQL . PDO, — , , . PDO . , , «» . PDO «», .

«»

「UNION」、一重引用符など。保護の非常に面白い方法。著者のサイトで別のバージョンを真剣に提供しているのを見たとき、サイト自体が保護されている場合はどうなるかを常に尋ねたいのですが。私たちの悲惨な発明者は、それらの非常に「危険な」「ストップワード」を含む投稿を公開できませんでした。

ユニバーサルデータ保護機能

また、初心者のphpshniksの間では非常によくある誤解です。 「私たちは、入力データのすべての「有害な文字」を殺すことで、インジェクションから身を守る汎用機能を入力に入れました！」

しかし、すでにわかっているように、「有害な」キャラクターは存在しません。特定のコンテキストでのみ特定の意味を持つサービスキャラクターのみが存在します。それ以外の場合は完全に安全です。

また、まずセキュリティが必要ではなく、データの正しいフォーマットが必要であることがわかりました。そして、これは、どのコンテキストで使用されるかがわかっている場合にのみ実行できます。残念ながら、スクリプト入力ではまだこれを知りません。このアプローチの鮮明な例は、悪名高いmagic_quotesディレクティブです。これは幸いなことに、言語から削除されています。まったく必要のないデータを処理することで、セキュリティの幻想を作り出し、ラインのみを保護します（そして、外部からスクリプトにのみ陥ります）。

そのため、これらのエラーを繰り返さないでください。スクリプトに入った直後にデータをSQL用にフォーマットしないでください。

エンコーディング

. .

, « » , mysql_real_escape_string() (!)

, , mysql_real_escape_string() « », . — latin1, , mysql_real_escape_string() mysql_escape_string().

同時に、2006年には、mysql_real_escape_string（）関数にmysql拡張機能の現在のエンコーディングを伝える方法がありませんでした。しかし、それ以来、進歩は非常に進み、ツールが登場しました-mysql_set_charset（）関数です。これは、SET NAMES要求の代わりにクライアントエンコーディングを設定するために使用する必要があります。



いずれにせよ、注入は一部のエキゾチックなエンコーディングに対してのみ可能です。すべてのシングルバイトエンコーディングとUTF-8は安全ですので（その結果、悪名高いaddslashes（）もそれらに適しているという事実です）。



当時、私はそれがすべてどのように機能するかをチェックするのが面倒ではありませんでした。私は確信していました-予測どおりに機能します。



先ほど述べた特徴的な詳細：

最近まで、PDOでは接続のエンコードをまったく設定できませんでした。PDOにはmysql_set_charset（）に似た関数はなく、バージョン5.3より前のDSNにはcharsetパラメーターのダミーのみがあり、エラーを生成せず、エンコードも公開しませんでした。

本質的に特別なことは何もありません。PDOがすべてに対して保護する方法について話すキャラクターをトロールする能力を除いて。

「LIKEの脆弱性」

LIKEには脆弱性が1つしかありません。この演算子を他の目的に使用することです。

何らかの理由で、記事のすべての種類のコンパイラーは、表現にメタキャラクターを代入する可能性がある初心者を怖がらせるのが大好きです。同時に、LIKEが使用されている場合、メタ文字はである必要があることを誰も書きません。そうでなければ、LIKEは意味をなしません。つまり、この脆弱性に対処する正しい方法は、％文字と_文字をエスケープすることではなく、たとえばパスワード検証など、完全一致に関心がある場合はこの関数を使用しないことです。以上です。

おわりに

この記事の目的はmysql拡張機能を修復することではありませんが、よくあることですが、問題はツールではなく、それを保持する手にあることに注意してください。そして、それらの達成のための目標とメカニズムの理解があれば、「時代遅れの」ツールで、あなたはより悪い結果を得ることができます。

したがって、私は別の代わりに1つの「宗教」を植え付けようとせず、古い方法を置き換える新しい方法を宣伝しましたが、私たちが達成したい目標、理由、およびそれを達成するためのオプションを説明しようとしました。

そして、少なくとも少し成功すれば、タスクが完了したと考えます。



更新： mysqlでの便利な作業とSQLインジェクションに対する保護のためのクラスで、記事で概説されている原則を実装します。