[
https://issues.apache.org/jira/browse/HADOOP-12758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15132349#comment-15132349
]
Larry McCay commented on HADOOP-12758:
--------------------------------------
Hi [~anu] - I appreciate your concerns and believe that the third option that I
mentioned may provide a solution for the inconsistency. At the same time
provide sane defaults that will allow *all* clients that are not vulnerable to
the attack and should not be subject to the requirements imposed on browsers to
continue to work.
If we reverse the list of non-browsers into a list of browser matching regex
expressions then all non-browsers will continue to work.
The challenge will be to identify the proper set of regex expressions to
protect the vast majority of browsers.
I don't see the requirement that browsers/AJAX provide additional HTTP headers
as a change to the REST protocol. This is an access requirement between the
browser client and the server and does not involve the semantics of the REST
API itself. It is really an application level concern. Similar to
authentication mechanisms differing between a web app and a curl invocation.
So, let's walk through the option 3 description:
1. default set of browser matching regex expressions in place
2. all non-browsers continue to work without requiring a header to protect them
from an attack that they are not vulnerable to
3. AJAX calls are changed to send the header based on configured header names
or default
4. user-agents that match a regex pattern have their header validated as being
present and therefore from a valid AJAX client
5. user-agents that do not match a regex pattern do not have their header
validated and therefore are vulnerable to CSRF
#5 above is the concerning bit that is introduced by this option 3.
We might be able to discern some additional client context from the Referrer
header which also cannot be altered by AJAX calls.
This will require some investigation into what Referrer is (if anything at all)
for non-browsers.
The idea being something like...
1. If #5 and there is no referrer then we don't validate the header or
2. if #5 and the referrer matches some additional config for allowed referrers
then validate the existence of a the header (this would indicate the use of an
unusual browser and should be added to regex patterns)
That level could be a follow up JIRA since given a sane set of browser regex
patterns as defaults this should be an edge case.
Thoughts?
> Extend CSRF Filter with UserAgent Checks
> ----------------------------------------
>
> Key: HADOOP-12758
> URL: https://issues.apache.org/jira/browse/HADOOP-12758
> Project: Hadoop Common
> Issue Type: Bug
> Components: security
> Reporter: Larry McCay
> Assignee: Larry McCay
> Attachments: HADOOP-12758-001.patch, HADOOP-12758-002.patch
>
>
> To protect against CSRF attacks, HADOOP-12691 introduces a CSRF filter that
> will require a specific HTTP header to be sent with every REST API call. This
> will affect all API consumers from web apps to CLIs and curl.
> Since CSRF is primarily a browser based attack we can try and minimize the
> impact on non-browser clients.
> This enhancement will provide additional configuration for identifying
> non-browser useragents and skipping the enforcement of the header requirement
> for anything identified as a non-browser. This will largely limit the impact
> to browser based PUT and POST calls when configured appropriately.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
