Hi
2013/2/28 Edward Burns <edward.burns_at_oracle.com>:
>>>>>> On Sun, 10 Feb 2013 14:48:27 -0500, Leonardo Uribe <lu4242_at_gmail.com> said:
>
> [...]
>
> LU> So, it is valid to check Referer header if present (just the usual: server,
> LU> port, context path, that the view exists ...), but the Token must be check
> LU> always for non postback requests (remember postback contains
> LU> javax.faces.ViewState token). Inclusive, we could check for the Origin
> LU> Header if present just for consistency suggested in the owasp.org
> LU> wiki.
>
> Leonardo, are you suggesting that we drop the "Otherwise, try to
> determine if the value of the Referer header corresponds to any of the
> views in the current web application." text?
>
The suggestion is always check the CSRF token on the url or in the
referrer header, and also keep the consistency check for the referer
header. What's missing is the check of the token in that part.
In other words, in theory the referer header is a weaker form of
CSRF protection. But the whole point of this feature is provide URL
protection for views in GET case, so the expected behavior is check the
token in the url or if is not present on the referer header.
It is well known that "... the ideal solution is to only include the CSRF
token in POST requests and modify server-side actions that have state
changing affect to only respond to POST requests. ..." but in JSF case,
javax.faces.ViewState hidden field already do that. Anyway, in some
cases the URL protection has its usefulness.
The consistency check for referer header (server, port, view existence, ...
whatever you can do to check the header is correct) is also wanted
and is critical to avoid some attacks.
> Also, can you please tell us exactly what you want to have done with the
> Origin header?
>
The wiki says this:
"... Checking The Origin Header
The Origin HTTP Header was introduced as a method of defending
against CSRF and other Cross-Domain attacks. Unlike the referer,
the origin will be present in HTTP request that originates from
an HTTPS url.
If the origin header is present, then it should be checked for consistency. ..."
Basically is if the origin header is present do the same checks of
consistency for referer header.
> Note that the original requirements for the issue did not include
> Referer spoofing protection, though I'd like to see how we can include
> that as well.
>
As you can see, the changes proposed are minimal, and are just
based on the recommendations of the owasp for CSRF. It is just
a minor correction.
regards,
Leonardo Uribe
> Ed
>
> --