possible security issue

Splash Forums PrettyFaces Users possible security issue

This topic contains 5 replies, has 3 voices, and was last updated by  0swald 6 years, 9 months ago.

Viewing 6 posts - 1 through 6 (of 6 total)
  • Author
    Posts
  • #17846

    0swald
    Participant

    Hi all!

    JSR-315 Servlet 3 specification (security chapter, 13.8) uses URL patterns for security mapping, e.g. /personal/* can be mapped to specific security role(s), requiring user to authenticate before accessing the resource. Now I have pretty-mapped /admin/balance/ to /faces/pages/admin/balance.xhtml. In that case http://localhost:8080/faces/pages/admin/balance.xhtml, would allow web user to avoid security checks.

    How to reproduce:

    1. simplest web app, with security constraints in web.xml:

    <security-constraint>
    <display-name>Access Manager Security Constraint</display-name>
    <web-resource-collection>
    <web-resource-name>AUTHENTICATED_RESOURCE</web-resource-name>
    <url-pattern>/admin/*</url-pattern>
    </web-resource-collection>
    <auth-constraint>
    <role-name>SECURE</role-name>
    </auth-constraint>
    <user-data-constraint>
    <transport-guarantee>CONFIDENTIAL</transport-guarantee>
    </user-data-constraint>
    </security-constraint>

    2. One bean (no pretty-config.xml):

    @ManagedBean
    @RequestScoped
    @URLMapping(id="balance",
    pattern="/admin/balance/",
    viewId="/faces/pages/admin/balance.xhtml")
    public class BalanceBean {
    ......
    }

    3. Browser:

    3.1. http://localhost:8080/admin/balance/ – security prompt

    3.2. http://localhost:8080/faces/pages/admin/balance.xhtml – full access

    This post is to inform, not panic :) My current workaround is to duplicate both views and pretty-mappings in security constraints. Hope someone will suggest more elegant way to handle this issue or point out what I’ve missed or misconfigured.

    #20575

    Hey 0swald,

    Thanks for mentioning this. It’s definitely a concern, though I might go as far as to say that it’s orthogonal to PrettyFaces in the respect that security should be handled at a resource level.

    PrettyFaces exposes an additional resource URL, but cannot “block” the underlying resource by default because that might break existing references; this is what a security package should be used for (as you mentioned as well.)

    I think your solution is correct (there are many ways to do this,) but I personally use Seam-Security, and block all .xhtml files according to certain patterns.

    You could even use an inbound rewrite rule to forward all non-mapped requests to a specific “access denied page”

    <rewrite match="*.xhtml" substitute="/access-denied" redirect="chain" outbound="false"/>

    or something like that…

    It’s probably worth mentioning in the FAQ / Documentation.

    –Lincoln

    #20576

    domdorn
    Participant

    3 Solutions:

    1)

    The easiest solution would be to either move the views (the .xhtml files) directly to the folder protected, e.g. I have a lot of rules like these

    <url-mapping id=”upload_exam”>

    <pattern>/upload/exam/#{ courseId }</pattern>

    <view-id>/upload/exam.xhtml</view-id>

    </url-mapping>

    or

    2)

    to simply move your real .xhtml files and the “faces/pages” folder under the WEB-INF directory, so your mappings would look like

    <url-mapping id=”upload_exam”>

    <pattern>/upload/exam/#{ courseId }</pattern>

    <view-id>/WEB-INF/faces/pages/upload/exam.xhtml</view-id>

    </url-mapping>

    or

    3)

    <security-constraint>

    <display-name>Access Manager Security Constraint</display-name>

    <web-resource-collection>

    <web-resource-name>AUTHENTICATED_RESOURCE</web-resource-name>

    <url-pattern>/faces/*</url-pattern>

    </web-resource-collection>

    <auth-constraint>

    <role-name>SECURE</role-name>

    </auth-constraint>

    <user-data-constraint>

    <transport-guarantee>CONFIDENTIAL</transport-guarantee>

    </user-data-constraint>

    </security-constraint>

    this should help :)

    http://twitter.com/domdorn ;)

    #20577

    0swald
    Participant

    Lincoln, domdorn.

    Thanks for posting your replies and solutions. Haven’t checked them yet, but it looks like they should really work. And it’s definitely worth small chapter in Docs, describing potential issues and workarounds. It’ll really help pretty newcomers to plan and develop their pretty web apps, having big picture in the very beginning and avoiding future redesign. Like in my case :)

    I will post here my final solution for JSR-315 based security, most probably based on the one proposed by domdorn.

    Regards,

    Osw.

    #20578
    #20579

    0swald
    Participant

    Not so easy as it seemed to me :(

    Regarding domdorn’s solution #2:

    Neither /faces/WEB-INF/* nor /WEB-INF/faces/* mappings do not work. The only possible way to hide original pages under /WEB-INF/ folder is to use extension mapping for Faces Servlet: *.xhtml. In that case one will really have only one (pretty) URL exposed along with known drawbacks:

    All JSF resources (css, js, png, jpg, etc) will be rewritten to *.css.xhtml, *.jpg.xhtml etc. I use Apache front-end with mod_jk and mod_cache enabled and serious reconfiguration will be required to tune caching and correct mime-type mappings. This operation is time consuming and should be repeated every time I decide to change or add third-party JSF library (RichFaces, Primefaces, etc)

    I have to admit that hiding pages behind WEB-INF is not a solution for me, and both original views and pretty-mapped URLs will be exposed. This approach implies some restrictions regarding security: as I will need to duplicate views and mapped urls in web.xml security mappings, maintaining common patterns in both becomes necessary to simplify security maintenance:

    <web-resource-collection>
    <web-resource-name>AUTHENTICATED_RESOURCE</web-resource-name>
    <!-- Pretty mapped URL -->
    <url-pattern>/admin/*</url-pattern>
    <!-- Faces resource path -->
    <url-pattern>/faces/admin/*</url-pattern>
    </web-resource-collection>

    http://code.google.com/p/prettyfaces/issues/detail?id=81#c2

Viewing 6 posts - 1 through 6 (of 6 total)

You must be logged in to reply to this topic.

Comments are closed.