0

「セキュリティを強化しすぎていませんか?」という問題に直面しています。または「セキュリティが低すぎますか？」

まず、「メッセージの投稿」機能と「メッセージの編集」機能を実装する必要があります。

基本的なテーブル構造は次のとおりです。

id, user_id, category_id, message_title, message_content

これらの 2 つの方法は非常に簡単に実装できるように思えますが、セキュリティやハッカーのことを考えると心配になります... ここで私が心配することがあります。

メッセージの投稿について:

  1. ユーザーはデータベースに非常に長いメッセージを送信しますか?
  2. ユーザーはデータベースを破壊するために SQL インジェクションを行いますか?
  3. ユーザーはメッセージを投稿し続け、データベースがいっぱいになりますか?
  4. ユーザーは無効な を送信しますcategory_idか? (たとえば、削除されたか、まだ表示されていないか、このユーザーはそのカテゴリを使用できません)

メッセージの編集について:

  1. ユーザーは自分のものではないメッセージを編集しますか? (ハックid)
  2. ユーザーは無効なメッセージを編集しますidか? (たとえば、削除された、またはまだ表示されていない)
  3. ユーザーはデータベース内の SQL インジェクション ステートメントを編集しますか?
  4. ユーザーはデータベース内の長いメッセージを編集しますか?
  5. ユーザーは無効な を編集しますcategory_idか? (たとえば、削除されたか、まだ表示されていないか、このユーザーはそのカテゴリを使用できません)

気になる質問がいくつかあります。次の 2 つのタイプに分類できます。

  1. 技術的なセキュリティの問題。(例: SQL インジェクション、メッセージ長)
  2. プログラムロジックの問題。（たとえば、category_idそのユーザーには許可されていません）

技術的なセキュリティの問題は、インターネット上の標準ライブラリを使用して実装できると思いますが、プログラム ロジックの問題に頭がおかしくなりました。すべてのチェックを実装する必要がありますか? たとえば、関連する SQL コマンドを実行する前に、それが存在するcategory_idことuserを確認し、存在することを確認します。id実装できますが、非常に時間がかかります。それとも、すべての入力が有効であり、ユーザーがシステム内で奇妙なことをハッキングしないと想定する必要がありcategory_idますか? お知らせ下さい。

4

1 に答える 1

1

Paul Cが言うように、ユーザーを決して信頼してはいけません。または、むしろ、ユーザーがデータ入力で発生する可能性のあるすべてのエラーと、データベースをハッキングするための悪意のある試みをいくつか行うことを信頼する必要があります。

入力検証の記述にかかる時間は、データベースの問題を修復するのにかかる時間よりもはるかに短くなります。それでも、同様の問題を防ぐために入力検証を追加する必要があります。最初からすべてを検証する方がはるかに簡単です。

于 2013-01-23T03:23:30.807 に答える