XSS漏洞出现时<；c:url>；及<；c:param>；值被注入到JavaScript字符串文本中

我的静态分析器已标记以下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。我主要感兴趣的是确定攻击者是否可以使用

userSuppliedParameter

URL查询参数将可执行JavaScript注入此页面，以及攻击者是否可以使用任意URL参数将document.location评估为/somepage.jsp以外的任何内容。例如：

http://foo.com/bar.jsp?userSuppliedParam=SOME_POTENTIALLY_MALICIOUS_PAYLOAD

。我不关心将值注入目标页面，也不关心目标页面解释URL的方式

应该对URL参数进行URL编码，这将阻止某人添加“@”符号，否则将导致前面的字符被解释为基本身份验证参数。否则，这将暴露一个错误

还应编码双引号，这将防止有人终止JavaScript字符串文字

我基于的url编码和JavaDoc的假设

---

还有其他可能的滥用吗？

普遍认为这是误报。如果我发现一个潜在的漏洞，我会更新它。

想不出任何其他的openingsAutomated XSS Check（自动XSS检查）会做得过火，但是这些用户参数来自哪里，这些标记何时呈现？还有，脚本标记中的html注释是毫无意义的，除非您真的支持不知道如何处理脚本标记的浏览器。感谢@erik reppen——从安全角度看，用户参数来自何处并不重要，它们是URL中的查询参数，因此，有人在某个地方发布链接，比如在钓鱼电子邮件或其他网站的博客文章中，可能会对其进行篡改。也许不清楚这些是URL查询参数。这看起来肯定是一个错误的警告。尝试查看是否

document.location=“”

会降低静态分析器的音量@Erik:JSP中的

${param}

引用HTTP请求参数映射。