13

I am confused. I see that JSF 2.0 has implicit CSRF protection: How JSF 2.0 prevents CSRF

On the other side according to the article http://www.oracle.com/webfolder/technetwork/tutorials/obe/java/JSF-CSRF-Demo/JSF2.2CsrfDemo.html we should add the following element to the faces-config.xml file with the list of JSF pages.

<protected-views>
   <url-pattern>/csrf_protected_page.xhtml</url-pattern>
</protected-views>

Should <protected-views> be used for JSF 2.2 CSRF protection?

Community
  • 1
  • 1
Michael
  • 10,063
  • 18
  • 65
  • 104

1 Answers1

18

I am confused. I see that JSF 2.0 has implicit CSRF protection: How JSF 2.0 prevents CSRF

This implicit protection is on POST requests only (i.e. pages with <h:form>).

On the other side according to the article http://www.oracle.com/webfolder/technetwork/tutorials/obe/java/JSF-CSRF-Demo/JSF2.2CsrfDemo.html we should add the following element to the faces-config.xml file with the list of JSF pages.

<protected-views>
   <url-pattern>/csrf_protected_page.xhtml</url-pattern>
</protected-views>

This protection will also be effective on GET requests (i.e. pages with <f:viewAction>, which is also new since JSF 2.2). Whenever you use <h:link> or <h:button> to create GET links/buttons to those pages, then a new GET request parameter javax.faces.Token with an autogenerated token value will be appended to the URL in the generated HTML output and this parameter would be required when the page in question is declared in <protected-views>.

This token will in turn be saved in the HTTP session. So, when the same URL is reopened in a different session, e.g. via a bookmark or being shared to another user, then a ProtectedViewException will be thrown which should basically show a message like "Please go back to the page where you found the link and click that link once more", effectively making it unbookmarkable.

If you want to make them bookmarkable, then you shouldn't be using protected views in first place. Or if you actually want to keep them unbookmarkable but you actually didn't intend to allow the enduser to bookmark/share the URL, then you shouldn't be using GET link/button to this page but instead an ajax POST link/button which opens the desired content in some sort of overlay on the current page, like a modal.

Should <protected-views> be used for JSF 2.2 CSRF protection?

Only on pages with <f:viewAction> which you'd like to CSRF-protect. Those with <h:form> are already implicitly protected by javax.faces.ViewState hidden input field, provided that you didn't turn off JSF view state by <f:view transient="true">. See also a.o. CSRF, XSS and SQL Injection attack prevention in JSF.

BalusC
  • 1,082,665
  • 372
  • 3,610
  • 3,555
  • 2
    When/why are pages with `` required to be protected (on GET requests) against CSRF? – Tiny Nov 20 '14 at 14:16
  • 3
    @Tiny: I'm also wondering that. GET requests are per definition idempotent. See also a.o. https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet#Disclosure_of_Token_in_URL – BalusC Nov 20 '14 at 15:11
  • It is an old theme, but i'm confused too. :) So I think if I protect get-s (non state modifying request) it is not CSRF just CORS. Can be important cannot get information from site, but if all page is protected, than I can't send bookmark link to user, because I can't send valid token for it. What is the solution? Protected view or not... Perhaps can be better send a token on request header like js framewrork's bearer token! Not? – László Tóth Jul 11 '23 at 14:56
  • 1
    If you want to make them bookmarkable, then you shouldn't be using protected views in first place. Or if you actually want to make them unbookmarkable, then you shouldn't be using GET links/buttons for this but instead an ajax POST link/button which opens the desired content in some sort of overlay on the current page, like a modal. – BalusC Jul 11 '23 at 15:48
  • What is the benefit using protected views (above ViewState)? Protect just get's, so malicous website cannot get sensitive data? Or has other benefit for example: by ajax post. – László Tóth Jul 11 '23 at 18:45
  • 1
    It has no benefit in properly designed apps. I've myself also never used this feature. – BalusC Jul 11 '23 at 18:48