[
https://issues.apache.org/jira/browse/ACCUMULO-3460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14559871#comment-14559871
]
Christopher Tubbs commented on ACCUMULO-3460:
---------------------------------------------
The solution I applied was to enforce a security constraint which required one
to be authenticated with an unspecified (thus, impossible to satisfy) set of
roles, before TRACE could be permitted. As a result, the error message is a 403
Forbidden (if the roles had been specified, it would have returned a 401
Unauthorized... something we may want to consider in the future if we make it
so that authenticated users are permitted to do TRACE).
An alternative solution would have been to implement doTrace in all of our
servlets, which responded with a 405 Method Not Allowed error, like the
DefaultServlet does (which we could get by extending DefaultServlet). However,
I felt that a solution with a server-level constraint would be more robust to
changes in the future (like somebody forgetting to extend a base Servlet or
changes to the underlying behavior of DefaultServlet). I also wasn't sure if
there'd be any other side-effects of extending DefaultServlet, which we
wouldn't want.
> Monitor should not allow HTTP TRACE
> -----------------------------------
>
> Key: ACCUMULO-3460
> URL: https://issues.apache.org/jira/browse/ACCUMULO-3460
> Project: Accumulo
> Issue Type: Bug
> Components: monitor
> Affects Versions: 1.5.0, 1.5.1, 1.5.2, 1.6.0
> Reporter: Sean Busbey
> Assignee: Christopher Tubbs
> Priority: Minor
> Labels: security
> Fix For: 1.6.3, 1.8.0, 1.7.1
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> A Nessus scan pinged my test cluster because the Accumulo monitor allows HTTP
> TRACE requests. (ref: [an overview of the general problem
> class|http://www.cgisecurity.com/whitehat-mirror/WH-WhitePaper_XST_ebook.pdf])
> The issue isn't bad unless
> * there's a same-origin-policy bypass for the user browser
> * there's an auth token we care about
> Exploits the bypass the same-origin-policy happen, so it's best to clean up
> server side if possible.
> The only auth tokens present in the Monitor are when we make use of the
> ShellServlet from ACCUMULO-196. We rely on the session state for auth, so
> there isn't a risk of leaking auth info directly, but we would leak the
> session id.
> The CSRF added in ACCUMULO-2785 means just the session id wouldn't be enough
> for impersonation, but if an attacker can read one requested page we have to
> presume they can read another.
> We should clean up our configs to disallow HTTP TRACE as a proactive measure.
> Marking minor since an attack vector would need an enabling vulnerability on
> the client side.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
