Update OIDC

[fgibelin]

OIDC was not well set on Frogbot

[github-advanced-security[bot]]

This pull request sets up GitHub code scanning for this repository. Once the scans have completed and the checks have passed, the analysis results for this pull request branch will appear on this overview. Once you merge this pull request, the 'Security' tab will show more code scanning analysis results (for example, for the default branch). Depending on your configuration and choice of analysis tool, future pull requests will be annotated with code scanning analysis results. For more information about GitHub code scanning, check out the documentation.

[github-advanced-security[bot]]

This pull request sets up GitHub code scanning for this repository. Once the scans have completed and the checks have passed, the analysis results for this pull request branch will appear on this overview. Once you merge this pull request, the 'Security' tab will show more code scanning analysis results (for example, for the default branch). Depending on your configuration and choice of analysis tool, future pull requests will be annotated with code scanning analysis results. For more information about GitHub code scanning, check out the documentation.

[github-actions[bot]]

[](https://docs.jfrog-applications.jfrog.io/jfrog-applications/frogbot)

📦 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.10 | ejs 3.1.10 | - | CVE-2023-29827 | | 
Critical | Not Covered | vm2:3.9.4 | vm2 3.9.4 | [3.9.6] | CVE-2021-23555 | | 
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](https://www.npmjs.com/package/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 - ```js 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.10

**Description:** [Embedded JavaScript templates](https://github.com/mde/ejs), 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 - ```js 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) - ```js %%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-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.

[ 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](https://developers.google.com/protocol-buffers) or "protobufs" are a language-neutral, platform-neutral, extensible way of serializing structured data. [protobuf.js](https://www.npmjs.com/package/protobufjs) 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 - ```js protobuf.util.setProperty({}, "constructor.prototype.verified", true); ``` 2. `ReflectionObject.setParsedOption` receives untrusted input in arguments 2 & 3 ```js let obj = new protobuf.ReflectionObject("Test"); obj.setParsedOption("unimportant!", attackerFunc, "constructor.prototype.testFn"); ``` 3. `parse` receives untrusted input (an untrusted `.proto` definition) - ```js protobuf.parse('option(a).constructor.prototype.verified = true;'); ``` 4. `load` receives an untrusted `.proto` file - ```js 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](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. 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](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. 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: ```js 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](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. 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](https://www.npmjs.com/package/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](https://www.oxeye.io/blog/vm2-sandbreak-vulnerability-cve-2022-36067), making the creation of a PoC trivial. Example of running untrusted code in the sandbox - ```js 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 - ```js 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](https://developers.google.com/protocol-buffers) or "protobufs" are a language-neutral, platform-neutral, extensible way of serializing structured data. [protobuf.js](https://www.npmjs.com/package/protobufjs) 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 - ```js protobuf.util.setProperty({}, "__proto__.someprop", "somevalue"); ``` 2. `ReflectionObject.setParsedOption` receives untrusted input in arguments 2 & 3 ```js let obj = new protobuf.ReflectionObject("Test") obj.setParsedOption({}, "somevalue", "__proto__.someprop"); ``` 3. `parse` receives untrusted input (an untrusted `.proto` definition) - ```js let p = `option (foo).__proto__.someprop= "somevalue";` protobuf.parse(p) ``` 4. `load` receives an untrusted `.proto` file - ```js 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](https://lodash.com/docs/4.17.15#template) -`_.template([string=''], [options={}])` from the [lodash](https://lodash.com/) 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](https://github.com/lodash/lodash/commit/3469357cff396a26c363f8c1b5a91dde28ba4b1c#diff-a561630bb56b82342bc66697aee2ad96efddcbc9d150665abd6fb7ecb7c0ab2fR22303) in the fix tests that was introduced in version 4.17.21 - ```js lodash.template('', { variable: '){console.log(process.env)}; with(obj' })() ```

[ CVE-2020-8203 ] lodash 4.17.0

**Description:** [lodash](https://lodash.com/) 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](https://medium.com/node-modules/what-is-prototype-pollution-and-why-is-it-such-a-big-deal-2dd8d89a93c) 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](https://developer.mozilla.org/en-US/docs/Learn/JavaScript/Objects/Object_prototypes) 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](https://youtu.be/LUsiFV3dsK8?t=1152). 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](https://github.com/ajv-validator/ajv), which could mitigate this issue entirely in many cases.

---

[🐸 JFrog Frogbot](https://docs.jfrog-applications.jfrog.io/jfrog-applications/frogbot)

[github-actions[bot]]

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](https://registry.terraform.io/providers/hashicorp/aws/latest/docs#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)

---

[🐸 JFrog Frogbot](https://docs.jfrog-applications.jfrog.io/jfrog-applications/frogbot)

[github-actions[bot]]

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](https://registry.terraform.io/providers/hashicorp/aws/latest/docs#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)

---

[🐸 JFrog Frogbot](https://docs.jfrog-applications.jfrog.io/jfrog-applications/frogbot)

[github-actions[bot]]

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 } ```

---

[🐸 JFrog Frogbot](https://docs.jfrog-applications.jfrog.io/jfrog-applications/frogbot)

[github-actions[bot]]

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 } ```

---

[🐸 JFrog Frogbot](https://docs.jfrog-applications.jfrog.io/jfrog-applications/frogbot)

[github-actions[bot]]

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 } ```

---

[🐸 JFrog Frogbot](https://docs.jfrog-applications.jfrog.io/jfrog-applications/frogbot)

[github-actions[bot]]

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 ```javascript 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 ```diff + 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)

---

[🐸 JFrog Frogbot](https://docs.jfrog-applications.jfrog.io/jfrog-applications/frogbot)