私は独自の cms を持っており、実装および調査すべきセキュリティ オプションを調査しています。
すべての CMS ページは、セッションに保存されているユーザー ID に基づいてユーザー権限をチェックしています。このページ内のフォームを「保護」することは、私にとってどれほど重要なことでしょうか? つまり、ユーザーは SQL ステートメントを作成する機会があるので、SQL インジェクションを使用したい場合はそれほど難しくありません...
だから私の考えは、ログオンページのみを保護し、セッションハイジャックから保護することです.それは正しいですか、それとも何か不足していますか?
フロントページのフォーム、クエリ文字列なども保護されています。
これについての内部に感謝します。
Web アプリの保護は終わりのない作業です。人々は、ツールと方法を組み合わせて、毎日 (文字通り) 悪用するベクトルを見つけています。CMS を構築するときは、次の点に特に注意する必要があります。
これらはすべて、フォームの送信、またはより一般的にはユーザーデータの入力に関係しています。それは 1 つの簡単な教訓に要約されます: ユーザーを決して信頼しないでください。
最初に心配する必要があり、最も危険なのは SQL インジェクションです。これは多くの企業が毎年犠牲になっているものであり、非常に詳細ですが、ほとんどの攻撃はパラメーター化されたクエリ ( TRUEパラメーター化されたクエリ) を使用することで防ぐことができます。PDO はデフォルトでそれらをエミュレートし、真のパラメーター化を有効にする構成フラグがあります。 ）。これにより、SQL 関連のほとんどのサニタイズが効果的に行われ、「適切なサニタイズ」はユーザーに任せられます (つまり、日付が実際に日付であることを確認します)。これにより、人々が一次 SQL インジェクションと呼ぶ傾向のあるもの、つまり直接侵入から保護されます。
二次はもっと難しい。データベースに何かを保存し、別のステートメントで実行する必要があります。CISCOガイドには、物事がどのように起こるかについての良い考えがあります.
SQL が大部分のスクリプトキディを打ち負かすのはこれですべてです。
コンテンツ フィルタリングに関しては、ブラックリストに登録するアプローチではなく、ホワイトリストに登録するアプローチを使用する必要があります。信頼できない、または認識できないものはすべて削除してください。HTML に関して言えば、まさにこれを行う HTMLPurify という素晴らしいツールがあります。
私の上司がした間違いをしないでください。コントローラーの実行後にページをレンダリングする直前ではなく、すぐにセッションを確認してください。