2

私の静的アナライザーは、次の XSS エラーにフラグを立てました。このパラメーターに悪意のあるコードを挿入する、挿入された値を JavaScript として解釈させる (おそらく JavaScript 文字列リテラルを途中で終了させる)、または挿入された値を別の場所にリダイレクトすることが可能かどうかを理解したいと思います。サーバーによって拒否された値を持つ目的の宛先。 

<c:url var="myUrl" value="/somepage.jsp">
  <c:param name="myParam" value="${param.userSuppliedParameter}"/>
</c:url>

<script type="text/javascript">
  <!--
    document.location = "${myUrl}";
  //-->
</script>

url パラメータが単に変更され、追加の URL パラメータが無視される場合に、サーバーがリダイレクト URL を適切に処理することは注目に値します。私は主に、攻撃者が URL クエリ パラメータを使用して実行可能な JavaScript をこのページに挿入できるかどうuserSuppliedParameterか、および攻撃者が document.location を /somepage.jsp 以外のものとして評価できるかどうかを判断することに関心があります。 URL パラメータ。例: http://foo.com/bar.jsp?userSuppliedParam=SOME_POTENTIALLY_MALICIOUS_PAYLOAD. 宛先ページに値が挿入されることや、宛先ページが URL を解釈する方法については気にしません。

<c:url>URL パラメーターを URL エンコードする必要があります。これにより、誰かが「@」記号を追加できなくなります。そうしないと、先行する文字が基本認証パラメーターとして解釈されてしまいます。そうしないと、オープン リダイレクトの脆弱性が露呈する可能性があります。

<c:url>二重引用符もエンコードする必要があります。これにより、誰かが JavaScript 文字列リテラルを終了するのを防ぐことができます。

URLEncoderのRFCおよび JavaDocに関する URL エンコーディングに関する私の仮定に基づいています。

他に考えられる虐待はありますか？

4

1 に答える 1

0

コンセンサスは、これは偽陽性であるということです。潜在的な脆弱性が見つかった場合は、これを更新します。

于 2013-01-08T18:22:50.543 に答える