jsf url 映射安全风险

发布于 2024-11-15 11:12:23 字数 958 浏览 1 评论 0原文

当您使用 JSF 时，您将拥有控制器 servlet javax.faces.webapp.FacesServlet，它将映射到以下内容：

<servlet-mapping>
   ...
    <url-pattern>/somefacesurl/*</url-pattern>
</servlet-mapping>

将 mypage.xhtml 放入 / 中，我们存在安全风险，因为它将通过两种方式访问（从从应用程序上下文）： 1) /somefacesurl/mypage.xhtml 2) /mypages.xhtml

第一个是jsf处理的，是正确的。 第二个不由 jsf 处理，因此呈现给客户端，暴露 jsf 标签，这是一个安全风险。

我只找到了两个解决方案
1) 始终映射到根 url：

<servlet-mapping>
   ...
    <url-pattern>*.xhtml</url-pattern>
</servlet-mapping>

很好的解决方案，但只允许按文件扩展名进行映射。

2) 映射到任何 url，并使用安全约束来禁止访问这些文件，如下所示：如何避免用户访问 JSF 中的 .xhtml 页面？

这两种解决方案都作为可行的替代方案出现在 JSF 2.0 规范中，但没有提及这两种解决方案的不同安全方法。

由于不考虑安全性，我想知道从访问 xhtml 文件的角度来看，第一个是否“安全”，或者可能存在获取 .xhtml 源的黑客攻击。

原文

When you use JSF, you'll have the controller servlet javax.faces.webapp.FacesServlet that will be mapped to the following:

<servlet-mapping>
   ...
    <url-pattern>/somefacesurl/*</url-pattern>
</servlet-mapping>

Putting a mypage.xhtml in /, we have a security risk because it will be accessed in two ways (starting from the application context):
1) /somefacesurl/mypage.xhtml
2) /mypages.xhtml

The first is processed by jsf, and is correct.
The second is not processed by jsf and so is presented to the client exposing jsf tags and this is a security risk.

I've found only two solutions
1) mapping always to the root url:

<servlet-mapping>
   ...
    <url-pattern>*.xhtml</url-pattern>
</servlet-mapping>

Good solution but permits only mappings by file extension.

2) Map to whatever url, and use security constraint to disallow access to those files as suggested in:
How to avoid user access to .xhtml page in JSF?

Both solutions are presented in the JSF 2.0 spec as viable alternatives, BUT there is no word about the different security approach of the two solutions.

Since security is NOT considered, i wonder if the first is "secure" from the point of view of access to the xhtml files or perhaps there is an hack to get the .xhtml sources.

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

溺渁∝ 2024-11-22 11:12:23

JSF 规范强制要求第一个映射是不正确的。它仅提供了 JSF 2.0 规范的第 11.1.2 章（您应该阅读）和 JSF 1.2 规范的第 10.1.2 章中的两个映射的示例。以下是 JSF 2.0 规范一的相关摘录（重点是我的）：

11.1.2 Servlet 映射
对 Web 应用程序的所有请求都会根据匹配的 URL 模式（如定义在
Java Servlet 规范）针对选择此 Web 的上下文路径之后的请求 URL 部分
应用。 JSF 实现必须支持定义的 Web 应用程序
将任何有效的 url-pattern 映射到 FacesServlet。 可以使用前缀或扩展名映射。何时
使用前缀映射，建议使用以下映射，但不是必需的：
;
     faces-servlet-name 
    /faces/*
使用扩展映射时，建议使用以下映射，但不是必需的：
;
     faces-servlet-name 
    *.faces
除了 FacesServlet 之外，JSF 实现还可以支持其他方式来调用 JavaServer Faces 请求
处理生命周期，但依赖这些机制的应用程序将不可移植。

我真的不明白为什么扩展（后缀）映射是“棘手的”。更重要的是，这是我最喜欢的 JSF 映射。我建议使用 *.xhtml 作为 JSF 映射。这还为您提供了一个优势，即您无需摆弄安全约束来阻止直接访问源文件。

更新：请注意，只要视图是声明性的并且不包含存储数据库用户名/密码等变量的任何单行 Java 源代码，源泄漏本身就不是安全问题。裸露。由于 Facelets 不允许嵌入原始 Java 代码（如 JSP scriptlet），我不明白这怎么会造成安全漏洞。黑客可以用查看源代码做什么？编辑它，渲染它并以某种方式提交回来？（我真的很想知道如何）。这显然是不可能的，因为 JSF 默认情况下也依赖于服务器端的视图状态。

不过，我同意 JSF 规范应该向读者提供更多有关这一点的信息。我为此创建了 JSF 规范问题 1015。

It is not true that the JSF spec mandates the first mapping. It just gives examples of the both mappings in chapter 11.1.2 of the JSF 2.0 spec (which you should be reading) and chapter 10.1.2 of the JSF 1.2 spec. Here's an extract of relevance of the JSF 2.0 spec one (emphasis mine):

11.1.2 Servlet Mapping
All requests to a web application are mapped to a particular servlet based on matching a URL pattern (as defined in the
Java Servlet Specification) against the portion of the request URL after the context path that selected this web
application. JSF implementations must support web application that define a <servlet-mapping>
that maps any valid url-pattern to the FacesServlet. Prefix or extension mapping may be used. When
using prefix mapping, the following mapping is recommended, but not required:
<servlet-mapping>
    <servlet-name> faces-servlet-name </servlet-name>
    <url-pattern>/faces/*</url-pattern>
</servlet-mapping>
When using extension mapping the following mapping is recommended, but not required:
<servlet-mapping>
    <servlet-name> faces-servlet-name </servlet-name>
    <url-pattern>*.faces</url-pattern>
</servlet-mapping>
In addition to FacesServlet, JSF implementations may support other ways to invoke the JavaServer Faces request
processing lifecycle, but applications that rely on these mechanisms will not be portable.

I really don't see why an extension (suffix) mapping is "tricky". Even more, this is my favourite JSF mapping. I recommend using *.xhtml as JSF mapping. This gives you also the advantage that you don't need to fiddle with security constraints to prevent direct access to source files.

Update: Please note that the source leak is not a security issue per se as long as the view is declarative and does not contain any single line of Java source code wherein variables like database username/password are stored and exposed. Since Facelets disallows for embedded raw Java code (like JSP scriptlets) I don't see how that's a security leak. What can a hacker do with the view source? Edit it, render it and submit back somehow? (I'd really wonder how). That's plain impossible since JSF by default relies on the view state in the server side as well.

I however agree with the point that the JSF specification should inform the reader more about this. I've created JSF spec issue 1015 for this.

回复收藏 0 原文

~没有更多了~