| Newsgroups |
gmane.editors.sed.user |
| Message-ID |
<[email protected]> |
On 17Sep2017 06:00, Daniel Goldman <[email protected]> wrote:
>"But second, and this is critical, you need to be absolutely totally sure that the marker "EOD" does not appear in the source data. If it does appear then (a) the data will terminate earlier (just annoying) but (b) critically, the following data will be fed to your shell as commands."
>
> Respectfully, I do not think that is the case. I would like to see that (data terminate early, following data fed to shell as commands) in an example. To my understanding, there is no risk, because the EOD marker has to appear on a line by itself. The bash reference manual says "This type of redirection instructs the shell to read input from the current source until a line containing only word (with no trailing blanks) is seen." We know the format of the source data. It will *not* have a line solely with EOD.
That's the point: you don't know for sure in the future.
If this is one off, with a fixed data set that you have _prescanned_ for
absence of the marker, then you're ok.
But this looks like the OP's scraping web page source data (the php behind the
page, not the rendered HTML). It sounds like this might reasonably get reused
again for future data.
> Here is example with EOD in the data, works fine, data does not terminate
> early:
> $ cat thephpfile
><?php
>$date = "2017-07-23";
>$time = "23:59";
>$dummy = "EOD";
><?php
>$date = "2017-07-24";
>$time = "23:59";
>$dummy = "1125";
And if someone creates input data like this?
<?php
$date = "2017-07-23";
$time = "23:59";
$dummy = "7777";
EOD
rm -r $HOME
<?php
$date = "2017-07-24";
$time = "23:59";
$dummy = "1125";
(Indented for clarity, intending the EOD hard against the left in real life.)
This is why this kind of recipe is not generally promulgated: it is very easy
for unanticipated input data to break the recipe, and when that breakage
escapes into the shell, that is the "arbitrary code execution" situation you
see mentioned all the time in security reports.
> So unless I am missing something, or some other fault turns up (always
> possible), I think Jim's solution is pretty much ideal.
It is succinct and cool and neat, and with known-safe input data it will work.
But the thing about automation is that one tends to reuse it, forgetting its
internals. This one is subject to code injection from the input data, and is
thus _not_ ideal. If it included a prescan for the marker, or a processing line
which escaped any potential marker, then it might be ok.
Without that it is like building a wall with bricks made of explosive: probably
perfectly safe as long as you never drop something.
Cheers,
Cameron Simpson <[email protected]> (formerly [email protected])