ajaxリクエストを検証する方法は正しいページからのものであり、改ざんされていませんか？
PHP、HTML、JSを使用した簡単なQ＆Aアプリを作成しています。 users、questionとanswersの3つのテーブルがあります。各テーブルには独自の主キーがあり、questionsとanswersには両方とも外部キーがあります重要な制約。 questionsストアusers.uID作成者を検索し、answersストアquestion.qID彼らが属している質問を特定し、回答を書いた著者も特定するため、users.uIDも外部キーです。
そして、これが私の主な関心事です：回答の送信ボタンを適切に実装する方法です。これは、著者IDと、jaxリクエストを介してanswersテーブルに挿入されることになっている質問IDを渡すため、そのIDを取得する必要があります。どこかから。主な関心事はXSRFではなく、IDが目に見える（または目に見えない）どこかに格納されている場合に、HTMLコードの一部を変更することにより、許可されたユーザーがXSRFを改ざんできるという事実です。
ユーザーIDは簡単で、DBから取得してセッションに保存し、ユーザーがログインすると他の場所でも再利用できるため、パフォーマンスコストの面で大きな問題はなく、ユーザーから隠された状態ですべてのスクリプトからアクセスできます。しかし、ユーザーが質問にアクセスするたびにセッションに質問IDを保存し、ユーザーが別の質問にアクセスしたときにそれを別の質問IDに置き換えることは、ある時点でサーバーに重い負荷をかけることを求めているように思えます。
ハッシュを送信ボタンに追加すると、ajax呼び出しデータを処理するスクリプトによって検証されますが、セッションにもそのハッシュを保存する必要があるため、私にとっても面倒です。また、隠しフィールドを使用することも安全ではありません。ユーザーがソースコードでそのフィールドを確認し、改ざんできるためです。
それでは、その質問IDを効率的に格納する場所はどこですか？そうすれば、送信ボタンが押されたときに準備が整い、そのユーザーはそれを改ざんできず、他のIDでajax呼び出しを送信できますか？セッションは本当に唯一のオプションですか？
主な関心事はXSRFではなく、IDが目に見える（または目に見えない）どこかに格納されている場合に、HTMLコードの一部を変更することにより、許可されたユーザーがXSRFを改ざんできるという事実です。
ユーザーが提供したユーザーインターフェースを迂回しないようにしたいという要望を理解しました。ただし、これは簡単ではなく、セキュリティも向上しません。
- 関連するユーザー状態をサーバー側に保存し、ユーザーが提供する状態と比較する必要があります。同じ状態が2か所にあるため、これらの状態が同期しなくなる可能性は常にあります。ユーザーがアクションを中止した場合、またはネットワーク接続が中断された場合。ユーザーは、複数の状態を持つこともできます。複数のブラウザータブでWebアプリを使用している場合。
- ユーザー状態の暗号化署名を作成し、この署名をトークンとしてユーザーに与えることもできます。ユーザーは各リクエストでトークンを送信する必要があるため、サーバーでトークンを検証できます。ただし、このトークンがnonceとして実装されていない場合でも、リプレイ攻撃の可能性があります。
これらはすべて間違いやすく、意図したとおりに機能しない場合、ユーザーに多大な不満をもたらす可能性があります（Cookieを削除しないと、使用できないサイトがいくつかあります）。この取り組みは、オンラインバンキングや、申し訳ありませんが安全であることが求められる同様の問題領域に適しています。他のドメインでは、これはユーザーに敵対的であると認識される可能性が高くなります。
ユーザーが提供したリンクに固執していることを確認する代わりに、ユーザーが実行しようとしているアクションに必要なpermissionsがあることを確認します。
- 一般に、リソースの表示、作成、または変更が許可されている場合、ユーザーがURLを操作した場合でも、ユーザーがそのアクションを実行できるようにします。
- リソースへのアクセスが許可されていない場合は、正しいURLを推測できても拒否します。多くのデータ「違反」の原因は、プライベートデータがアクセス許可モデルによって保護されておらず、他のユーザーが知らないはずの「秘密の」IDによってのみ保護されていることです。ただし、攻撃者によって推測または傍受される可能性があります。
ユーザーがアクセスを許可されているリソースの悪用を防ぐには：
レート制限を使用します。例えば。 Q＆Aシステムでは、通常のユーザーは10分以内に5つの回答を投稿することはできません。
特にユーザーのコンテンツが公開されている場合は、ユーザーが作成したコンテンツにフラグを付けてレビューするシステムを開発します。
Webアプリを使用するときにユーザーがボットに頼っている場合、重要な機能が不足している可能性があります。スクレイピングよりも便利なAPIを提供します。場合によっては、CSVへのエクスポートボタンがすべてのユーザーに表示されないことがあります。
サーバー上のすべての「重要な」データを暗号化し、暗号化された値を非表示フィールドに格納します。クライアント側のスクリプトで使用する必要がある場合は、暗号化されていない形式で同じデータを公開できます。
また、「サーバーの高負荷」を恐れないでください。スケーリングには多くの方法があり、データベースへの負荷がおそらく一番の懸念事項になります。