私が書いている Web アプリケーションでは、ログインしている訪問者に、アップロードした写真の URL をサイトへのリンクとして入力する機会を与えています。
入力された文字列が URL であることを確認するために検証するつもりでしたが、ソリューションの複雑さを熟考した結果、おそらくそれは必要ないのではないかと考えました。
ただし、そうしないと見逃す可能性のあるセキュリティへの影響はありますか? (有効な URL に悪意のあるスクリプトなどが含まれている可能性がある状況を考えています。)
私が書いている Web アプリケーションでは、ログインしている訪問者に、アップロードした写真の URL をサイトへのリンクとして入力する機会を与えています。
入力された文字列が URL であることを確認するために検証するつもりでしたが、ソリューションの複雑さを熟考した結果、おそらくそれは必要ないのではないかと考えました。
ただし、そうしないと見逃す可能性のあるセキュリティへの影響はありますか? (有効な URL に悪意のあるスクリプトなどが含まれている可能性がある状況を考えています。)
URL のセキュリティの問題は、その有効性とはあまり関係がありません (ただし、間違いを見つけるために基本的なチェックを行うのは良いことですが、当然、一般的なデータに使用するのと同じ入力検証と出力エスケープ コードを使用する必要があります)。危険な URL スキームに関係しています。
最も顕著なのは、 javascript:
URL は実際には場所ではなく、それらをリンクするページに挿入するスクリプト コンテンツであり、クロスサイト スクリプティングの脆弱性をもたらします。同様の問題を持つ他のスキームがあります。http://
文字列がまたはで始まることを確認するなど、既知の適切なスキームのみを許可することをお勧めしますhttps://
。
この機能は、アップローダが CSRF 攻撃をトリガーする Web ページにリンクするクロスサイト リクエスト フォージェリ (CSRF) 攻撃の完璧な例のようです。
CSRF 攻撃のリスクを軽減するには、攻撃サイトがサイト効果のあるアクションを予測できないようにします。これは通常、サイトとログインした訪問者だけが知っているランダムな値である、いわゆるトークンによって行われます。
URL を正しく検証することは簡単ではありません。近づくことはできますが、RFC で許可されているすべてを網羅しているわけではありません。URL を入力として評価していない限り、html_escape() またはフレームワークの同等のものを実行することは、サイトをカジュアルな文字列のいたずらから保護するための十分な予防策です。
フレームワークを調査して、クロスサイト スクリプティング、SQL インジェクション、およびその他の関連する問題に対してどのような予防措置を講じる必要があるかを理解する必要がある場合があります。うまくいかないことのほとんどは、サニタイズされていない入力に関連していますが、マイレージはかなり異なる場合があります.
100% の安全性を期待する場合、ユーザーを保護することはおそらく妥当な設計目標ではありません。結局のところ、Web は保護されたサンドボックスではありません。