I noticed a part of the guide that mentioned a security issue stemming from string input sanitizing for the ctx argument passed to job. Link: #2
I was surprised to see that when assigning the string context variable that the only thing that seemed to go on was wrapping the string in a set of single-quotes:
case 'string':
variable = `'${config.ctx[key]}'`
break
which allows the exploit shown in #2 to occur. This PR simply uses JSON.stringify instead, just like it is already done with object types to stop someone from doing some quote-related funny-business. I won't claim that this makes everything particularly safe, but it does solve the simple case shown in the issue description. Perhaps the docs can be updated to show how such an exploit could still occur.
This PR also adds a test that checks, and fails on master, but passes on this PR, for allowance of arbitrary code execution in strings passed to the ctx argument of job.
I noticed a part of the guide that mentioned a security issue stemming from string input sanitizing for the
ctx
argument passed tojob
. Link: #2I was surprised to see that when assigning the string context variable that the only thing that seemed to go on was wrapping the string in a set of single-quotes:
which allows the exploit shown in #2 to occur. This PR simply uses
JSON.stringify
instead, just like it is already done withobject
types to stop someone from doing some quote-related funny-business. I won't claim that this makes everything particularly safe, but it does solve the simple case shown in the issue description. Perhaps the docs can be updated to show how such an exploit could still occur.This PR also adds a test that checks, and fails on master, but passes on this PR, for allowance of arbitrary code execution in strings passed to the
ctx
argument ofjob
.