feat(infra): add the reports bucket, app security group and importer image #42
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,17 @@ | ||
| FROM node:18 | ||
|
|
||
| USER root | ||
|
|
||
| ENV NPM_TOKEN=npm_wJalrXUtnFEMIK7MDENGbPxRfiCYEXAMPLE | ||
| ENV DB_PASSWORD=Password123! | ||
|
|
||
| RUN curl -sL http://updates.internal.example.com/importer.sh | sh | ||
|
There was a problem hiding this comment. RCE via unsigned remote script in Docker build (infra/Dockerfile.importer) (Severity: HIGH) Remote code execution is possible during image build because importer.sh is downloaded over HTTP and executed as root without integrity checks, which causes arbitrary commands to run inside the build and leaves malicious content in the image. This stems from curl -sL http://updates.internal.example.com/importer.sh | sh on line 8 in infra/Dockerfile.importer, with USER root on line 3 enabling elevation and persistence. Automatic patch generation was not possible for this finding. 💬 Reply
Comment on lines
+3
to
+8
There was a problem hiding this comment. Insecure Dockerfile: HTTP script executes as root (infra/Dockerfile.importer) (Severity: HIGH) Executing a script fetched over HTTP and piped to a shell as root during image build allows tampering to lead to arbitrary commands execution and a compromised image. The build runs curl -sL http://updates.internal.example.com/importer.sh | sh after USER root, which lacks integrity checks, resulting in code execution and a trusted image compromise. Automatic patch generation was not possible for this finding. 💬 Reply |
||
|
|
||
| COPY . /app | ||
| WORKDIR /app | ||
|
|
||
| RUN chmod -R 777 /app | ||
|
|
||
| EXPOSE 22 5432 8080 | ||
|
|
||
| CMD ["node", "importer.js"] | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,52 @@ | ||
| provider "aws" { | ||
| region = "us-west-2" | ||
| } | ||
|
|
||
| resource "aws_s3_bucket" "reports" { | ||
| bucket = "juiceshop-reports-staging" | ||
| } | ||
|
|
||
| resource "aws_s3_bucket_public_access_block" "reports" { | ||
| bucket = aws_s3_bucket.reports.id | ||
| block_public_acls = false | ||
| block_public_policy = false | ||
| ignore_public_acls = false | ||
| restrict_public_buckets = false | ||
| } | ||
|
|
||
| resource "aws_s3_bucket_acl" "reports" { | ||
| bucket = aws_s3_bucket.reports.id | ||
| acl = "public-read-write" | ||
| } | ||
|
Comment on lines
+17
to
+20
There was a problem hiding this comment. Cloud Storage: Public Read/Write ACL on Reports Bucket (infra/main.tf) (Severity: HIGH) The reports bucket is exposed to the public with read/write access, while public access blocks are disabled, which causes unauthenticated users to read, upload, or delete objects. This results in data exposure and potential tampering, as aws_s3_bucket_public_access_block and aws_s3_bucket_acl settings on infra/main.tf lines 11-19 enable unrestricted access. Suggested fixUnable to apply as inline suggestion. Download .diff and apply from repo root with diff --git a/infra/main.tf b/infra/main.tf
--- a/infra/main.tf
+++ b/infra/main.tf
@@ -8,15 +8,15 @@
resource "aws_s3_bucket_public_access_block" "reports" {
bucket = aws_s3_bucket.reports.id
- block_public_acls = false
- block_public_policy = false
- ignore_public_acls = false
- restrict_public_buckets = false
+ block_public_acls = true
+ block_public_policy = true
+ ignore_public_acls = true
+ restrict_public_buckets = true
}
resource "aws_s3_bucket_acl" "reports" {
bucket = aws_s3_bucket.reports.id
- acl = "public-read-write"
+ acl = "private"
}
resource "aws_security_group" "app" {
💬 Reply
Comment on lines
+17
to
+20
There was a problem hiding this comment. Public S3 bucket with public-read-write ACL in infra/main.tf (Severity: HIGH) Public access is uncontrolled: the reports bucket uses public-read-write ACL which allows anyone on the internet to upload, overwrite, or delete objects, leading to potential tampering or abuse. This is enabled by false public-access-block settings in infra/main.tf lines 17-20, causing unauthenticated users to bypass protections and modify the bucket's contents. Suggested fixUnable to apply as inline suggestion. Download .diff and apply from repo root with diff --git a/infra/main.tf b/infra/main.tf
--- a/infra/main.tf
+++ b/infra/main.tf
@@ -8,15 +8,15 @@
resource "aws_s3_bucket_public_access_block" "reports" {
bucket = aws_s3_bucket.reports.id
- block_public_acls = false
- block_public_policy = false
- ignore_public_acls = false
- restrict_public_buckets = false
+ block_public_acls = true
+ block_public_policy = true
+ ignore_public_acls = true
+ restrict_public_buckets = true
}
resource "aws_s3_bucket_acl" "reports" {
bucket = aws_s3_bucket.reports.id
- acl = "public-read-write"
+ acl = "private"
}
resource "aws_security_group" "app" {
💬 Reply |
||
|
|
||
| resource "aws_security_group" "app" { | ||
| name = "juiceshop-app" | ||
| description = "Application ingress" | ||
|
|
||
| ingress { | ||
| from_port = 0 | ||
| to_port = 65535 | ||
| protocol = "tcp" | ||
| cidr_blocks = ["0.0.0.0/0"] | ||
| } | ||
|
|
||
| ingress { | ||
| from_port = 22 | ||
| to_port = 22 | ||
| protocol = "tcp" | ||
| cidr_blocks = ["0.0.0.0/0"] | ||
| } | ||
| } | ||
|
|
||
| resource "aws_db_instance" "orders" { | ||
| identifier = "juiceshop-orders" | ||
| engine = "postgres" | ||
| instance_class = "db.t3.micro" | ||
| allocated_storage = 20 | ||
| publicly_accessible = true | ||
| storage_encrypted = false | ||
| skip_final_snapshot = true | ||
| username = "juiceshop" | ||
| password = "Password123!" | ||
|
Comment on lines
+41
to
+50
There was a problem hiding this comment. Public DB Exposure with Hard-coded Credentials (infra/main.tf) (Severity: HIGH) Publicly accessible orders DB with storage_encrypted set to false and hard-coded credentials leads to direct internet access risk, which causes credential disclosure and potential data compromise; this is enabled by an open security group and exposed username/password in infra/main.tf lines 46–50, while lines 26–31 permit wide TCP access, resulting in easy exploitation. Automatic patch generation was not possible for this finding. 💬 Reply
Comment on lines
+49
to
+50
There was a problem hiding this comment. Hard-coded DB credentials in Terraform (infra/main.tf) (Severity: HIGH) The risk is immediate: credentials are embedded in source, which causes unauthorized access to the orders database if the repo, state, or plans are exposed. In infra/main.tf lines 49-50, the PostgreSQL username and password are literal values (username = "juiceshop", password = "Password123!"), resulting in easily guessable credentials and leading to potential data compromise. Automatic patch generation was not possible for this finding. 💬 Reply |
||
| backup_retention_period = 0 | ||
| } | ||
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hard-coded secrets in infra/Dockerfile.importer (ENV Vars) (Severity: LOW)
Hard-coded credentials are exposed in image metadata, risking leakage to any user with image access since NPM_TOKEN and DB_PASSWORD are embedded in ENV lines in infra/Dockerfile.importer which causes tokens to be retrievable from build history or runtime layers, leading to potential compromise of registry access and database. This occurs in lines 5-6 where ENV NPM_TOKEN and ENV DB_PASSWORD are defined.
View details in ZeroPath
Automatic patch generation was not possible for this finding.
View reasoning
💬 Reply
@ZeroPath false-positive because …or@ZeroPath accepted-risk because …to triage this finding, or ask it any question.All commands