This example code intends to take the name of a user and list the contents of that user's home directory. It is subject to the first variant of OS command injection.
The $userName variable is not checked for malicious input. An attacker could set the $userName variable to an arbitrary OS command such as:
BadPHP
$userName = $_POST["user"];$command = 'ls -l /home/' . $userName;system($command);
The following code segment reads the name of the author of a weblog entry, author, from an HTTP request and sets it in a cookie header of an HTTP response.
Assuming a string consisting of standard alpha-numeric characters, such as "Jane Smith", is submitted in the request the HTTP response including this cookie might take the following form:
BadJava
String author = request.getParameter(AUTHOR_PARAM);...Cookie cookie = new Cookie("author", author);cookie.setMaxAge(cookieExpiration);response.addCookie(cookie);
Consider the following program. It intends to perform an "ls -l" on an input filename. The validate_name() subroutine performs validation on the input to make sure that only alphanumeric and "-" characters are allowed, which avoids path traversal (CWE-22) and OS command injection (CWE-78) weaknesses. Only filenames like "abc" or "d-e-f" are intended to be allowed.
However, validate_name() allows filenames that begin with a "-". An adversary could supply a filename like "-aR", producing the "ls -l -aR" command (CWE-88), thereby getting a full recursive listing of the entire directory and all of its sub-directories. There are a couple possible mitigations for this weakness. One would be to refactor the code to avoid using system() altogether, instead relying on internal functions. Another option could be to add a "--" argument to the ls command, such as "ls -l --", so that any remaining arguments are treated as filenames, causing any leading "-" to be treated as part of a filename instead of another option. Another fix might be to change the regular expression used in validate_name to force the first character of the filename to be a letter or number, such as:
BadPerl
my $arg = GetArgument("filename"); do_listing($arg); sub do_listing { my($fname) = @_; if (! validate_name($fname)) { print "Error: name is not well-formed!\n"; return; } # build command my $cmd = "/bin/ls -l $fname"; system($cmd); } sub validate_name { my($name) = @_; if ($name =~ /^[\w\-]+$/) { return(1); } else { return(0); } }
Consider the following program. It intends to perform an "ls -l" on an input filename. The validate_name() subroutine performs validation on the input to make sure that only alphanumeric and "-" characters are allowed, which avoids path traversal (CWE-22) and OS command injection (CWE-78) weaknesses. Only filenames like "abc" or "d-e-f" are intended to be allowed.
However, validate_name() allows filenames that begin with a "-". An adversary could supply a filename like "-aR", producing the "ls -l -aR" command (CWE-88), thereby getting a full recursive listing of the entire directory and all of its sub-directories. There are a couple possible mitigations for this weakness. One would be to refactor the code to avoid using system() altogether, instead relying on internal functions. Another option could be to add a "--" argument to the ls command, such as "ls -l --", so that any remaining arguments are treated as filenames, causing any leading "-" to be treated as part of a filename instead of another option. Another fix might be to change the regular expression used in validate_name to force the first character of the filename to be a letter or number, such as:
GoodPerl
if ($name =~ /^\w[\w\-]+$/) ...
Consider a "CWE Differentiator" application that uses an an LLM generative AI based "chatbot" to explain the difference between two weaknesses. As input, it accepts two CWE IDs, constructs a prompt string, sends the prompt to the chatbot, and prints the results. The prompt string effectively acts as a command to the chatbot component. Assume that invokeChatbot() calls the chatbot and returns the response as a string; the implementation details are not important here.
To avoid XSS risks, the code ensures that the response from the chatbot is properly encoded for HTML output. If the user provides CWE-77 and CWE-78, then the resulting prompt would look like:
BadPython
prompt = "Explain the difference between {} and {}".format(arg1, arg2) result = invokeChatbot(prompt) resultHTML = encodeForHTML(result) print resultHTML
Consider a "CWE Differentiator" application that uses an an LLM generative AI based "chatbot" to explain the difference between two weaknesses. As input, it accepts two CWE IDs, constructs a prompt string, sends the prompt to the chatbot, and prints the results. The prompt string effectively acts as a command to the chatbot component. Assume that invokeChatbot() calls the chatbot and returns the response as a string; the implementation details are not important here.
To avoid XSS risks, the code ensures that the response from the chatbot is properly encoded for HTML output. If the user provides CWE-77 and CWE-78, then the resulting prompt would look like:
GoodPython
cweRegex = re.compile("^CWE-\d+$") match1 = cweRegex.search(arg1) match2 = cweRegex.search(arg2) if match1 is None or match2 is None: # throw exception, generate error, etc. prompt = "Explain the difference between {} and {}".format(arg1, arg2) ...
The following code is a workflow job written using YAML. The code attempts to download pull request artifacts, unzip from the artifact called pr.zip and extract the value of the file NR into a variable "pr_number" that will be used later in another job. It attempts to create a github workflow environment variable, writing to $GITHUB_ENV. The environment variable value is retrieved from an external resource.
The code does not neutralize the value of the file NR, e.g. by validating that NR only contains a number (CWE-1284). The NR file is attacker controlled because it originates from a pull request that produced pr.zip. The attacker could escape the existing pr_number and create a new variable using a "\n" (CWE-93) followed by any environment variable to be added such as:
BadOther
name: Deploy Preview jobs: deploy: runs-on: ubuntu-latest steps: - name: 'Download artifact' uses: actions/github-script with: script: | var artifacts = await github.actions.listWorkflowRunArtifacts({ owner: context.repo.owner, repo: context.repo.repo, run_id: ${{ github.event.workflow_run.id }}, }); var matchPrArtifact = artifacts.data.artifacts.filter((artifact) => { return artifact.name == "pr" })[0]; var downloadPr = await github.actions.downloadArtifact({ owner: context.repo.owner, repo: context.repo.repo, artifact_id: matchPrArtifact.id, archive_format: 'zip', }); var fs = require('fs'); fs.writeFileSync('${{github.workspace}}/pr.zip', Buffer.from(downloadPr.data)); - run: | unzip pr.zip echo "pr_number=$(cat NR)" >> $GITHUB_ENV
The following code is a workflow job written using YAML. The code attempts to download pull request artifacts, unzip from the artifact called pr.zip and extract the value of the file NR into a variable "pr_number" that will be used later in another job. It attempts to create a github workflow environment variable, writing to $GITHUB_ENV. The environment variable value is retrieved from an external resource.
The code does not neutralize the value of the file NR, e.g. by validating that NR only contains a number (CWE-1284). The NR file is attacker controlled because it originates from a pull request that produced pr.zip. The attacker could escape the existing pr_number and create a new variable using a "\n" (CWE-93) followed by any environment variable to be added such as:
GoodOther
The code could be modified to validate that the NR file only contains a numeric value, or the code could retrieve the PR number from a more trusted source.