create insecure-api

[confusedcrib]

No description provided.

[dryrunsecurity]

DryRun Security Summary

The changes in this GitHub Pull Request introduce a range of updates to an intentionally insecure API application, including vulnerabilities such as broken object-level authorization, broken authentication, excessive data exposure, security misconfiguration, lack of rate limiting, mass assignment, SQL injection, and improper asset management, which are designed for educational purposes to demonstrate various API security vulnerabilities outlined in the OWASP API Security Top 10.

Expand for full summary

Summary:

The changes in this GitHub Pull Request cover a range of updates to an intentionally insecure API application, as well as changes to the associated Docker image and configuration files. The key points from an application security perspective are:

1. The "insecure-api" Docker image and associated code appear to be designed for educational purposes, demonstrating various API security vulnerabilities outlined in the OWASP API Security Top 10.
2. The code changes introduce vulnerabilities such as broken object-level authorization, broken authentication, excessive data exposure, security misconfiguration, lack of rate limiting, mass assignment, SQL injection, and improper asset management.
3. The changes also include updates to the application's dependencies, the GitHub Actions workflow for building and publishing the Docker image, and the Helm chart configuration for deploying the "insecure-api" application.
4. While the purpose of this application is to be intentionally insecure for educational purposes, it's crucial to ensure that the vulnerabilities are properly contained and that the application is not accidentally deployed in a production environment.

Overall, the changes in this Pull Request are focused on maintaining an intentionally insecure API application for educational and demonstration purposes. As an application security engineer, it's important to review these changes carefully to understand the security implications and ensure that the application is not deployed in a way that could compromise the security of the overall system.

Files Changed:

• insecure-api/Dockerfile: The Dockerfile sets up the Python-based FastAPI application, using a lightweight base image and installing the required dependencies.
• insecure-api/README: This file provides an overview of the intentionally insecure API and the various vulnerabilities it demonstrates, including broken object-level authorization, broken authentication, excessive data exposure, security misconfiguration, lack of rate limiting, mass assignment, SQL injection, and improper asset management.
• insecure-api/database.py: This file contains a simulated database for video games, with hardcoded user credentials and a lack of input validation, which could lead to security issues.
• .github/workflows/publish-insecure.yml: This GitHub Actions workflow is responsible for building and pushing the "insecure-api" Docker image, which raises security concerns and should be thoroughly reviewed.
• insecure-api/requirements.txt: The changes update the dependencies for the FastAPI application, which should be monitored for any security-related updates.
• insecure-chart/values.yaml: The changes introduce a new "insecureApi" section, which configures the deployment of the "insecure-api" application, including exposing an unnecessary port and using a potentially outdated or vulnerable Docker image.
• insecure-api/models.py: The changes introduce new Pydantic models for VideoGame and User, which should be reviewed for potential security issues, such as sensitive data exposure and privilege escalation.
• insecure-api/main.py: This file contains the FastAPI application code, which includes several vulnerabilities, such as broken object-level authorization, broken authentication, excessive data exposure, lack of rate limiting, broken function-level authorization, mass assignment, injection, improper asset management, and insufficient logging and monitoring.
• insecure-java/README.md: The changes in this file focus on reorganizing the order of the vulnerability descriptions and removing certain sections, such as XML External Entities (XXE), Insecure Deserialization, and Insufficient Logging & Monitoring.

Code Analysis

We ran 9 analyzers against 12 files and 2 analyzers had findings. 7 analyzers had no findings.

Analyzer	Findings
Sensitive Files Analyzer	2 findings
Authn/Authz Analyzer	1 finding

View PR in the DryRun Dashboard.

[socket-security]

New dependencies detected. Learn more about Socket for GitHub ↗︎

Package	New capabilities	Transitives	Size	Publisher
pypi/[email protected]	environment, filesystem, network, shell	0	3.93 MB	tiangolo
pypi/[email protected]	environment, filesystem, network, shell Transitive: eval, unsafe	+13	6.61 MB	Kludex, tomchristie

View full report↗︎

[jit-ci]

❌ Jit has detected 2 important findings in this PR that you should review.
The findings are detailed below as separate comments.
It’s highly recommended that you fix these security issues before merge.

[jit-ci]

Security control: Static Code Analysis Python Semgrep

Type: Sqlalchemy Raw Sql Query Concatenation Risks Sql Injection

Description: Avoiding SQL string concatenation: untrusted input concatenated with raw SQL query can result in SQL Injection. In order to execute raw query safely, prepared statement should be used. SQLAlchemy provides TextualSQL to easily used prepared statement with named parameters. For complex SQL composition, use SQL Expression Language or Schema Definition Language. In most cases, SQLAlchemy ORM will be a better option.

Severity: HIGH

Learn more about this issue

---

Jit Bot commands and options (e.g., ignore issue)

You can trigger Jit actions by commenting on this PR review:

• #jit_ignore_fp Ignore and mark this specific single instance of finding as “False Positive”
• #jit_ignore_accept Ignore and mark this specific single instance of finding as “Accept Risk”
• #jit_ignore_type_in_file Ignore any finding of type "SQLAlchemy raw SQL query concatenation risks SQL Injection" in insecure-api/main.py; future occurrences will also be ignored.
• #jit_undo_ignore Undo ignore command

[jit-ci]

Security control: Docker Scan

Type: Image User Should Not Be 'Root'

Description: Running containers with 'root' user can lead to a container escape situation. It is a best practice to run containers as non-root users, which can be done by adding a 'USER' statement to the Dockerfile.

Severity: HIGH

Learn more about this issue

---

Fix suggestion:

This fix suggestion was generated by Jit. Please note that the suggestion might not always fit every use case. It is highly recommended that you check and review it before merging.

Suggestion guidelines

• First of all, check if your container is running as a root user. In most of the cases, you can do it by running a command like this: docker run <image> whoami. If it returns root, then you should consider using a non-root user, by following one of the next steps:
  • If a non-root user already exists in your container, consider using it.
  • If not, you can create a new user by adding a USER command to the Dockerfile, with a non-root user as argument, for example: USER <non-root-user-name>.

Suggested change

	FROM python:3.9-slim
	FROM python:3.9-slim
	RUN addgroup --system <group>
	RUN adduser --system <user> --ingroup <group>
	USER <user>:<group>

---

Jit Bot commands and options (e.g., ignore issue)

You can trigger Jit actions by commenting on this PR review:

• #jit_ignore_fp Ignore and mark this specific single instance of finding as “False Positive”
• #jit_ignore_accept Ignore and mark this specific single instance of finding as “Accept Risk”
• #jit_ignore_type_in_file Ignore any finding of type "Image user should not be 'root'" in insecure-api/Dockerfile; future occurrences will also be ignored.
• #jit_undo_ignore Undo ignore command