[jira] [Commented] (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=17277272#comment-17277272 ] Isabelle Giguere commented on SOLR-14886: - Patch off current Solr master branch (9.x) - Add a property "hideStackTrace" to solr.xml - In NodeConfig, the default value is "false", for back-compatibility. - Use the new property in ResponseUtils, to print out, or not, the stack trace. - Adapt code that calls ResponseUtils - Add documentation in Ref Guide There's no direct path between solr.xml and ResponseUtils, or any class that uses ResponseUtils, so the "hideStackTrace" property is duplicated in CoreContainer, just so it lives in a place where it can be read. May not be the best approach. Note that the patch cannot fix the cases where the error message ()contains the full stack trace. > 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 > Attachments: SOLR-14886.patch, SOLR-14886.patch > > > 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] [Commented] (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=17273951#comment-17273951
]
Isabelle Giguere commented on SOLR-14886:
-
Note that the patch cannot fix the cases where the error message contains the
full stack trace.
For example : SOLR-8319 (SOLR-8921)
Refer to this comment in SOLR-8921 for hints on how to generate an NPE, and you
will see the stack trace in the error message.
https://issues.apache.org/jira/browse/SOLR-8921?focusedCommentId=16646667=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16646667
{code}
org.apache.solr.client.solrj.impl.BaseHttpSolrClient$RemoteSolrException
org.apache.solr.client.solrj.impl.BaseHttpSolrClient$RemoteSolrException
Error from server at null: java.lang.NullPointerException at
java.base/java.util.concurrent.ConcurrentHashMap.get(Unknown Source) at
org.apache.solr.util.ConcurrentLFUCache.get(ConcurrentLFUCache.java:163) at
org.apache.solr.search.LFUCache.get(LFUCache.java:198) at
org.apache.solr.search.SolrIndexSearcher.getPositiveDocSet(SolrIndexSearcher.java:843)
at
org.apache.solr.search.SolrIndexSearcher.numDocs(SolrIndexSearcher.java:2066)
at
org.apache.solr.handler.component.PivotFacetProcessor.getSubsetSize(PivotFacetProcessor.java:355)
at
org.apache.solr.handler.component.PivotFacetProcessor.processSingle(PivotFacetProcessor.java:218)
at
org.apache.solr.handler.component.PivotFacetProcessor.process(PivotFacetProcessor.java:166)
at
org.apache.solr.handler.component.FacetComponent.process(FacetComponent.java:280)
at
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:360)
at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:214)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:2627) at
org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:795) at
org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:568) at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:415)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:345)
at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1596)
at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:545)
at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:590)
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:1610)
at
org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233)
at
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1300)
at
org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188)
at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:485)
at
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1580)
at
org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186)
at
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1215)
at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
at
org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:221)
at
org.eclipse.jetty.server.handler.InetAccessHandler.handle(InetAccessHandler.java:177)
at
org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:146)
at
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
at
org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:322)
at
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
at org.eclipse.jetty.server.Server.handle(Server.java:500) at
org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:383) at
org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:547) at
org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:375) at
org.eclipse.jetty.server.HttpChannel.run(HttpChannel.java:335) at
org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:336)
at
org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:313)
at
org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:171)
at
org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.produce(EatWhatYouKill.java:135)
at org.eclipse.jetty.http2.HTTP2Connection.produce(HTTP2Connection.java:170)
at org.eclipse.jetty.http2.HTTP2Connection.onFillable(HTTP2Connection.java:125)
at
[jira] [Commented] (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=17273160#comment-17273160 ] Isabelle Giguere commented on SOLR-14886: - Well... silly me. After looking at QueryResponseWriter, method SolrCore.postDecorateResponse, and places where the "trace" element of the response is set, it occurred to me that all we need to do is block the stack trace from the HTTP response. That's handled in ResponseUtils. Patch off branch_8x, for a start. It should eventually be adapted to master branch (Solr 9). - Add a property "hideStackTrace" to solr.xml - In NodeConfig, the default value is "false", for back-compatibility. - Use the new property in ResponseUtils, to print out, or not, the stack trace. - Adapt code that calls ResponseUtils There's no direct path between solr.xml and ResponseUtils, or any class that uses ResponseUtils, so the "hideStackTrace" property is duplicated in CoreContainer, just so it lives in a place where it can be read. May not be the best approach. > 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 > Attachments: SOLR-14886.patch > > > 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] [Commented] (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 commented on SOLR-14886:
-
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
org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:146)
at
[jira] [Commented] (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 commented on SOLR-14886:
-
[~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
[jira] [Commented] (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=17200150#comment-17200150 ] Jason Gerlowski commented on SOLR-14886: Curious: is there a particular use case you have in mind for this? Is this an aesthetics thing, where you want to shield users from stacktraces that'll be extra-noise or alarming to them? Or are you seeing some security or other concern here? > Suppress stack trace in Query response. > --- > > Key: SOLR-14886 > URL: https://issues.apache.org/jira/browse/SOLR-14886 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >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
