[
https://issues.apache.org/jira/browse/SOLR-1603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806616#action_12806616
]
Hoss Man commented on SOLR-1603:
--------------------------------
{quote}
the output is a complex Perl data structure with search results which would
presumably immediately be assigned to a variable - not eval'd.
Absolutely agree with Erik and Yonik - I can't think of a realistic case in
which this would present a security risk.
{quote}
The only way (i know of) to utilize a string based representation of a data
structure like this in perl is using eval to convert it from a string
representation to the intended data structures...
bq. I'm aware of the risk of eval'ing untrusted strings, but I'm not sure how
this could be a problem with a Solr response.
...The issue is that If you have a network service whose output format is only
useful when "eval"ed by the client, then even if that service only ever
produces serialized data (and not serialized code) it still opens the client up
to man in the middle attacks where a malicious server can generate a response
that _does_ include malicious code, and that code is executed by the client ...
man in the middle attacks of something like XML that provide tainted data are
bad enough, but the possibility of tainted code is really sketchy.
As i said before: i'm not making any statements about this patch being
more/less safe then any of the other existing response writers that are only
useful when "eval"ed in a particular language interpreter -- my point was that
while I have never had any clear notion about how/when evaling strings from an
external source was considered "acceptable" in those language communities (the
example of python's literal_eval is a good one), I _am_ a heavy perl user, and
i do know that the Perl community as a whole actively discourages using eval to
deserialize "perl" from remote services -- this is precisely why things like
YAML and the Storable API were created. Both have options to control how they
should behave if/when code is encountered in the serialized data.
I can see value in adding an output format designed to be trivially useful for
perl, but i don't feel comfortable advertising something for Perl users that
directly violates Perl best practices -- Particularly when we already have two
writers that are fairly easy to use from perl anyway (XML and JSON)
> Perl Response Writer
> --------------------
>
> Key: SOLR-1603
> URL: https://issues.apache.org/jira/browse/SOLR-1603
> Project: Solr
> Issue Type: New Feature
> Components: Response Writers
> Reporter: Claudio Valente
> Priority: Minor
> Attachments: SOLR-1603.2.patch, SOLR-1603.patch
>
>
> I've made a patch that implements a Perl response writer for Solr.
> It's nan/inf and unicode aware.
> I don't know whether some fields can be binary but if so I can probably
> extend it to support that.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
