-
Notifications
You must be signed in to change notification settings - Fork 674
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SOLR-14886 : suppress stack traces in query response #1632
SOLR-14886 : suppress stack traces in query response #1632
Conversation
solr/core/src/test/org/apache/solr/servlet/HideStackTraceTest.java
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
While I can understand that Solr needs NodeConfig / solr.xml, this feels way more like a simple Java system property situation. We certainly have many of the latter.
Maybe someday we would have a unification in a generic way so that we needn't go through all the NodeConfig plumbing just to have some global flag.
@igiguere could you rebase on top of main branch (as suggested on the dev list)? |
@stillalex : I'm in CHANGES.txt a couple of times with my full name |
I rebased this branch on the fork's main (up to date with /solr main). There were no changes to push, so I don't know if a build will be triggered. |
I'm not seeing a new build, I think you have to force push the rebase so the build can apply correctly |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See org.apache.solr.search.json.TestJsonRequestWithEdismaxDefType to see a new breed of tests. Notice the SolrClientTestRule. Notice a ConfigRequest is used to manipulate a configuration instead of creating yet another config file. We have too many such config files; it's a maintenance problem. Feedback on this is welcome!
@dsmiley I am attempting to rewrite the test using thew new mode datapoints (the test and the stacktrace of the exception, left rule init outside for brevity):
|
Thanks for trying Alex! EmbeddedSolrServer: Ideally, a test (or more likely the test infrastructure behind the scenes) could pick the response format if it wants, say, XML or JSON instead of the parsed NamedList, such as if assertJQ (JSON path custom thing) or assertQ (XPath). The InputStreamResponseParser may be needed, which is a bit of a special thing (see Find-Usages to see for yourself). |
dc7733e
to
80bf80a
Compare
@dsmiley I refactored the test as best I could. please take a look and let me know if more cleanup is needed. |
@@ -301,6 +301,8 @@ && getZkController().getOverseer() != null | |||
|
|||
private final AllowListUrlChecker allowListUrlChecker; | |||
|
|||
private final boolean hideStackTrace; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think a simple global boolean needs to be yet another field on CoreContainer. Even the NodeConfig stuff is overkill for what could be a system property.
If we do keep NodeConfig, we could still do away with this field because the NodeConfig stays around as a field on CoreContainer as cfg
.
@@ -28,6 +28,10 @@ | |||
public class ResponseUtils { | |||
private ResponseUtils() {} | |||
|
|||
// System property to use if the Solr core does not exist or solr.hideStackTrace is not | |||
// configured. (i.e.: a lot of unit test). | |||
private static final boolean SYSTEM_HIDE_STACK_TRACES = Boolean.getBoolean("solr.hideStackTrace"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is all we need for internal config IMO.
import org.apache.http.client.methods.HttpGet; | ||
import org.apache.http.util.EntityUtils; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As a project, we'd like to get away from needless use of Apache HttpClient. We can use JDK HttpClient here.
It's sad to see so much ceremony in NodeConfig :-( -- an issue for another PR. |
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. Add unit test
adapt getTypedErrorInfo to suppress the stack trace
Co-authored-by: Christine Poerschke <[email protected]>
address review comments: - ensure the stack trace is logged while being hidden from the HTTP response - evaluate config setting and system property in a single location Fix unit test
Address review comment: read the system property "solr.hideStackTrace" only once. The system property is used if the Solr core does not exist or solr.hideStackTrace is not configured. (in a lot of unit test). Documentation also mentions that Solr can run without configuring any core (not sure how useful it is then): https://solr.apache.org/guide/solr/latest/configuration-guide/core-discovery.html Pass a Boolean instead of the SolrCore object to methods of ResponseUtils. Search the whole code base for places where "trace" is added, and check for "hideStackTrace" before adding the trace. Refactor the unit test: Using an Http2SolrClient, the test threw the exception that was supposed to demonstrate the fix! Use a CloseableHttpClient, to query Solr from "outside", without SolrJ, and get the plain XMl response.
Code clean-up.
Address review comments: use boolean instead of Boolean. Set the system property as default in NodeConfig. Simplify the initialization of the unit test. Add a logger in HideStackTraceTest, to avoid failures on task "validateSourcePatterns", due to logger name and logger pattern Built and checked locally - gradlew.bat compileJava compileTestJava test - gradlew.bat tidy check -x test
address review comment: fix default hideStackTrace
422925b
to
5b5d907
Compare
having to rebase + force commit to get crave build unstuck is becoming a real pain |
Added a property "hideStackTrace" to solr.xml or system property 'solr.hideStackTrace' to not include error stack trace in the response. --------- Co-authored-by: Christine Poerschke <[email protected]> Co-authored-by: Alex Deparvu <[email protected]> (cherry picked from commit cf30265)
https://issues.apache.org/jira/browse/SOLR-14886
Description
Stack traces are considered a security risk. Please refer to OWASP for a full explanation:
https://owasp.org/Top10/A05_2021-Security_Misconfiguration/
Solution
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.
Also check if stack traces should be hidden everywhere the "trace" element is added to a response. (I searched for the string"trace" - with quotes - throughout the Solr code. Hope I got everything.)
Tests
org.apache.solr.servlet.HideStackTraceTest : force an exception into the response, and assert that if hideStackTrace=true, the stack trace is not shown.
Checklist
Please review the following and check all that apply:
main
branch../gradlew check
.