0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 1 year has passed since last update.

SQLインジェクションを防ぐ 〜1

Last updated at Posted at 2021-11-18

#####SQLコードインジェクション防止の8のベストプラクティス
https://snyk.io/blog/sql-injection-cheat-sheet/

######第一章です。

序章から、早速1つ目、クライアントサイドの入力バリデーションに依存しないについてご紹介します。

序章

  1. クライアントサイドの入力バリデーションに依存しない
  2. 制限された権限を持つデータベースユーザーを使用する
  3. プリペアドステートメントとクエリパラメータ化を使用する
  4. コードをスキャンしてSQLインジェクションの脆弱性を探す
  5. ORMレイヤーを使用する
  6. ブロックリストに依存しない
  7. 入力バリデーションを行う
  8. ストアドプロシージャに注意する

チートシート(英語)はこちら

1.クライアントサイドの入力バリデーションに依存しない

クライアントサイドの入力バリデーションは有用です。クライアントサイドの入力バリデーションを使用することで、無効なものがシステムロジックに送信されるのを防ぐことができます。ただし、残念ながら、これは悪意がなく、設計どおりにシステムを使用したいユーザーにしか通用しません。特定の値が無効であるという直接的なフィードバックをユーザーに提供することは、非常に有益で、ユーザーフレンドリーです。したがって、ユーザーエクスペリエンスを向上させるためには、クライアントサイドバリデーションを使用すべきです。

しかし、SQLインジェクションの観点からは、この方法には頼るべきではありません。ブラウザに読み込まれているJavaScriptコードを変更することで、クライアントサイドのバリデーションを削除できます。また、クライアントサーバ型のアーキテクチャでは、postmanのようなツールや昔ながらのcurlコマンドを使い、バックエンドへの基本的なHTTPコールにSQLインジェクションを引き起こすパラメータを指定することは非常に簡単です。

バリデーションはサーバーサイドで、理想的にはできるだけソースに近い場所で行うべきです。この場合、SQLクエリを作成する場所でバリデーションします。クライアントから送られてくるものはすべて潜在的に有害であると考えるべきです。ですから、SQLインジェクションの観点から、クライアントサイドのバリデーションに頼るのは、とても危険です。

1つ目は以上です。
最後までお読みいただきありがとうございました!
######次回はSQLインジェクションを防ぐ 〜2に続きます。

SQLインジェクションに関する英語全原文はこちらです。


######Contents provided by:
Jesse Casman, Fumiko Doi, Content Strategists for Snyk, Japan, and Randell Degges, Community Manager for Snyk Global

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?