PHP のセマンティック URL を介した Web サイト攻撃を防ぐ方法を共有する

セマンティック URL 攻撃とは何ですか?

多くの攻撃者の主な動機は好奇心であり、セマンティック URL 攻撃はその良い例です。このタイプの攻撃では、主に、何か興味深いものを発見することを期待して URL を編集します。

たとえば、ユーザー chris がソフトウェア内のリンクをクリックして http://example.org/private.php?user=chris ページに到達した場合、ユーザーの値を変更しようとするのは当然のことです。そして何が起こるか見てみましょう。たとえば、http://example.org/private.php?user=rasmus にアクセスして、他の人の情報を参照できるかどうかを確認する場合があります。 GET データの操作は POST データの操作よりもわずかに便利であるだけですが、その露出により、特に初心者の攻撃者にとってはより頻繁に攻撃されることになります。

ほとんどの脆弱性は、特に複雑な理由ではなく、見落としによって引き起こされます。多くの経験豊富なプログラマは、上記の URL を信頼することの危険性をすぐに認識していますが、多くの場合、他の人から指摘されるまでそれに気づきません。

セマンティック URL 攻撃や脆弱性がどのように見逃されるかをよりよく説明するために、Web メール システムを例に挙げます。このシステムの主な機能は、ユーザーがログインして自分の電子メールを表示することです。

ユーザー ログインに基づくシステムには、パスワード取得メカニズムが必要です。通常のアプローチは、攻撃者が知りそうにない質問をすることです (コンピュータのブランドなど、ただし、ユーザーが質問を指定して自分で回答できる方がよいでしょう)。質問が正しく答えられた場合、新しい質問が行われます。登録したメールアドレスにパスワードが送信されます。

Web メール システムの場合、登録時に電子メール アドレスを指定できない場合があるため、質問に正しく回答したユーザーは電子メール アドレスの入力を求められます (新しいパスワードがその電子メール アドレスに送信される間、パスワードはバックアップされます)電子メール アドレス情報も収集される場合があります)。次のフォームは新しいメール アドレスを要求するために使用され、アカウント名はフォームの非表示フィールドに保存されます:

コードをコピー コードは次のとおりです。次のように:

新しいメールアドレスを指定してくださいパスワードを送信しました:



>

受信スクリプトreset.phpが、どのアカウントのパスワードがリセットされるか、どのメールアドレスに新しいパスワードが送信されるかなどのすべての情報を取得することがわかります。 。

ユーザーが (正しい質問に回答した後) 上記のフォームを参照できる場合、そのユーザーが chris アカウントの法的所有者であると考える理由があります。代わりの電子メール アドレスとして chris@example.org を指定した場合、送信後に次の URL にリダイレクトされます:

http://example.org/reset.php?user=chris&email=chris@example .org

URL はブラウザ バーに表示されるため、このステップに到達したユーザーは、ユーザー変数とメール変数の役割を簡単に確認できます。これに気づいたユーザーは、php@example.org が非常に優れたアドレスであると考え、次のリンクにアクセスして試しました:

http://example.org/reset。 chris@example.org

reset.php がユーザーによって提供された情報を信頼する場合、これはセマンティック URL 攻撃の脆弱性です。この場合、システムは php アカウントの新しいパスワードを生成して chris@example.org に送信するため、chris は php アカウントを盗むことに成功します。

セッション追跡を使用すると、上記の状況を簡単に回避できます:

コードをコピーします コードは次のとおりです:

session_start();
$clean = array();
$email_pattern = '/^[^@s<>] @([-a- z0-9 ] .) [a-z]{2,}$/i';
if (preg_match($email_pattern, $_POST['email']))
{
$clean['email' ] = $ _POST['メール'];
$user = $_SESSION['user'];
$new_password = md5(uniqid(rand(), TRUE)); '検証済み' ])
{
/* パスワードの更新 */
mail($clean['email'], '新しいパスワード', $new_password)
}
}
? >


上の例では、一部の詳細 (詳細な電子メール情報や妥当なパスワードなど) が省略されていますが、ユーザーが提供したアカウントに対する不信感が示されており、さらに重要なのはセッションの使用です。ユーザーが質問に正しく答えたかどうか ($_SESSION['verified'])、および質問に正しく答えたユーザー ($_SESSION['user']) を保存する変数。この不信感こそが、アプリケーションの脆弱性を防ぐ鍵となります。

実際には、次の原則を覚えておいてください。

ユーザー入力を信用しないでください (つまり、ユーザー入力の検出です。書くのは面倒ですが、時間内に問題を解決するよりは良いです!)