[jira] [Comment Edited] (SOLR-14886) Suppress stack trace in Query response.
[
https://issues.apache.org/jira/browse/SOLR-14886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17270442#comment-17270442
]
Isabelle Giguere edited comment on SOLR-14886 at 1/26/21, 9:04 PM:
---
We could easily add a parameter in solr.xml to hide (or not) stack traces:
But doing something with that parameter will not be easy.
I thought of a solution that would use that new parameter to modify the
response just before sending it out, so the actual log file would not be
affected. Either adapt implementations of QueryResponseWriter, or method
SolrCore.postDecorateResponse.
However, the "trace" element of the response seems to be set all over the code,
instead of handling the Exception properly, or throwing it so it could be
handled in a more generic way elsewhere. These locations in code (at least 12
that I can see in branch_8x, not counting unit tests) don't all have access to
the config from solr.xml
For example, trying to sort results using a multi-valued field (a date field)
yields this error. The "error" and "trace" elements are set in
QueryComponent.mergeIds.
{code}
class java.lang.String cannot be cast to class org.apache.lucene.util.BytesRef
(java.lang.String is in module java.base of loader 'bootstrap';
org.apache.lucene.util.BytesRef is in unnamed module of loader
org.eclipse.jetty.webapp.WebAppClassLoader @c00fff0)
java.lang.ClassCastException: class java.lang.String cannot be cast to class
org.apache.lucene.util.BytesRef (java.lang.String is in module java.base of
loader 'bootstrap'; org.apache.lucene.util.BytesRef is in unnamed module of
loader org.eclipse.jetty.webapp.WebAppClassLoader @c00fff0) at
org.apache.lucene.search.FieldComparator$TermOrdValComparator.compareValues(FieldComparator.java:561)
at
org.apache.solr.handler.component.ShardFieldSortedHitQueue$1.compare(ShardFieldSortedHitQueue.java:161)
at
org.apache.solr.handler.component.ShardFieldSortedHitQueue$1.compare(ShardFieldSortedHitQueue.java:153)
at
org.apache.solr.handler.component.ShardFieldSortedHitQueue.lessThan(ShardFieldSortedHitQueue.java:92)
at
org.apache.solr.handler.component.ShardFieldSortedHitQueue.lessThan(ShardFieldSortedHitQueue.java:33)
at org.apache.lucene.util.PriorityQueue.upHeap(PriorityQueue.java:254) at
org.apache.lucene.util.PriorityQueue.add(PriorityQueue.java:131) at
org.apache.lucene.util.PriorityQueue.insertWithOverflow(PriorityQueue.java:147)
at
org.apache.solr.handler.component.QueryComponent.mergeIds(QueryComponent.java:958)
at
org.apache.solr.handler.component.QueryComponent.handleRegularResponses(QueryComponent.java:614)
at
org.apache.solr.handler.component.QueryComponent.handleResponses(QueryComponent.java:593)
at
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:454)
at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:211)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:2596) at
org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:802) at
org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:579) at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:420)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:352)
at org.eclipse.jetty.servlet.FilterHolder.doFilter(FilterHolder.java:201) at
org.eclipse.jetty.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1601)
at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:548)
at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:602)
at
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
at
org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:235)
at
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1624)
at
org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233)
at
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1435)
at
org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188)
at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:501)
at
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1594)
at
org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186)
at
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1350)
at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
at
org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:191)
at
org.eclipse.jetty.server.handler.InetAccessHandler.handle(InetAccessHandler.java:177)
at
[jira] [Comment Edited] (SOLR-14886) Suppress stack trace in Query response.
[
https://issues.apache.org/jira/browse/SOLR-14886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17249854#comment-17249854
]
Isabelle Giguere edited comment on SOLR-14886 at 12/15/20, 6:45 PM:
[~gerlowskija]
The full stack trace in the error response can be a vulnerability.
As explained by our application security assessment team:
{quote}
Detailed technical error messages can allow an attacker to gain information
about the application and database that could be used to conduct an attack.
This information could include the names of database tables and columns, the
structure of database queries, method names, configuration details, etc.
{quote}
So, OK, no database here. But the basic idea is that the stack trace contains
too much information for a response to the outside world. Stack traces are for
logs, for developers.
It falls into item #6 in the OWASP top 10
https://owasp.org/www-project-top-ten/
"verbose error messages containing sensitive information"
So, either each and every error message needs to be cleaned-up individually,
which is error-prone, or, we don't display any details to the outside world.
Because the stack trace lists all classes and methods, a hacker can determine
which vulnerable library is included on the classpath. So in this sense, even
information about the classpath is sensitive information.
was (Author: igiguere):
[~gerlowskija]
The full stack trace in the error response can be a vulnerability.
As explained by our application security assessment team:
{quote}
Detailed technical error messages can allow an attacker to gain information
about the application and database that could be used to conduct an attack.
This information could include the names of database tables and columns, the
structure of database queries, method names, configuration details, etc.
{quote}
So, OK, no database here. But the basic idea is that the stack trace contains
too much information for a response to the outside world. Stack traces are for
logs, for developers.
It falls into item #6 in the OWASP top 10
https://owasp.org/www-project-top-ten/
"verbose error messages containing sensitive information"
So, either each an every error message needs to be cleaned-up individually,
which is error-prone, or, we don't display any details to the outside world.
Because the stack trace lists all classes and methods, a hacker can determine
which vulnerable library is included on the classpath. So in this sense, even
information about the classpath is sensitive information.
> Suppress stack trace in Query response.
> ---
>
> Key: SOLR-14886
> URL: https://issues.apache.org/jira/browse/SOLR-14886
> Project: Solr
> Issue Type: Improvement
>Affects Versions: 8.6.2
>Reporter: Vrinda Davda
>Priority: Minor
>
> Currently there is no way to suppress the stack trace in solr response when
> it throws an exception, like when a client sends a badly formed query string,
> or exception with status 500 It sends full stack trace in the response.
> I would propose a configuration for error messages so that the stack trace is
> not visible to avoid any sensitive information in the stack trace.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-14886) Suppress stack trace in Query response.
[
https://issues.apache.org/jira/browse/SOLR-14886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17249854#comment-17249854
]
Isabelle Giguere edited comment on SOLR-14886 at 12/15/20, 6:44 PM:
[~gerlowskija]
The full stack trace in the error response can be a vulnerability.
As explained by our application security assessment team:
{quote}
Detailed technical error messages can allow an attacker to gain information
about the application and database that could be used to conduct an attack.
This information could include the names of database tables and columns, the
structure of database queries, method names, configuration details, etc.
{quote}
So, OK, no database here. But the basic idea is that the stack trace contains
too much information for a response to the outside world. Stack traces are for
logs, for developers.
It falls into item #6 in the OWASP top 10
https://owasp.org/www-project-top-ten/
"verbose error messages containing sensitive information"
So, either each an every error message needs to be cleaned-up individually,
which is error-prone, or, we don't display any details to the outside world.
Because the stack trace lists all classes and methods, a hacker can determine
which vulnerable library is included on the classpath. So in this sense, even
information about the classpath is sensitive information.
was (Author: igiguere):
[~gerlowskija]
The full stack trace in the error response can be a vulnerability.
As explained by our application security assessment team:
{quote}
Detailed technical error messages can allow an attacker to gain information
about the application and database that could be used to conduct an attack.
This information could include the names of database tables and columns, the
structure of database queries, method names, configuration details, etc.
{quote}
So, OK, no database here. But the basic idea is that the stack trace contains
too much information for a response.
> Suppress stack trace in Query response.
> ---
>
> Key: SOLR-14886
> URL: https://issues.apache.org/jira/browse/SOLR-14886
> Project: Solr
> Issue Type: Improvement
>Affects Versions: 8.6.2
>Reporter: Vrinda Davda
>Priority: Minor
>
> Currently there is no way to suppress the stack trace in solr response when
> it throws an exception, like when a client sends a badly formed query string,
> or exception with status 500 It sends full stack trace in the response.
> I would propose a configuration for error messages so that the stack trace is
> not visible to avoid any sensitive information in the stack trace.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
