ホームページ  >  記事  >  バックエンド開発  >  PHP および SQL インジェクション攻撃 [3]_PHP チュートリアル

PHP および SQL インジェクション攻撃 [3]_PHP チュートリアル

WBOY
WBOYオリジナル
2016-07-21 15:55:03920ブラウズ

最近忙しいので連載は続けていきます(笑)半月以内に終わらせたいと思います。

上記では、データベースに付属する安全でない入力フィルタリング機能について説明しましたが、この機能はすべてのデータベースで利用できるわけではありません。現在、このような機能を備えているのは MySQL、SQLite、PostgreSQL、および Sybase だけですが、Oracle や SQL Server を含む多くのデータベースにはありません。

この状況を考慮して、開発者は通常、安全でないデータがデータベースに書き込まれることを避けるための一般的な方法である Base64 エンコーディングを採用します。これにより、問題を引き起こす可能性のある特殊文字によって引き起こされるすべての危険が回避されます。ただし、Base64 エンコード後のデータ容量は約 33% 増加し、より多くのスペースを必要とします。 PostgreSQL では、Base64 でエンコードされたデータの使用には別の問題があります。つまり、「LIKE」クエリを使用できないということです。

ここまでをまとめると、データベース自体の文字列マスキングだけに依存するだけでは十分ではないことがわかります。危険な文字がクエリ ステートメントに影響を与える前に、それらを除外するソリューションが必要です。事前定義されたクエリ (準備されたクエリ/準備されたステートメント) は非常に優れた方法です。事前定義されたクエリとは何ですか?これは、クエリ ステートメントの構造と一部の部分のデータ型を定義するクエリ ステートメント テンプレートに相当します。送信した SQL ステートメントがこのテンプレートの定義を満たしている場合は実行され、そうでない場合は実行されず、エラーが報告されます。

例:

pg_query($conn, “PREPARE stmt_name (text) AS SELECT * FROM users WHERE name=$1”);
pg_query($conn, “EXECUTE stmt_name ({$name})”); ( $conn, “DEALLOCATE stmt_name”);

PREPARE stmt_name (text) AS .. ここでの $1 を除くすべての文字はプレースホルダーであり、変更は許可されません。はは、この方法は本当に良い方法だと思います。残念ながら、すべてのデータベースがこれをサポートしているわけではありません。 。

http://www.bkjia.com/PHPjc/318370.htmlwww.bkjia.comtru​​ehttp://www.bkjia.com/PHPjc/318370.html技術記事最近忙しいので連載は続けていきます(笑)半月以内に終わらせたいと思います。 データベースに付属する安全でない入力フィルタリング機能については前述しましたが、この機能はすべてのデータベースで利用できるわけではありません。現在...
声明:
この記事の内容はネチズンが自主的に寄稿したものであり、著作権は原著者に帰属します。このサイトは、それに相当する法的責任を負いません。盗作または侵害の疑いのあるコンテンツを見つけた場合は、admin@php.cn までご連絡ください。