1

フォームのなりすましを防止するフォーム ヘルパーを開発しようとしています。だから私はこれを思いついた:

<form...>
<?=form::secure()?>
...
</form>

ユーザーセッションのIDのmd5であるトークンをキー「_token」で隠しフォームにスタンプします(これはランダムで、1週間後に更新されます)。そして、「アクション」URL (フォームから):

$token = (isset($_GET['_token'])) ? $_GET['_token'] : null;
$token = (is_null($token) and isset($_POST['_token'])) ? $_POST['_token'] : $token;
if (form::is_secure($token)) { // checks if the given token is equal to md5(user id)
    ...ok...
} else {
    ...error...
}

それはフォームのなりすましを防ぎますか、それとも何か不足していますか? ユーザーがページを読み込んでフォームを送信した直後にユーザー ID の有効期限が切れた場合、エラーが出力され、フォームを再度送信する必要がありますが、これは問題ありません (まれです)。

ここで失敗する可能性がある唯一のことは、潜在的な攻撃者がユーザーのセッション ID を取得でき、そのリクエストに ?_token=id を添付して、ユーザーが参照できるようにすることだと思いましたが、その時点で、攻撃者がユーザー セッション ID を持っている場合、攻撃者はとにかくやりたいことを実行できます。

私は正しいですか?そうでない場合、目標を達成するためにコードを編集するにはどうすればよいですか?

4

2 に答える 2

5

トークンは有効なセッションを検証する必要があるため、余分なものを追加せずにセッションのセキュリティ層を繰り返すだけなので、事実上車輪を再発明しています. これは、誰かにパスワードの入力を求めてから、確認のためにもう一度入力を求めるのと同じです。誰もが気分が良くなるかもしれませんが、パスワードが侵害された場合、攻撃を遅くするだけで、攻撃を防ぐことはできません.

これは、これらのことを真剣に受け止めるべきではない、またはあなたの試みを却下するべきではないことを示唆しているわけではありません. GETフォームの内容 (または経由で渡されるもの) が私の哲学です。POST)は、セキュリティや計算などの他のロジックから分離する必要があり、サーバーはユーザー提供のデータをユーザー提供のデータ以外のものと見なすべきではありません。理想的には、誰でもフォーム アクションに何でも投稿でき、サーバー/コントローラーがそれを正しく一貫して管理します。セッションが検証され (セキュリティ)、データがサニタイズされてから検証され、ユーザーが実際に Web フォームを使用しているときに JS を介して生成された値が再計算/検証されます。応答は、理想的には、要求元 (Web ブラウザー、コマンド ライン ユーザー、または Web サービス) が解釈できるように、リダイレクトまたは Web 標準応答のいずれかで十分に汎用的です。

上記の場合、スプーフィングの強調と懸念が減り、セキュリティ層と検証層を別々に強化することがより強調されます。そして何よりも、これをうまく行ったバックエンドコントローラーは、次のように簡単に移植/再利用できます。 Web サービス バックエンド。

簡単に言えば、あなたのソリューションは悪くありません。私が知る限り、実際のセキュリティを追加していないだけでなく、バ​​ックエンドのセキュリティ ロジックを公開することさえあります。特定のスプーフィングに関する懸念や脅威がある場合は、万能のソリューションをすぐに考え出すよりも、そのユース ケースに対処して解決策を講じる方がよいでしょう。ユースケースには、交換のさまざまなポイントで対処する必要がある特定のソリューション/考慮事項があることが判明する場合があります。

于 2012-06-27T00:02:31.603 に答える
1

車輪を再発明しないでください。Web フレームワークを使用していない場合は、CSRF4PHPなど、CSRF 保護をプロジェクトに追加する無数のライブラリの 1 つを統合します。

あなたのソリューションは近いですが、攻撃者がセッション ID をスクレイピングできるため、機能しません。

于 2012-06-27T00:34:25.043 に答える