[jira] [Comment Edited] (HBASE-20004) Client is not able to execute REST queries through browser in a secure cluster

["Sean Busbey (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/HBASE-20004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16370126#comment-16370126 ] 

Sean Busbey edited comment on HBASE-20004 at 2/20/18 3:07 PM:
--------------------------------------------------------------

{quote}Are we committing to supporting browser based query of the REST API? That seems like something clearly out of scope for us.{quote}

I don't think we should commit to having the browser work with the REST API, but from what I can tell researching this:

1) OPTIONS is commonly used in REST APIs for discovery. A REST service expressly called out as when it's appropriate for a webserver to respond to the HTTP OPTIONS method.

2) The specific vulnerability class that drove HBASE-10473 doesn't actually involved the OPTIONS method. It's all just in the TRACE method, the OPTIONS method is simply listed in the OWASP guide as one quick way to see if a webserver will respond to TRACE [ref|https://www.owasp.org/index.php/Test_HTTP_Methods_(OTG-CONFIG-006)].

3) OPTIONS *is* listed in the category of attack surface reduction. specifically, it's one that shows up as "usually you don't need this so you ought to disable it by default" (but see #1 above, REST is called out as when clients should expect OPTIONS to work).

4) several automated scanners I looked at seem to combine a mis-read of #2 and a correct read of #3 to always flag when OPTIONS is enabled.

From all of this I draw a few conclusions. First, I think we should allow OPTIONS on the REST server specifically by default and we should disallow it by default in our general HTTP interfaces. Second, since some folks doing network scans will still ping on the REST server, we should provide a config knob to turn off allowing OPTIONS with a warning that REST clients expect it and some may malfunction without it. That way operators get an out of the box config that should work with clients, a ready-made justification to filter out the security scan result if/when it shows up, and a way to conform to the scan result at the expense of client compatibility if that's what their policy requires.


was (Author: busbey):
> Are we committing to supporting browser based query of the REST API? That seems like something clearly out of scope for us.

I don't think we should commit to having the browser work with the REST API, but from what I can tell researching this:

1) OPTIONS is commonly used in REST APIs for discovery. A REST service expressly called out as when it's appropriate for a webserver to respond to the HTTP OPTIONS method.

2) The specific vulnerability class that drove HBASE-10473 doesn't actually involved the OPTIONS method. It's all just in the TRACE method, the OPTIONS method is simply listed in the OWASP guide as one quick way to see if a webserver will respond to TRACE [ref|https://www.owasp.org/index.php/Test_HTTP_Methods_(OTG-CONFIG-006)].

3) OPTIONS *is* listed in the category of attack surface reduction. specifically, it's one that shows up as "usually you don't need this so you ought to disable it by default" (but see #1 above, REST is called out as when clients should expect OPTIONS to work).

4) several automated scanners I looked at seem to combine a mis-read of #2 and a correct read of #3 to always flag when OPTIONS is enabled.

From all of this I draw a few conclusions. First, I think we should allow OPTIONS on the REST server specifically by default and we should disallow it by default in our general HTTP interfaces. Second, since some folks doing network scans will still ping on the REST server, we should provide a config knob to turn off allowing OPTIONS with a warning that REST clients expect it and some may malfunction without it. That way operators get an out of the box config that should work with clients, a ready-made justification to filter out the security scan result if/when it shows up, and a way to conform to the scan result at the expense of client compatibility if that's what their policy requires.

> Client is not able to execute REST queries through browser in a secure cluster
> ------------------------------------------------------------------------------
>
>                 Key: HBASE-20004
>                 URL: https://issues.apache.org/jira/browse/HBASE-20004
>             Project: HBase
>          Issue Type: Bug
>          Components: REST
>    Affects Versions: 1.3.1
>            Reporter: Ashish Singhi
>            Assignee: Ashish Singhi
>            Priority: Minor
>         Attachments: HBASE-20004.branch-1.patch, HBASE-20004.patch
>
>
> Firefox browser is not able to negotiate REST queries with server in secure mode.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)