PCI に準拠する必要がある e コマース サイトがあります。私が抱えている問題は、XSS 攻撃で失敗することです。
www.mydomain.com?qs=%3c%2fscript%3e%3c script%3ealert(12345)%3c%2fscript%3e
.htaccess で悪意のあるスクリプト タグを取り除き、ユーザーを別のページにリダイレクトする方法はありますか? それとも、間違った木を吠えていますか?
最善の方法は、コード内のユーザー入力を信頼しないことです。たとえば、htmlspecialcharsなどを介して実行せずに、ユーザーが提供したデータをブラウザーにエコーバックしないでください。これは、SQL インジェクション攻撃と同じカテゴリに属しますが、インジェクションは SQL クエリではなく、生成された HTML コードを対象としています。
ユーザー提供データは、クライアント側から改ざんされる可能性のあるすべてのデータです。これには、$_POST、$_GET、ファイルのアップロード、Cookie、および HTTP ヘッダー (User-Agent や Referer など) が含まれます。このようなデータは常に信頼できないものとして扱う必要があり、コンテキストごとに保護する必要があります。データをデータベースに挿入しますか? データをクエリに入れる前にエスケープします (または準備済みステートメントを使用します)。ユーザーのブラウザに出力しますか?htmlspecialchars でエスケープ! メールアドレスでいいのでしょうか?電子メール メッセージに挿入する前に、実際にあることを確認してください。
データをデータベースに保存したとしても、一部のコンテキストではデータが安全ではない可能性があることに注意してください。たとえば、適切に SQL エスケープされた $_POST データには、まだ HTML タグやその他の XSS データが含まれている可能性があるため、ブラウザーに送信する前にエスケープする必要があります (ここで言いたいのは、user-provided
ラベルはそうではないということです)。データベースまたはファイルにデータを保存するという理由だけで消えます)。これを防ぐ良い方法は、使用されるエスケープ方法がこのコンテキストに対して正しいものであることを確認するために、各コンテキストのエスケープをできるだけ遅く行うことです(たとえば、エコーの直前に htmlspecialchars を実行します) 。可能な限り (たとえば、電子メール アドレスを検証し、無効な場合はエラーをスローするなど、無効なデータを受け入れないでください)。
これらの攻撃のほとんどをキャッチする Apache 用のModSecurity拡張機能もありますが、インジェクションを作成する方法はほぼ無限にあるため、絶対確実というわけではありません。したがって、ModSecurity は、アプリケーション コードを既に保護しているが、将来バグのために何かを見逃す可能性があることを恐れている場合にのみ使用する必要があります (これは、何らかの形で私たちのほとんどに発生する可能性があります)。
コード内の $_GET 変数をクリーンアップしてみませんか?
次の htaccess メソッドがあなたのケースで役立つかどうかを確認してください http://wp-mix.com/block-xss-htaccess/