Skip to content

Update frogbot-scan-pull-request.yml#6

Open
shaniil wants to merge 1 commit intomainfrom
shaniil-patch-2
Open

Update frogbot-scan-pull-request.yml#6
shaniil wants to merge 1 commit intomainfrom
shaniil-patch-2

Conversation

@shaniil
Copy link
Copy Markdown
Owner

@shaniil shaniil commented Nov 1, 2024

No description provided.

@github-actions
Copy link
Copy Markdown

github-actions bot commented Nov 1, 2024

🚨 Frogbot scanned this pull request and found the below:

📦 Vulnerable Dependencies

✍️ Summary

SEVERITY CONTEXTUAL ANALYSIS DIRECT DEPENDENCIES IMPACTED DEPENDENCY FIXED VERSIONS CVES

Critical
Applicable lodash:4.17.0 lodash 4.17.0 [4.17.12] CVE-2019-10744

Critical
Applicable ejs:3.1.6 ejs 3.1.6 - CVE-2023-29827

Critical
Applicable ejs:3.1.6 ejs 3.1.6 [3.1.7] CVE-2022-29078

Critical
Not Covered vm2:3.9.4 vm2 3.9.4 [3.9.6] CVE-2021-23555

Critical
Not Covered cors.js:0.0.1-security cors.js 0.0.1-security - -

High
Not Covered express:4.18.2 path-to-regexp 0.1.7 [0.1.10]
[1.9.0]
[3.3.0]
[6.3.0]
[8.0.0]
CVE-2024-45296

Critical
Not Applicable vm2:3.9.4 vm2 3.9.4 - CVE-2023-37903

Critical
Not Applicable vm2:3.9.4 vm2 3.9.4 - CVE-2023-37466

Critical
Not Applicable protobufjs:6.11.2 protobufjs 6.11.2 [6.11.4]
[7.2.5]
CVE-2023-36665

Critical
Not Applicable vm2:3.9.4 vm2 3.9.4 [3.9.18] CVE-2023-32314

Critical
Not Applicable vm2:3.9.4 vm2 3.9.4 [3.9.17] CVE-2023-30547

Critical
Not Applicable vm2:3.9.4 vm2 3.9.4 [3.9.16] CVE-2023-29199

Critical
Not Applicable vm2:3.9.4 vm2 3.9.4 [3.9.15] CVE-2023-29017

Critical
Not Applicable vm2:3.9.4 vm2 3.9.4 [3.9.10] CVE-2022-25893

Critical
Not Applicable vm2:3.9.4 vm2 3.9.4 [3.9.11] CVE-2022-36067

High
Not Applicable express:4.18.2 body-parser 1.20.1 [1.20.3] CVE-2024-45590

High
Not Applicable protobufjs:6.11.2 protobufjs 6.11.2 [6.11.3] CVE-2022-25878

High
Not Applicable lodash:4.17.0 lodash 4.17.0 [4.17.21] CVE-2021-23337

High
Not Applicable lodash:4.17.0 lodash 4.17.0 [4.17.19] CVE-2020-8203

🔬 Research Details

[ CVE-2019-10744 ] lodash 4.17.0

Description:
lodash is a modern JavaScript utility library delivering modularity, performance, & extras.

The function defaultsDeep was found to be vulnerable to prototype pollution, when accepting arbitrary source objects from untrusted input

Example of code vulnerable to this issue -

const lodash = require('lodash'); 
const evilsrc = {constructor: {prototype: {evilkey: "evilvalue"}}};
lodash.defaultsDeep({}, evilsrc)

Remediation:

Development mitigations

Add the Object.freeze(Object.prototype); directive once at the beginning of your main JS source code file (ex. index.js), preferably after all your require directives. This will prevent any changes to the prototype object, thus completely negating prototype pollution attacks.

[ CVE-2023-29827 ] ejs 3.1.6

Description:
Embedded JavaScript templates, also known as EJS, is one of the most popular Node.js templating engines, which is compiled with the Express JS view system.

When rendering views using EJS, it is possible to bypass ejs' template injection restrictions, by abusing the closeDelimiter rendering option, in the case when -

  1. The template itself can be partially controlled by the attacker
  2. The template rendering options can be fully controlled by the attacker

The vulnerability was rightfully disputed due to the fact that a vulnerable configuration is extremely unlikely to exist in any real-world setup. As such, the maintainers will not provide a fix for this (non-)issue.

Example of a vulnerable application -

const express = require('express')
const app = express()
const port = 3000

app.set('view engine', 'ejs');

app.get('/page', (req,res) => {
    res.render('page', req.query); // OPTS (2nd parameter) IS ATTACKER-CONTROLLED
})

app.listen(port, () => {
  console.log("Example app listening on port ${port}")
})

Contents of page.ejs (very unlikely to be attacker controlled) -

%%1");process.mainModule.require('child_process').execSync('calc');//

In this case, sending closeDelimiter with the same malicious code that already exists at page.ejs will trigger the injection -
http://127.0.0.1:3000/page?settings[view%20options][closeDelimiter]=1")%3bprocess.mainModule.require('child_process').execSync('calc')%3b//

[ CVE-2022-29078 ] ejs 3.1.6

Description:
Embedded JavaScript templates, also known as EJS, is one of the most popular Node.js templating engines, which is compiled with the Express JS view system.

When rendering views using EJS, it is possible to perform template injection on the opts.outputFunctionName variable, since the variable is injected into the template body without any escaping. Although it is unlikely that the attacker can directly control the outputFunctionName property, it is possible that it can be influenced in conjunction with a prototype pollution vulnerability.

Once template injection is achieved, the attacker can immediately perform remote code execution since the template engine (EJS) allows executing arbitrary JavaScript code.

Example of a vulnerable Node.js application -

const express = require('express');
const bodyParser = require('body-parser');
const lodash = require('lodash');
const ejs = require('ejs');

const app = express();

app
    .use(bodyParser.urlencoded({extended: true}))
    .use(bodyParser.json());

app.set('views', './');
app.set('view engine', 'ejs');

app.get("/", (req, res) => {
    res.render('index');
});

app.post("/", (req, res) => {
    let data = {};
    let input = JSON.parse(req.body.content);
    lodash.defaultsDeep(data, input);
    res.json({message: "OK"});
});

let server = app.listen(8086, '0.0.0.0', function() {
    console.log('Listening on port %d', server.address().port);
});

Exploiting the above example for RCE -
curl 127.0.0.1:8086 -v --data 'content={"constructor": {"prototype": {"outputFunctionName": "a; return global.process.mainModule.constructor._load(\"child_process\").execSync(\"whoami\"); //"}}}'

Due to the prototype pollution in the lodash.defaultsDeep call, an attacker can inject the outputFunctionName property with an arbitrary value. The chosen value executes an arbitrary process via the child_process module.

Remediation:

Development mitigations

Add the Object.freeze(Object.prototype); directive once at the beginning of your main JS source code file (ex. index.js), preferably after all your require directives. This will prevent any changes to the prototype object, thus completely negating prototype pollution attacks.

Note that this mitigation is supposed to stop any prototype pollution attacks which can allow an attacker to control the opts.outputFunctionName parameter indirectly.

The mitigation will not stop any (extremely unlikely) scenarios where the JavaScript code allows external input to directly affect opts.outputFunctionName.

[ CVE-2021-23555 ] vm2 3.9.4

Description:
The package vm2 before 3.9.6 are vulnerable to Sandbox Bypass via direct access to host error objects generated by node internals during generation of a stacktraces, which can lead to execution of arbitrary code on the host machine.

[ XRAY-264729 ] cors.js 0.0.1-security

Description:
The package cors.js for Node.js contains malicious code that installs a persistent connectback shell. The package is typosquatting the popular cors package. When installed, the package opens a connectback shell to the hardcoded host 107.175.32.229 on TCP port 56173. The malicious payload achieves persistency by installing a cron job that repeats every 10 seconds - */10 * * * * *

Remediation:
As with any malware, the malicious package must be completely removed, and steps must be taken care to remediate the damage that was done by the malicious package -

Removing the malicious package

Run npm uninstall cors.js

Refreshing stolen credentials

Many malicious packages steal stored user credentials, focusing on the following -

It is highly recommended to change or revoke data that is stored in the infected machine at those locations

Stopping malicious processes

Many malicious packages start malicious processes such as connectback shells or crypto-miners. Search for any unfamiliar processes that consume a large amount of CPU or a large amount of network traffic, and stop them. On Windows, this can be facilitated with Sysinternals Process Explorer.

Removing installed backdoors

Many malicious packages install themselves as a persistent backdoor, in order to guarantee the malicious code survives a reboot. Search for any unfamiliar binaries set to be run on startup, and remove them. On Windows, this can be facilitated with Sysinternals Autoruns.

Defining an Xray policy that blocks downloads of Artifacts with malicious packages

It is possible to create an Xray policy that will not allow artifacts with identified malicious packages to be downloaded from Artifactory. To create such a policy, add a new Security policy and set Minimal Severity to Critical. Under Automatic Actions check the Block Download action.

Contacting the JFrog Security Research team for additional information

Optionally, if you are unsure of the full impact of the malicious package and wish to get more details, the JFrog Security Research team can help you assess the potential damage from the installed malicious package.

Please contact us at research@jfrog.com with details of the affected artifact and the name of the identified malicious package.

[ CVE-2024-45296 ] path-to-regexp 0.1.7

Description:
path-to-regexp turns path strings into a regular expressions. In certain cases, path-to-regexp will output a regular expression that can be exploited to cause poor performance. Because JavaScript is single threaded and regex matching runs on the main thread, poor performance will block the event loop and lead to a DoS. The bad regular expression is generated any time you have two parameters within a single segment, separated by something that is not a period (.). For users of 0.1, upgrade to 0.1.10. All other users should upgrade to 8.0.0.

Remediation:

Development mitigations

This vulnerability can be mitigated by manually defining the parameter's regular expression when two or more parameters exist in a single segment. For example, /flights/:from-:to(\\w+) instead of /flights/:from-:to.

[ CVE-2023-37903 ] vm2 3.9.4

Description:
vm2 is an open source vm/sandbox for Node.js. In vm2 for versions up to and including 3.9.19, Node.js custom inspect function allows attackers to escape the sandbox and run arbitrary code. This may result in Remote Code Execution, assuming the attacker has arbitrary code execution primitive inside the context of vm2 sandbox. There are no patches and no known workarounds. Users are advised to find an alternative software.

[ CVE-2023-37466 ] vm2 3.9.4

Description:
vm2 is an advanced vm/sandbox for Node.js. The library contains critical security issues and should not be used for production. The maintenance of the project has been discontinued. In vm2 for versions up to 3.9.19, Promise handler sanitization can be bypassed with the @@species accessor property allowing attackers to escape the sandbox and run arbitrary code, potentially allowing remote code execution inside the context of vm2 sandbox.

[ CVE-2023-36665 ] protobufjs 6.11.2

Description:
Protocol Buffers or "protobufs" are a language-neutral, platform-neutral, extensible way of serializing structured data. protobuf.js is a JavaScript library that allows creating and consuming protobufs.
An incomplete fix for CVE-2022-25878 has been reported as CVE-2023-36665.

Multiple prototype pollution vulnerabilities were detected in the protobuf.js library. Namely these can occur when:

  1. util.setProperty receives untrusted input in arguments 2 & 3 -
protobuf.util.setProperty({}, "constructor.prototype.verified", true);
  1. ReflectionObject.setParsedOption receives untrusted input in arguments 2 & 3
let obj = new protobuf.ReflectionObject("Test");
obj.setParsedOption("unimportant!", attackerFunc, "constructor.prototype.testFn");
  1. parse receives untrusted input (an untrusted .proto definition) -
protobuf.parse('option(a).constructor.prototype.verified = true;');
  1. load receives an untrusted .proto file -
protobuf.loadSync("poc.proto");

an example malicious .proto file -
option(foo).constructor.prototype.verified = true;

While most prototype pollution attacks lead to denial of service, it has been reported that code execution is possible when unsanitized user input is provided to the functions util.setProperty or ReflectionObject.setParsedOption.

Remediation:

Development mitigations

Add the Object.freeze(Object.prototype); directive once at the beginning of your main JS source code file (ex. index.js), preferably after all your require directives. This will prevent any changes to the prototype object, thus completely negating prototype pollution attacks.

[ CVE-2023-32314 ] vm2 3.9.4

Description:
vm2 is a sandbox that can run untrusted code with Node's built-in modules. A sandbox escape vulnerability exists in vm2 for versions up to and including 3.9.17. It abuses an unexpected creation of a host object based on the specification of Proxy. As a result a threat actor can bypass the sandbox protections to gain remote code execution rights on the host running the sandbox. This vulnerability was patched in the release of version 3.9.18 of vm2. Users are advised to upgrade. There are no known workarounds for this vulnerability.

[ CVE-2023-30547 ] vm2 3.9.4

Description:
vm2 is an open-source Node.js package that can be used for sandboxing untrusted code and creating isolated testing and development environments.
The vm2 package provides a secure virtual environment for running untrusted code, which cannot be escaped to the host machine.
However, a sandbox escape was discovered where untrusted code running inside the sandbox can escape and run arbitrary code on the host machine, even in the sandbox's default configuration.

To prevent the leaking of host context information into the virtual machine, the code given to the run() function is pre-processed and sanitized using the transformer() function before execution.
As a post-processing step, the code re-throws the sanitized exception inside a nested try-catch.

However, this may be proxied through a getPrototypeOf() proxy handler which can by itself throw an unsanitized host exception, resulting in the outer catch statement receiving it. This bypasses the sanitation and gains access to a pointer in the host context that may be exploited to run code outside the sandbox.

Example of running untrusted code in the sandbox -

const { VM } = require('vm2');
new VM().run(untrusted_code);
[ CVE-2023-29199 ] vm2 3.9.4

Description:
vm2 is an open-source Node.js package that can be used for sandboxing untrusted code and creating isolated testing and development environments.
The vm2 package provides a secure virtual environment for running untrusted code, which cannot be escaped to the host machine.
However, a sandbox escape was discovered where untrusted code running inside the sandbox can escape and run arbitrary code on the host machine, even in the sandbox's default configuration.

To prevent the leaking of host context information into the virtual machine, the code given to the run() function is pre-processed and sanitized using the transformer() function before execution. As a post-processing step, the ObjectPattern case replaces instances of $tmpname with the string value of tmpname (originally VM2_INTERNAL_TMPNAME). However, if the original code includes $tmpname in the catch condition, it can bypass the handleException() function and gain access to a pointer in the host context that may be exploited to run code in the host context.

Example of running untrusted code in the sandbox -

const { VM } = require('vm2');
new VM().run(untrusted_code);

Example of malicious code that triggers the issue when processed by the run() function:

aVM2_INTERNAL_TMPNAME = {};
function stack() {
    new Error().stack;
    stack();
}
try {
    stack();
} catch (a$tmpname) {
    a$tmpname.constructor.constructor('return process')().mainModule.require('child_process').execSync('touch pwned');
}

Remediation:

Development mitigations

Prevent user code to contain $tmpname by replacing it with a not-empty string. Example:

const { VM } = require('vm2');
const vm = new VM();
const code = userInputCode();
...
const modifiedCode = code.replace(/$tmpname/g, 'myCustomName');
vm.run(modifiedCode);
[ CVE-2023-29017 ] vm2 3.9.4

Description:
vm2 is an open-source Node.js package that can be used for sandboxing untrusted code and creating isolated testing and development environments.
However, a sandbox escape was discovered where untrusted code running inside the sandbox can escape and run arbitrary code on the host machine, even in the sandbox's default configuration.

Specifically, the frames object is an array in the new Node.js versions for handling async errors and can be accessed through the Error.prepareStackTrace object. This object wasn't converted to a sandbox object and could potentially allow access to the host object.

Example of running untrusted code in the sandbox -

const { VM } = require('vm2');
new VM().run(untrusted_code);
[ CVE-2022-25893 ] vm2 3.9.4

Description:
[vm2][https://www.npmjs.com/package/vm2] is an open-source Node.js package that can be used for sandboxing untrusted code and creating isolated testing and development environments.

The vm2 package provides a secure virtual environment for running untrusted code, which cannot be escaped to the host machine.
However, a sandbox escape was discovered where untrusted code running inside the sandbox can escape and run arbitrary code on the host machine, even in the sandbox's default configuration.

Specifically, the WeakMap object can be accessed through the WeakMap.prototype.set method, allowing for the assignment of a {value: value} pair instead of a {key: value} using the global object.prototype.set method which is later assigned into the wrappedPrepareStack object. This can potentially allow access to the host object via the Error.prepareStackTrace object.

Vulnerable code snippet -

const { VM } = require('vm2');
new VM().run(untrusted_code);

Remediation:

Development mitigations

Prefix the untrusted code with Object.freeze(WeakMap.prototype) to prevent the prototype lookup -

new VM().run(
Object.freeze(WeakMap.prototype);

// Untrusted code here...
}

[ CVE-2022-36067 ] vm2 3.9.4

Description:
vm2 is a sandbox that can run untrusted code with whitelisted Node's built-in modules. The sandbox is used for running untrusted code while not allowing the code to perform actions that will compromise the host machine, such as running arbitrary shell commands.

It was discovered that due to insecure error handling, an attacker could create code that runs inside the sandbox but eventually creates an object outside of the sandbox that would be subsequently executed. This allows the attacker to perform malicious operations such as execution arbitrary shell commands using the child_process module. Since the Sandbox by design is meant to run untrusted code, it is highly likely that this vulnerability can be exploited on every application that uses vm2.

The vulnerability has an extensive technical writeup, making the creation of a PoC trivial.

Example of running untrusted code in the sandbox -

const {VM} = require('vm2');
new VM().run(attacker_javascript_code_as_string);

Remediation:

Development mitigations

Define the global Error object before executing untrusted code in the sandbox -

const {VM} = require('vm2');
const vm2 = new VM();

// Define the Error object
vm2.sandbox.Error = Error;

// Now we can execute untrusted code
new VM().run(attacker_javascript_code_as_string);
[ CVE-2024-45590 ] body-parser 1.20.1

Description:
body-parser is Node.js body parsing middleware. body-parser <1.20.3 is vulnerable to denial of service when url encoding is enabled. A malicious actor using a specially crafted payload could flood the server with a large number of requests, resulting in denial of service. This issue is patched in 1.20.3.

Remediation:

Development mitigations

The vulnerability can be mitigated by specifying extended = false when initializing the URL-encoded parser.

[ CVE-2022-25878 ] protobufjs 6.11.2

Description:
Protocol Buffers or "protobufs" are a language-neutral, platform-neutral, extensible way of serializing structured data. protobuf.js is a JavaScript library that allows creating and consuming protobufs.
Multiple prototype pollution vulnerabilities were detected in the protobuf.js library. Namely these can occur when:

  1. util.setProperty receives untrusted input in arguments 2 & 3 -
protobuf.util.setProperty({}, "__proto__.someprop", "somevalue");
  1. ReflectionObject.setParsedOption receives untrusted input in arguments 2 & 3
let obj = new protobuf.ReflectionObject("Test")
obj.setParsedOption({}, "somevalue", "__proto__.someprop");
  1. parse receives untrusted input (an untrusted .proto definition) -
let p = `option (foo).__proto__.someprop= "somevalue";` 
protobuf.parse(p)
  1. load receives an untrusted .proto file -
protobuf.load("/path/to/untrusted.proto", function(err, root) { ... });

Remediation:

Development mitigations

Add the Object.freeze(Object.prototype); directive once at the beginning of your main JS source code file (ex. index.js), preferably after all your require directives. This will prevent any changes to the prototype object, thus completely negating prototype pollution attacks.

[ CVE-2021-23337 ] lodash 4.17.0

Description:
JavaScript-based applications (both frontend and backend) that use the template function -_.template([string=''], [options={}]) from the lodash utility library and provide the options argument (specifically the variable option) from untrusted user input, are vulnerable to JavaScript code injection. This issue can be easily exploited, and an exploitation example is publicly available in the fix tests that was introduced in version 4.17.21 -

lodash.template('', { variable: '){console.log(process.env)}; with(obj' })()
[ CVE-2020-8203 ] lodash 4.17.0

Description:
lodash is a JavaScript library which provides utility functions for common programming tasks.

JavaScript frontend and Node.js-based backend applications that merge or zip objects using the lodash functions mergeWith, merge and zipObjectDeep are vulnerable to prototype pollution if one or more of the objects it receives as arguments are obtained from user input.
An attacker controlling this input given to the vulnerable functions can inject properties to JavaScript special objects such as Object.prototype from which all JavaScript objects inherit properties and methods. Any change on Object.prototype properties will then propagate through the prototype chain inheritance to all of the objects in a JavaScript application. This in turn would allow an attacker to add new properties or modify existing properties which will have application specific implications that could lead to DoS (denial of service), authentication bypass, privilege escalation and even RCE (remote code execution) in some cases.
As an example for privilege escalation, consider a JavaScript application that has a user object which has a Boolean property of user.isAdmin which is used to decide which actions the user may take. If an attacker can modify or add the isAdmin property through prototype pollution, it can escalate the privileges of its own user to those of an admin.
As exploitation is usually application specific, successful exploitation is much more likely if an attacker have access to the JavaScript application code. As such, frontend applications are more vulnerable to this vulnerability than Node.js backend applications.

Remediation:

Deployment mitigations

As general guidelines against prototype pollution, first consider not merging objects originating from user input or using a Map structure instead of an object. If merging objects is needed, look into creating objects without a prototype with Object.create(null) or into freezing Object.prototype with Object.freeze(). Finally, it is always best to perform input validation with a a JSON schema validator, which could mitigate this issue entirely in many cases.


@github-actions
Copy link
Copy Markdown

github-actions bot commented Nov 1, 2024

access_key

at main.tf (line 18)

🛠️ Infrastructure as Code Vulnerability

Severity Finding

High
Hardcoded access keys found for AWS Provider
Full description

Provider aws should never set access_key or secret_key.
Instead of setting these keys, AWS provider credentials can be provided by -

  1. Environment variables
  2. Shared credentials files
  3. Shared configuration files
  4. Container credentials
  5. Instance profile credentials and region

See Terraform's Authentication and Configuration for more details

Vulnerable example -

provider "aws" {
    region     = "us-west-2"
    access_key = "my-access-key"
    secret_key = "my-secret-key"
}

Secure example #1 -

provider "aws" {
  shared_config_files      = ["/Users/tf_user/.aws/conf"]
  shared_credentials_files = ["/Users/tf_user/.aws/creds"]
  profile                  = "customprofile"
}

(using configuration files)

Secure example #2 -

$ export AWS_ACCESS_KEY_ID="my-access-key"
$ export AWS_SECRET_ACCESS_KEY="my-secret-key"
$ export AWS_REGION="us-west-2"
$ terraform plan

(using environment variables)


@github-actions
Copy link
Copy Markdown

github-actions bot commented Nov 1, 2024

secret_key

at main.tf (line 19)

🛠️ Infrastructure as Code Vulnerability

Severity Finding

High
Hardcoded access keys found for AWS Provider
Full description

Provider aws should never set access_key or secret_key.
Instead of setting these keys, AWS provider credentials can be provided by -

  1. Environment variables
  2. Shared credentials files
  3. Shared configuration files
  4. Container credentials
  5. Instance profile credentials and region

See Terraform's Authentication and Configuration for more details

Vulnerable example -

provider "aws" {
    region     = "us-west-2"
    access_key = "my-access-key"
    secret_key = "my-secret-key"
}

Secure example #1 -

provider "aws" {
  shared_config_files      = ["/Users/tf_user/.aws/conf"]
  shared_credentials_files = ["/Users/tf_user/.aws/creds"]
  profile                  = "customprofile"
}

(using configuration files)

Secure example #2 -

$ export AWS_ACCESS_KEY_ID="my-access-key"
$ export AWS_SECRET_ACCESS_KEY="my-secret-key"
$ export AWS_REGION="us-west-2"
$ terraform plan

(using environment variables)


@github-actions
Copy link
Copy Markdown

github-actions bot commented Nov 1, 2024

test

at main.tf (line 23)

🛠️ Infrastructure as Code Vulnerability

Severity Finding

High
AWS EC2 instance is publicly accessible
Full description

Resource aws_instance should not have associate_public_ip_address=true

Vulnerable example -

resource "aws_instance" "vulnerable_example" {
  associate_public_ip_address = true
}

Secure example -

resource "aws_instance" "secure_example" {
  # associate_public_ip_address is not set
}

@github-actions
Copy link
Copy Markdown

github-actions bot commented Nov 1, 2024

b

at main.tf (line 54)

🛠️ Infrastructure as Code Vulnerability

Severity Finding

High
block_public_acls=false was detected
Full description

If resource aws_s3_bucket exists, then resource aws_s3_bucket_public_access_block must also exist and have block_public_acls=true

Vulnerable example -

resource "aws_s3_bucket" "example_bucket" {
  bucket = "mybucket"
}

resource "aws_s3_bucket_public_access_block" "vulnerable_example" {
  bucket = aws_s3_bucket.example_bucket.id
  # block_public_acls is not set
}

Secure example -

resource "aws_s3_bucket" "example_bucket" {
  bucket = "mybucket"
}

resource "aws_s3_bucket_public_access_block" "secure_example" {
  bucket = aws_s3_bucket.example_bucket.id
  block_public_acls = true
}

1 similar comment
@github-actions
Copy link
Copy Markdown

github-actions bot commented Nov 1, 2024

b

at main.tf (line 54)

🛠️ Infrastructure as Code Vulnerability

Severity Finding

High
block_public_acls=false was detected
Full description

If resource aws_s3_bucket exists, then resource aws_s3_bucket_public_access_block must also exist and have block_public_acls=true

Vulnerable example -

resource "aws_s3_bucket" "example_bucket" {
  bucket = "mybucket"
}

resource "aws_s3_bucket_public_access_block" "vulnerable_example" {
  bucket = aws_s3_bucket.example_bucket.id
  # block_public_acls is not set
}

Secure example -

resource "aws_s3_bucket" "example_bucket" {
  bucket = "mybucket"
}

resource "aws_s3_bucket_public_access_block" "secure_example" {
  bucket = aws_s3_bucket.example_bucket.id
  block_public_acls = true
}

@github-actions
Copy link
Copy Markdown

github-actions bot commented Nov 1, 2024

req.query

at server.js (line 20)

🎯 Static Application Security Testing (SAST) Vulnerability

Severity Finding

High
Untrusted input is used as a response template
Full description

Overview

Template Object Injection (TOI) is a vulnerability that can occur in
web applications that use template engines to render dynamic content.
Template engines are commonly used to generate HTML pages, emails, or
other types of documents that include variable data. TOI happens when
untrusted user input is included as part of the template rendering
process, and the template engine evaluates the input as a code
expression, leading to potential code injection or data tampering
attacks. To prevent TOI vulnerabilities, it's important to sanitize and
validate all user input that is used as part of the template rendering
process.

Query operation

In this query we look for user inputs that flow directly to a
request render.

Vulnerable example

var app = require('express')();
app.set('view engine', 'hbs');

app.use(require('body-parser').json());
app.use(require('body-parser').urlencoded({ extended: false }));
app.post('/path', function(req, res) {
    var bodyParameter = req.body.bodyParameter;
    var queryParameter = req.query.queryParameter;
    res.render('template', bodyParameter);
});

In this example, a user-provided data is injected directly into the
render command, leading to potential code injection or data
tampering attacks.

Remediation

+   const sanitizeHtml = require('sanitize-html');
var app = require('express')();
app.set('view engine', 'hbs');
app.use(require('body-parser').json());
app.use(require('body-parser').urlencoded({ extended: false }));
app.post('/path', function(req, res) {
    var bodyParameter = req.body.bodyParameter;
    var queryParameter = req.query.queryParameter;

-       res.render('template', bodyParameter);
+       res.render('template', sanitizeHtml(bodyParameter));
});
Using `sanitize-html`, the user-provided data is sanitized, before
rendering to the response.
Code Flows
Vulnerable data flow analysis result

↘️ req (at server.js line 16)

↘️ req (at server.js line 20)

↘️ req.query (at server.js line 20)


Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant