You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@hbase.apache.org by "Wellington Chevreuil (Jira)" <ji...@apache.org> on 2023/04/26 09:37:00 UTC

[jira] [Commented] (HBASE-27812) Provide option in HBase UI to disable stack trace for security

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

Wellington Chevreuil commented on HBASE-27812:
----------------------------------------------

{quote}Applications should always fail safe in their designs. If an application fails to an unknown state, it is likely that an attacker may be able to exploit this indeterminate state to access unauthorized functionality, or worse, create, modify or destroy data. Error messages may also aid in the identification of other attacks such as buffer overflows and SQL injection, and can generally contribute to an overall weaker security posture.
{quote}
HBase UI doesn't provide any functionality for altering data. There's no authorization feature either, so I believe none of the above is applicable. That said, it can be daunting to argue against infosec groups running templated security vulnerability reports in many organizations, so I guess we should still have some way of address this, I just don't see it as a major priority.

> Provide option in HBase UI to disable stack trace for security
> --------------------------------------------------------------
>
>                 Key: HBASE-27812
>                 URL: https://issues.apache.org/jira/browse/HBASE-27812
>             Project: HBase
>          Issue Type: Improvement
>          Components: UI
>            Reporter: Yash Dodeja
>            Assignee: Yash Dodeja
>            Priority: Minor
>
> Uncaught server exceptions occur when providing parameter values that the server or servlet does not understand.
> Physical paths, versioning information, stack traces' content, and other data can be gathered and used to help further an attack when improper error handling is present.
> Applications should always fail safe in their designs. If an application fails to an unknown state, it is likely that an attacker may be able to exploit this indeterminate state to access unauthorized functionality, or worse, create, modify or destroy data. Error messages may also aid in the identification of other attacks such as buffer overflows and SQL injection, and can generally contribute to an overall weaker security posture.
> For example, if we use a HTTPS web server and explicitly provide Host header with a wrong value, say attackers.com, we get the following response in UI:
> {code:java}
> <html>
> <head>
> <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1"/>
> <title>Error 400 Host does not match SNI</title>
> </head>
> <body><h2>HTTP ERROR 400 Host does not match SNI</h2>
> <table>
> <tr><th>URI:</th><td>/tablesDetailed.jsp</td></tr>
> <tr><th>STATUS:</th><td>400</td></tr>
> <tr><th>MESSAGE:</th><td>Host does not match SNI</td></tr>
> <tr><th>SERVLET:</th><td>-</td></tr>
> <tr><th>CAUSED BY:</th><td>org.apache.hbase.thirdparty.org.eclipse.jetty.http.BadMessageException: 400: Host does not match SNI</td></tr>
> </table>
> <h3>Caused by:</h3><pre>org.apache.hbase.thirdparty.org.eclipse.jetty.http.BadMessageException: 400: Host does not match SNI
>    at org.apache.hbase.thirdparty.org.eclipse.jetty.server.SecureRequestCustomizer.customize(SecureRequestCustomizer.java:279)
>    at org.apache.hbase.thirdparty.org.eclipse.jetty.server.SecureRequestCustomizer.customize(SecureRequestCustomizer.java:210)
>    at org.apache.hbase.thirdparty.org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:483)
>    at org.apache.hbase.thirdparty.org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:732)
>    at org.apache.hbase.thirdparty.org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:479)
>    at org.apache.hbase.thirdparty.org.eclipse.jetty.server.HttpChannel.run(HttpChannel.java:439)
>    at org.apache.hbase.thirdparty.org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:883)
>    at org.apache.hbase.thirdparty.org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:1034)
>    at java.lang.Thread.run(Thread.java:750)
> </pre>
> </body>
> </html> {code}
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)