3 ms·

Totally agreed with this. MongoDB’s default security posture is ridiculous, and amazingly it used to be even worse.

• jbverschoor 5y ago
  It’s exactly the same for redis, which means if used for jobs, you can insert arbitrary code.
  • berkes 5y ago
    All my async job code lives in a codebase and redis merely contains the payload and some ids. What system, framework or stack are you using that stores the code of the job in the database? I'm curious, because I can imagine it solves some issues, e.g. deploying new code while allowing old code to finish running and scheduled jobs.
    • arp242 5y ago
      I think what they mean is Redis' Lua scripting stuff with EVAL and such. Also, if you have stuff like this in Redis, which will get picked up by a job runner: {"runjob": "foojob", "params": ["one", "two"]} Depending on how your job runner interprets this, it can be a big problem if people can write to this. At the very least it'll be a DoS in most cases, at worst (SQL) database, shell access, or leaking of passwords.
    • jbverschoor 5y ago
      Depending on the implementation of your job framework you can either: - run jobs that aren’t supposed to run (removing an account for example, is that’s scheduled after a 2 week grace period) maybe an export or import job. Can be anything of course - if your job runner allows scripts, or arbitrary class methods, you can do whatever you want - you can remove jobs if you feel like it - if you can escape redis because of whatever exploit, you now have access to the internal network In general I use sidekiq, but resque and inspired implementations generally work on simply calling perform(), so any class with such a method can be called, depending on the typesystem. The biggest two issues are the ability to perform any defined task, and the larger attack surface of an exposed redis server