[
https://issues.apache.org/jira/browse/SOLR-13987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16988318#comment-16988318
]
Jason Gerlowski edited comment on SOLR-13987 at 12/5/19 12:25 AM:
------------------------------------------------------------------
bq. doing things like making it opt-in as Joel suggests are really good short
term solutions.
It seems like there _is_ agreement on creating a headless mode for Solr then.
I'll spin that off as a separate jira so it doesn't further confuse this one.
Feel free to assign that to yourself if you're willing to pick it up Joel. I'm
also happy to help with it. (see SOLR-14014)
bq. Its really insecure that the current admin UI relies on eval() [...] I will
fix this issue if nobody gets there first.
Awesome. Of course, I think Joel has a valid point that drastic changes are
likely to generate pushback (or even vetos). But there's no point crossing
that bridge before we come to it. Maybe the JS changes don't need to be
drastic at all. Looking forward to seeing what you (or whoever gets there
first) come up with.
bq. It is a real security issue. [...] Its bullshit to say that "oh its behind
a firewall, so we can write insecure code and be lazy". [...] Insecure code is
a problem.
The "deploy-behind-firewall" rule isn't there to enable community laziness.
It's there because Solr - in deep-rooted ways inherent to its design - is
insecure to expose to the world. The way we use ZooKeeper, the way APIs expose
network and filesystem information, the metrics that are exposed, the lack of
rate limiting and the susceptibility to DoS attacks. _Solr is not and was
never designed to be used outside of a firewall._ It's not laziness to say
that, it's caution, honesty, and realism.
Should we plug the holes we know of? Of course. Should we fix XSS issues? Of
course. I'm glad you're doing this. But even with this and other recent
security tickets fixed - I still don't think that changes the situation
fundamentally. Solr will still be unsafe exposed to the world, and it seems
like wishful thinking to tell users otherwise.
I guess I just want to make sure that no one reading this jira gets the
impression that "Hey, the UI's been fixed up, Solr's safe to expose externally
now".
was (Author: gerlowskija):
bq. doing things like making it opt-in as Joel suggests are really good short
term solutions.
It seems like there _is_ agreement on creating a headless mode for Solr then.
I'll spin that off as a separate jira so it doesn't further confuse this one.
Feel free to assign that to yourself if you're willing to pick it up Joel. I'm
also happy to help with it.
bq. Its really insecure that the current admin UI relies on eval() [...] I will
fix this issue if nobody gets there first.
Awesome. Of course, I think Joel has a valid point that drastic changes are
likely to generate pushback (or even vetos). But there's no point crossing
that bridge before we come to it. Maybe the JS changes don't need to be
drastic at all. Looking forward to seeing what you (or whoever gets there
first) come up with.
bq. It is a real security issue. [...] Its bullshit to say that "oh its behind
a firewall, so we can write insecure code and be lazy". [...] Insecure code is
a problem.
The "deploy-behind-firewall" rule isn't there to enable community laziness.
It's there because Solr - in deep-rooted ways inherent to its design - is
insecure to expose to the world. The way we use ZooKeeper, the way APIs expose
network and filesystem information, the metrics that are exposed, the lack of
rate limiting and the susceptibility to DoS attacks. _Solr is not and was
never designed to be used outside of a firewall._ It's not laziness to say
that, it's caution, honesty, and realism.
Should we plug the holes we know of? Of course. Should we fix XSS issues? Of
course. I'm glad you're doing this. But even with this and other recent
security tickets fixed - I still don't think that changes the situation
fundamentally. Solr will still be unsafe exposed to the world, and it seems
like wishful thinking to tell users otherwise.
I guess I just want to make sure that no one reading this jira gets the
impression that "Hey, the UI's been fixed up, Solr's safe to expose externally
now".
> fix admin UI to not rely on javascript eval()
> ---------------------------------------------
>
> Key: SOLR-13987
> URL: https://issues.apache.org/jira/browse/SOLR-13987
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Robert Muir
> Priority: Major
>
> Followup from SOLR-13982: currently any CSP is weak because it must allow
> this eval: means arbitrary javascript can still be executed.
> Let's fix the admin UI to not require eval so it can be disabled by the
> browser.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
