Beefy Boxes and Bandwidth Generously Provided by pair Networks
Do you know where your variables are?

Re^3: Storing state of execution

by Anonymous Monk
on Dec 10, 2015 at 07:38 UTC ( #1149868=note: print w/replies, xml ) Need Help??

in reply to Re^2: Storing state of execution
in thread Storing state of execution

afoken: Data::Dumper generates executable perl code that has to be parsed back into the program using string eval. That works, sure, but it is a security nightmare: Imagine someone inserting system "rm -rf /" into the saved dump.

Try Re: Perl data notation (PSON/JSON/SafestUndumper), Re: Which parameter for permit_only? (Safest Undumper of Data::Dumper)

Replies are listed 'Best First'.
Re^4: Storing state of execution
by afoken (Canon) on Dec 11, 2015 at 18:52 UTC

    I prefer to have a storage format that by definition can not contain executable code instead of relying on a filter that tries to prevent malicious code execution inside a string eval. One bug in Safe and the "SafestUndumper" is no longer save, but instead happily executes malicious code.

    Also, the "non-executable" formats force the programmer to use a parser. There is no way to accidentally or intentionally use a string eval on those formats.

    So, who would intentionally use a string eval on untrusted code?

    • The new programmer who does not know enough about the project.
    • The new programmer who did not learn the style guide by heart.
    • The lazy programmer who thinks "It's just a quick hack, I'll use string eval for now because I trust my current, hand-written config file, and fix that problem later." (We all know from experience that it won't be fixed until at least a few years later.)
    • The stupid programmer who thinks "all of that stinking modules are just a stupid waste of time, eval is much faster".

    A little bit of bean counting:

    Actually, every storage format that can contain strings can - in theory - also contain executable Perl code. But when reading back formats like XML or JSON, an explicit string eval on an extracted string is required, and that string eval is not present in the library reading the file format (or, at least, it should not be present).

    Oh, and string eval means more than just eval $string:

    • do $filename is a string eval on a file content - exactly what the four programmers from above would like to use to undump Data::Dumper output.
    • require $filename - it's do $filename at the core, plus a little bit of book keeping to avoid repeated reading of the file.
    • use $filename - require with an implicit BEGIN block.
    • evalbytes $bytes - new since v5.16

    And finally: Any Javascript compiler/interpreter must be able to read and execute JSON, as it is a very restricted subset of Javascript/ECMAScript. That also means that using Javascripts eval (always a string eval) to read JSON is a tempting, but stupid idea, on the same level as using Perl's string eval to read Data::Dumper output. Since ECMAScript Fifth Edition (2009), there is a special JSON parser embedded in the Javascript environment (see


    Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://1149868]
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others contemplating the Monastery: (4)
As of 2022-05-28 08:15 GMT
Find Nodes?
    Voting Booth?
    Do you prefer to work remotely?

    Results (98 votes). Check out past polls.