5

私の Web サイトには、ヘッダー、フッター、およびメイン コンテンツがあります。ユーザーがログインしていない場合、メインのコンテンツでは、実際のコンテンツの代わりにログイン フォームが表示される場合があります。

そのログイン フォーム$_SERVER['REQUEST_URI']で、セッション変数に を書き込みます$_SESSION['redirect']。

ユーザーをログインさせる私のログインフォームポストハンドラーは、このリンクへのログインに成功した後にユーザーを送信しますheader('location: http://myserver.com'.$_SESSION['redirect']);

したがって、myserver.com/somesite.php?somevar=10ログインしている場合は適切なサイトが表示されます。それ以外の場合はログインフォームが表示されますが、ブラウザのアドレスバーの URL にはまだmyserver.com/somesite.php?somevar=10 「資格情報を入力すると にリダイレクトされます」と表示されますmyserver.com/somesite.php?somevar=10。次に、ログインしているので、完全に表示されます。

REQUEST_URIフォーム アクションまたはリンクの href として値を使用しません。

また、$_GET使用する変数は最初に正規表現と一致するかどうかを確認します (通常、変数はsha1文字列またはその他の方法でランダムに生成された数字と文字のみの文字列であり、特別な文字は含まれません)。 db クエリで使用されます。

私の質問は、セキュリティ上の懸念があるかどうかです。これを悪用する方法、URL に悪意のあるものを入力してから、たとえば別のユーザーに送信する方法はありますか? プロセスのどこかで何かをエスケープする必要がありますか?

4

4 に答える 4

1

何でもオンラインに置くことには、多くのセキュリティ上の懸念があります。post/get リクエストで識別可能なパターンを持つことは懸念事項ですが、それは多くの要因に依存します。主に、ユーザーがサイトをいじることで何を得ることができるか、サイト ユーザーの悪意に対してどの程度の責任を負うかです。

ログイン スクリプトへのトラフィックがサイトのユーザーによって実際に生成されていることを確認するには、セッション トークンを使用することが最初にできることです。これら 2 つの一般的なプラクティスは、SQL インジェクションとクロスサイト スクリプティング攻撃から保護するための最初のステップです。優れたデータベース設計と優れたコード設計の両方を通じて、データが確実に保護されるようにするための適切な手順。

私のお気に入りの手法の 1 つは、カスタム http ヘッダーを使用するようにアプリケーションを構成することです。スーパー グローバル チェックからデータを受信するスクリプトは、カスタム ヘッダーがセキュリティのコンポーネントとして正しく提供されていることを確認します。これらのヘッダーは、どのハッカーでも簡単に見たり盗聴したりできますが、悪意のある性質の攻撃の多くは、最初にスクリプトによって実行されます。これは、展開が簡単なもう 1 つの手順であり、これらのタイプの攻撃の標的になりにくくなっています。

PHP ベースのサイトの強化に関する簡単な Google 検索で、この記事が見つかりました。この記事には、いくつかの良いヒントがあります。

于 2013-03-05T02:28:37.997 に答える
1

100% 安全になることはありません。OWASP Top Tenをご覧ください。これらは主なセキュリティの問題です。

の代わりに、$_SESSION で各ユーザーに関連付けられたトークン (乱数) が必要だと思います$_SERVER['REQUEST_URI']。REQUEST_URI を GET で渡し、トークンを POST (非表示の入力) で渡し、それを検証することができます。この URI へのユーザー ログインが必要な場合は、受信したユーザー トークンがセッション ユーザー トークンと同じであることを確認してください。

于 2013-12-16T14:41:25.983 に答える