#####SQLコードインジェクション防止の８のベストプラクティス
https://snyk.io/blog/sql-injection-cheat-sheet/
######第8章です。
- クライアントサイドの入力バリデーションに依存しない
- 制限された権限を持つデータベースユーザーを使用する
- プリペアドステートメントとクエリパラメータ化を使用する
- コードをスキャンしてSQLインジェクションの脆弱性を探す
- ORMレイヤーを使用する
- ブロックリストに依存しない
- 入力バリデーションを行う
- ストアドプロシージャに注意する
8.ストアドプロシージャに注意
多くのデベロッパが、SQLインジェクションを防ぐには、ストアドプロシージャを使用するのが良いと思っています。しかし、必ずしもそうとは限りません。アプリケーションで作成したSQLクエリと同様に、ストアドプロシージャにも悪意のあるインジェクションが可能です。
アプリケーションのSQLクエリと同様に、ストアドプロシージャのクエリもパラメータを連結するのではなく、パラメータ化する必要があります。ストアドプロシージャへのSQLインジェクションは、非常に簡単に防ぐことができます。
ですから、MySQLではこのようなことをしないでください。
DELIMITER // CREATE PROCEDURE FindUsers( IN Username VARCHAR(50) ) BEGIN
SET @Statement = CONCAT('SELECT * FROM User WHERE username = ', Username, ' );
PREPARE stm FROM @Statement; EXECUTE stm;
END // DELIMITER ;
ストアドプロシージャでは、パラメータ化されたクエリを使用してください。
DELIMITER // CREATE PROCEDURE First( IN Username VARCHAR(50) ) BEGIN
PREPARE stm FROM 'SELECT * FROM User WHERE username = ?'; EXECUTE stm USING Username;
END // DELIMITER ;
上記のように、、アプリケーションのコードと同じルールがストアドプロシージャに適用されます。ストアドプロシージャの実装方法は、データベースによって異なります。利用しているデータベースのストアドプロシージャの実装方法を確認し、そこでもインジェクションに注意してください。すべてのロジックをアプリケーション内で行うことが望ましいとは思いますが、開発する言語でプリペアドステートメントが利用できない場合、ストアドプロシージャは合理的な解決策となります。
8つめは以上です。
最後までお読みいただきありがとうございました！
######最終章は以上です。
SQLインジェクションに関する英語全原文はこちらです。
######Contents provided by:
Jesse Casman, Fumiko Doi, Content Strategists for Snyk, Japan, and Randell Degges, Community Manager for Snyk Global