Today with modern JIT compilers its probably not much faster...
x["a"]["b"]["c"]
var array = ["foo", "bar"]
"eval is evil", if you will.
In my case, code supplied by the end user is compiled into a different language such that I think I can prevent intentionally-malicious activity.
Nonetheless, spinning up a VM to create an environment in which potentially untrustworthy code is executed before then destroying the VM seems the safest option.
Lambda allows arbitraty network access and may allow access to your AWS resources.
If you have to do this, the best approach is to containerise it, use capabilities to enforce restrictions and run in a virtual machine as isolated as possible.
It's still not great though. Some languages (eg Java) have additional features that help with this though.
I didn’t mention containers since they don’t provide strong isolation and some people misuse them as though they do. There’s no harm in using them as another layer of defense, but hardware virtualization provides much better security.
As for mostly-full-featured `eval`: iirc Perl itself has a facility to create restricted sub-interpreters and run scripts that can't do certain things. (Though I might be confusing Perl with PHP here.)
Besides that approach, simply rolling your own parser using a parser combinator library is super simple. The word combinator makes it seem complicated, but it's actually the opposite, using parser combinators is a lot simpler than writing a parser the traditional way you might have learned in formal education.
Implementing a simple DSL like for example an event-filtering language should cost a competent but fully inexperienced programmer maybe 1 or 2 weeks for a proof of concept, and then 3-6 more weeks to get it production ready depending on the feature set of course.
Of course, that's more time than simply running the V8 interpreter over your input string, and maybe running the V8 interpreter over your input string is an awesome way to empower your (trusted) customers.
Have you tried writing your own interpreter?
Handles user input data??
Uses ‘eval’???
this doesn't work in perl 5.6.2! grrrr
Sept. 26, 2008 - Version 7.44
- Added read support for DjVu images
It was not uncommon to manually ./configure, make, make install tarballs locally in those days, especially not on systems like Slackware so I can see it being possible to have old packages installed that were not automagically updated.
I'd accept this for maybe pre-2000, but people should really know better.
I looked at the front-page of that library. It says it cleans metadata from a huge number of file format. Frankly it looks more like something you would use on your own, known safe, files before sharing them online.
I'm not sure the tool is presented as a sanitizer for untrusted input. At least, it does not claim to be.
Why does Gitlab need to clean metadata from DjVu files? Wtf are DjVu files?!
It doesn't. It needs to clean metadata from JPEG and TIFF files. They didn't properly check if the files were actually of those types, and Exiftool performed its own content type detection to end up in its DjVu code.
> Wtf are DjVu files?!
DjVu is basically an alternative to PDF.[1]
We are already avoiding / trying to avoid way too much interesting and useful things. All for the sake of security and only to encounter new ways to be attacked. Instead of "avoid" how about actually organizing worldwide intolerance and hunt for those attackers.