[ https://issues.apache.org/jira/browse/ACCUMULO-3460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14556742#comment-14556742 ]
Sean Busbey commented on ACCUMULO-3460: --------------------------------------- Let me know when you think it's fixed and I'll see if I can update where my nightly scans check. > 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 > > 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)