SQLコードインジェクション防止の８のベストプラクティス
第一章です。
序章から、早速１つ目、クライアントサイドの入力バリデーションに依存しないについてご紹介します。
序章
1. クライアントサイドの入力バリデーションに依存しない
2. 制限された権限を持つデータベースユーザーを使用する
3. プリペアドステートメントとクエリパラメータ化を使用する
4. コードをスキャンしてSQLインジェクションの脆弱性を探す
5. ORMレイヤーを使用する
6. ブロックリストに依存しない
7. 入力バリデーションを行う
8. ストアドプロシージャに注意する
1.クライアントサイドの入力バリデーションに依存しない
クライアントサイドの入力バリデーションは有用です。クライアントサイドの入力バリデーションを使用することで、無効なものがシステムロジックに送信されるのを防ぐことができます。ただし、残念ながら、これは悪意がなく、設計どおりにシステムを使用したいユーザーにしか通用しません。特定の値が無効であるという直接的なフィードバックをユーザーに提供することは、非常に有益で、ユーザーフレンドリーです。したがって、ユーザーエクスペリエンスを向上させるためには、クライアントサイドバリデーションを使用すべきです。
しかし、SQLインジェクションの観点からは、この方法には頼るべきではありません。ブラウザに読み込まれているJavaScriptコードを変更することで、クライアントサイドのバリデーションを削除できます。また、クライアントサーバ型のアーキテクチャでは、postmanのようなツールや昔ながらのcurlコマンドを使い、バックエンドへの基本的なHTTPコールにSQLインジェクションを引き起こすパラメータを指定することは非常に簡単です。
バリデーションはサーバーサイドで、理想的にはできるだけソースに近い場所で行うべきです。この場合、SQLクエリを作成する場所でバリデーションします。クライアントから送られてくるものはすべて潜在的に有害であると考えるべきです。ですから、SQLインジェクションの観点から、クライアントサイドのバリデーションに頼るのは、とても危険です。
１つ目は以上です。
最後までお読みいただきありがとうございました！
次回はSQLインジェクションを防ぐ 〜2に続きます。
SQLインジェクションに関する英語全原文はこちらです。
Contents provided by:
Jesse Casman, Fumiko Doi, Content Strategists for Snyk, Japan, and Randell Degges, Community Manager for Snyk Global