4 ms·

The second example is vulnerable to command injection. ./test.sh ls -la

• admax88q 7y ago
  "vulnerable" It's a shell script as part of your build system. Surely you're not passing untrusted input to your command line are you?
  • jtaft 7y ago
    Someone might. It's always better not to introduce such code.
    • GordonS 7y ago
      Unless I'm missing something, this seems a bit silly. Why would I be any more likely to type `test.sh rm -rf /` that `rm -rm /`?
      • jtaft 7y ago
        I think you're both right that the risk is low, assuming it's a build script that is to be run locally by a developer. Code tends to get copied and pasted, and can easily sneak into other programs. Programs are integrated in ways which weren't originally intended. It's not a secure coding pattern, and that's why I mentioned it. During security reviews, I would be focusing on more risky vulnerabilities, but I still review and flag findings in build scripts. I'm more concerned with build scripts downloading content over HTTP, or missing security compiler flags, but I digress.