text:
test PR

📦 Vulnerable Dependencies
✍ Summary

SEVERITY
CONTEXTUAL ANALYSIS
DIRECT DEPENDENCIES
IMPACTED DEPENDENCY
FIXED VERSIONS
CVES

    High
Undetermined
pip:21.2.3
pip 21.2.3
-
CVE-2018-20225

     Low
Undetermined
pip:21.2.3
pip 21.2.3
[23.3]
CVE-2023-5752

    High
Not Applicable
flask:1.1.2
flask 1.1.2
[2.2.5][2.3.2]
CVE-2023-30861

  Medium
Not Applicable
setuptools:57.4.0
setuptools 57.4.0
[65.5.1]
CVE-2022-40897

Critical
Applicable
werkzeug:1.0.1
werkzeug 1.0.1
[2.1.1]
CVE-2022-29361

    High
Undetermined
pip:21.2.3
pip 21.2.3
-
CVE-2018-20225

    High
Undetermined
werkzeug:1.0.1
werkzeug 1.0.1
[2.3.8][3.0.1]
CVE-2023-46136

  Medium
Undetermined
jinja2:2.11.3
jinja2 2.11.3
[3.1.3]
CVE-2024-22195

     Low
Undetermined
werkzeug:1.0.1
werkzeug 1.0.1
[2.2.3]
CVE-2023-23934

     Low
Undetermined
pip:21.2.3
pip 21.2.3
[23.3]
CVE-2023-5752

    High
Not Applicable
werkzeug:1.0.1
werkzeug 1.0.1
[2.2.3]
CVE-2023-25577

  Medium
Not Applicable
setuptools:57.4.0
setuptools 57.4.0
[65.5.1]
CVE-2022-40897

 🔬 Research Details

 [ CVE-2018-20225 ] pip 21.2.3

Description:
This CVE refers to the possibility of a "dependency confusion" attack when using pip with the --extra-index-url flag. This vulnerability has been disputed by the maintainers of pip as the described behavior is intended (although potentially insecure) and as such there are no plans to fix it.
If pip is executed with the --extra-index-url when using a private PyPI repository, an attacker could cause pip to download a private package (for example one named private_package) by adding a package with the same name (private_package) in the public PyPI repository. This would lead to remote code execution as pip will download the public package that could contain malicious code. This dependency confusion attack was demonstrated in 2021 by Alex Birsan.
Remediation:
Deployment mitigations
Do not use the --extra-index-url flag with pip and consider using version pinning for deployments.

 [ CVE-2023-5752 ] pip 21.2.3

Description:
When installing a package from a Mercurial VCS URL  (ie "pip install
hg+...") with pip prior to v23.3, the specified Mercurial revision could
be used to inject arbitrary configuration options to the "hg clone"
call (ie "--config"). Controlling the Mercurial configuration can modify
how and which repository is installed. This vulnerability does not
affect users who aren't installing from Mercurial.

 [ CVE-2023-30861 ] flask 1.1.2

Description:
Flask is a lightweight web framework for Python used for building web applications.
An issue arises when using a caching proxy that caches cookies (specifically, the Set-Cookie headers) from responses intended for clients. This situation can result in the proxy sending one client's session cookies to other clients, leading to data leakage or even privilege escalation.
The root cause of this issue is the absence of the Vary: Cookie header, which informs the proxy not to cache session cookies when the session is refreshed (i.e., resent to update the expiration) without being accessed or modified. The Vary: Cookie header is typically set when the session is accessed or modified.
To exploit this vulnerability, several specific conditions must be met:

The application must be hosted behind a proxy that caches responses along with their cookies.
The application must have the session.permanent attribute set to True.
The session must not be accessed or modified before the request is made.
The SESSION_REFRESH_EACH_REQUEST feature must be enabled (which is the default behavior).
The application should not set a Cache-Control header to indicate that a page is private and should not be cached.

Example of vulnerable code:
from flask import Flask, session

app = Flask(__name__)
app.secret_key = 'your_secret_key'

@app.route('/')
def index():
    session.permanent = True
    # Other code logic...
    return privateData(user)

In this example, a Flask application is used, and the session.permanent attribute is set to True. If this application is deployed behind a caching proxy without proper handling of session cookies and caching directives, the issue may be present.
Remediation:
Development mitigations
Add a Cache-Control in all requests/responses sent by the application explicitly instructing the caching proxy not to cache any content:
@app.after_request
def add_cache_control(response):
    response.headers['Cache-Control'] = 'no-store, no-cache, private, must-revalidate, max-age=0'
    return response

Development mitigations
Disable the SESSION_REFRESH_EACH_REQUEST setting of the Flask application:
app = Flask(__name__)
app.config['SESSION_REFRESH_EACH_REQUEST'] = False

 [ CVE-2022-40897 ] setuptools 57.4.0

Description:
Setuptools is a package for managing Python packages and dependencies, including tools for building and distributing packages, as well as for discovering and managing 3rd party packages available on PyPI.
The find_external_links function in the setuptools.package_index module is used to find external links that are associated with a package available on the Python Package Index (PyPI). These external links are typically URLs to the package's homepage, documentation, source code repository, and other resources that are related to the package.
The most common scenario of triggering this issue is when running pip with the --editable flag. This will cause the vulnerable find_external_links function to be invoked
Example of manual usage of find_external_links -
from setuptools.package_index import PackageIndex
import requests

# Specify the URL of the package page on PyPI
url = 'https://pypi.org/project/requests'

# Use the requests library to retrieve the HTML content of the package page
response = requests.get(url)

# Create an instance of the PackageIndex class
index = PackageIndex()

# Use the find_external_links function to find external links for the package
links = index.find_external_links(url, response.text)

# Print the name and URL of each external link
for link_name, link_url in links:
    print(f'{link_name}: {link_url}')

This example will find and print all external links for a package.
To find a specific url, i.e. the tag containing the rel= property, the find_external_links function uses a Regular Expression (regex). The regex is too not efficient which can lead to ReDoS on specific user inputs.
As a result, a user fetching malicious HTML from a package in PyPI or a custom PackageIndex page may be attacked.

 [ CVE-2022-29361 ] werkzeug 1.0.1

Description:
Improper parsing of HTTP requests in Pallets Werkzeug v2.1.0 and below allows attackers to perform HTTP Request Smuggling using a crafted HTTP request with multiple requests included inside the body. NOTE: the vendor's position is that this behavior can only occur in unsupported configurations involving development mode and an HTTP server from outside the Werkzeug project

 [ CVE-2018-20225 ] pip 21.2.3

Description:
This CVE refers to the possibility of a "dependency confusion" attack when using pip with the --extra-index-url flag. This vulnerability has been disputed by the maintainers of pip as the described behavior is intended (although potentially insecure) and as such there are no plans to fix it.
If pip is executed with the --extra-index-url when using a private PyPI repository, an attacker could cause pip to download a private package (for example one named private_package) by adding a package with the same name (private_package) in the public PyPI repository. This would lead to remote code execution as pip will download the public package that could contain malicious code. This dependency confusion attack was demonstrated in 2021 by Alex Birsan.
Remediation:
Deployment mitigations
Do not use the --extra-index-url flag with pip and consider using version pinning for deployments.

 [ CVE-2023-46136 ] werkzeug 1.0.1

Description:
Werkzeug is a comprehensive WSGI web application library. If an upload of a file that starts with CR or LF and then is followed by megabytes of data without these characters: all of these bytes are appended chunk by chunk into internal bytearray and lookup for boundary is performed on growing buffer. This allows an attacker to cause a denial of service by sending crafted multipart data to an endpoint that will parse it. The amount of CPU time required can block worker processes from handling legitimate requests. This vulnerability has been patched in version 3.0.1.

 [ CVE-2024-22195 ] jinja2 2.11.3

Description:
Jinja is an extensible templating engine. Special placeholders in the template allow writing code similar to Python syntax. It is possible to inject arbitrary HTML attributes into the rendered HTML template, potentially leading to Cross-Site Scripting (XSS). The Jinja xmlattr filter can be abused to inject arbitrary HTML attribute keys and values, bypassing the auto escaping mechanism and potentially leading to XSS. It may also be possible to bypass attribute validation checks if they are blacklist-based.

 [ CVE-2023-23934 ] werkzeug 1.0.1

Description:
Werkzeug is a comprehensive WSGI web application library. Browsers may allow "nameless" cookies that look like =value instead of key=value. A vulnerable browser may allow a compromised application on an adjacent subdomain to exploit this to set a cookie like =__Host-test=bad for another subdomain. Werkzeug prior to 2.2.3 will parse the cookie =__Host-test=bad as __Host-test=bad`. If a Werkzeug application is running next to a vulnerable or malicious subdomain which sets such a cookie using a vulnerable browser, the Werkzeug application will see the bad cookie value but the valid cookie key. The issue is fixed in Werkzeug 2.2.3.

 [ CVE-2023-5752 ] pip 21.2.3

Description:
When installing a package from a Mercurial VCS URL  (ie "pip install
hg+...") with pip prior to v23.3, the specified Mercurial revision could
be used to inject arbitrary configuration options to the "hg clone"
call (ie "--config"). Controlling the Mercurial configuration can modify
how and which repository is installed. This vulnerability does not
affect users who aren't installing from Mercurial.

 [ CVE-2023-25577 ] werkzeug 1.0.1

Description:
Werkzeug is a comprehensive WSGI web application library. Prior to version 2.2.3, Werkzeug's multipart form data parser will parse an unlimited number of parts, including file parts. Parts can be a small amount of bytes, but each requires CPU time to parse and may use more memory as Python data. If a request can be made to an endpoint that accesses request.data, request.form, request.files, or request.get_data(parse_form_data=False), it can cause unexpectedly high resource usage. This allows an attacker to cause a denial of service by sending crafted multipart data to an endpoint that will parse it. The amount of CPU time required can block worker processes from handling legitimate requests. The amount of RAM required can trigger an out of memory kill of the process. Unlimited file parts can use up memory and file handles. If many concurrent requests are sent continuously, this can exhaust or kill all available workers. Version 2.2.3 contains a patch for this issue.

 [ CVE-2022-40897 ] setuptools 57.4.0

Description:
Setuptools is a package for managing Python packages and dependencies, including tools for building and distributing packages, as well as for discovering and managing 3rd party packages available on PyPI.
The find_external_links function in the setuptools.package_index module is used to find external links that are associated with a package available on the Python Package Index (PyPI). These external links are typically URLs to the package's homepage, documentation, source code repository, and other resources that are related to the package.
The most common scenario of triggering this issue is when running pip with the --editable flag. This will cause the vulnerable find_external_links function to be invoked
Example of manual usage of find_external_links -
from setuptools.package_index import PackageIndex
import requests

# Specify the URL of the package page on PyPI
url = 'https://pypi.org/project/requests'

# Use the requests library to retrieve the HTML content of the package page
response = requests.get(url)

# Create an instance of the PackageIndex class
index = PackageIndex()

# Use the find_external_links function to find external links for the package
links = index.find_external_links(url, response.text)

# Print the name and URL of each external link
for link_name, link_url in links:
    print(f'{link_name}: {link_url}')

This example will find and print all external links for a package.
To find a specific url, i.e. the tag containing the rel= property, the find_external_links function uses a Regular Expression (regex). The regex is too not efficient which can lead to ReDoS on specific user inputs.
As a result, a user fetching malicious HTML from a package in PyPI or a custom PackageIndex page may be attacked.

🐸 JFrog Frogbot

Path(user_dir + "/" + filename)

at flask_webgoat/actions.py (line 33)
🎯 Static Application Security Testing (SAST) Vulnerability

Severity
Finding

    High
Path Traversal

 Full description

Overview
Path traversal, also known as directory traversal, is a type of vulnerability that allows an
attacker to access files or directories on a computer or device that are outside of
the intended directory.
Allowing arbitrary read access can allow the attacker to read sensitive files, such as
configuration files or sensitive data, potentially leading data loss
or even system compromise.
Allowing arbitrary write access is more severe and in most cases leads to arbitrary code
execution, via editing important system files or sensitive data.
Query operation
In this query we look for user input that can flow un-sanitized as a path into file access
functions
(either read or write access)
Vulnerable example
from flask import Flask, request, send_file
app = Flask(__name__)

@app.route('/files/')
def serve_file():
    filename = request.args.get('filename')
    basepath = 'static/files/'
    return send_file(basepath + filename)

if __name__ == '__main__':
    app.run()

In this example, the application has a route /files/ that serves files from a directory
called static/files. The vulnerability lies in the fact that the application does not
properly validate or sanitize the filename parameter, allowing an attacker to traverse
beyond the intended directory and access sensitive files on the server.
An attacker could exploit this vulnerability by manipulating the filename parameter
and providing a relative path to access files outside of the static/files directory.
For example, they could craft a URL like this:
http://localhost:5000/files/?filename=../../../etc/passwd
Remediation
When possible, use inherently safe path functions such as send_from_directory that perform
filename escaping -
@app.route('/files/')
def serve_file():
    filename = request.args.get('filename')
    basepath = 'static/files/'
-    return send_file(basepath + filename)
+    return send_from_directory(basepath, filename)

Alternatively, before accessing a potential path, check that the user's filename does not
escape the intended path -
from pathlib import Path
def is_escaping_path(basepath, userpath):
    try:
        Path(basepath).joinpath(userpath).resolve().relative_to(basepath.resolve())
        return False
    except ValueError:
        return True

@app.route('/files/')
def serve_file():
    filename = request.args.get('filename')
    basepath = 'static/files/'
+    if is_escaping_path(basepath, filename):
+         abort(400)  # Bad Request
    return send_file(basepath + filename)

 Code Flows

 Vulnerable data flow analysis result

↘ request.form (at flask_webgoat/actions.py line 19)
↘ request.form.get (at flask_webgoat/actions.py line 19)
↘ request.form.get("filename") (at flask_webgoat/actions.py line 19)
↘ filename_param (at flask_webgoat/actions.py line 19)
↘ filename_param + ".txt" (at flask_webgoat/actions.py line 32)
↘ filename (at flask_webgoat/actions.py line 32)
↘ user_dir + "/" + filename (at flask_webgoat/actions.py line 33)
↘ Path(user_dir + "/" + filename) (at flask_webgoat/actions.py line 33)

🐸 JFrog Frogbot

🐸 JFrog Frogbot

conn.cursor().execute(query, args)

at flask_webgoat/__init__.py (line 14)
🎯 Static Application Security Testing (SAST) Vulnerability

Severity
Finding

    High
SQL Injection

 Full description

Overview
SQL injection is a type of vulnerability that allows an attacker to execute arbitrary SQL
commands on a database.
This can allow the attacker to gain access to sensitive information,
such as user credentials or sensitive data, or to perform unauthorized actions,
such as deleting or modifying data.
Query operation
In this query we check if a user input can flow un-sanitized into an SQL query.
Vulnerable example
from flask import Flask, request
import sqlite3

app = Flask(__name__)

@app.route('/login', methods=['POST'])
def login():
    username = request.form.get('username')
    password = request.form.get('password')

    # Vulnerable SQL query
    query = f"SELECT * FROM users WHERE username = '{username}' AND password = '{password}'"

    # Execute the query
    conn = sqlite3.connect('database.db')
    cursor = conn.cursor()
    cursor.execute(query)
    user = cursor.fetchone()
    conn.close()

    if user:
        return 'Login successful'
    else:
        return 'Login failed'

if __name__ == '__main__':
    app.run()

In this example, the application accepts a username and password from a login form via a
POST request. The SQL query is constructed using string concatenation, which makes it
vulnerable to SQL injection attacks.
An attacker can exploit this vulnerability by entering ' OR 1=1 -- as the username.
The resulting query would become -
SELECT * FROM users WHERE username = '' OR 1=1 --' AND password = ''

which will always evaluate to TRUE, leading to an authentication bypass
since the attacker has no valid credentials.
Remediation
Replace the vulnerable string concatenation with a parameterized query
using ? placeholders -
@app.route('/login', methods=['POST'])
    def login():
    username = request.form.get('username')
    password = request.form.get('password')

    # Vulnerable SQL query
-   query = f"SELECT * FROM users WHERE username = '{username}' AND password = '{password}'"
+   query = "SELECT * FROM users WHERE username = ? AND password = ?"

    # Execute the query
    conn = sqlite3.connect('database.db')
    cursor = conn.cursor()
-    cursor.execute(query)
+    cursor.execute(query, (username, password))
    user = cursor.fetchone()
    conn.close()

    if user:
        return 'Login successful'
    else:
        return 'Login failed'

 Code Flows

 Vulnerable data flow analysis result

↘ request.form (at flask_webgoat/auth.py line 9)
↘ request.form.get (at flask_webgoat/auth.py line 9)
↘ request.form.get("username") (at flask_webgoat/auth.py line 9)
↘ username (at flask_webgoat/auth.py line 9)
↘ (username, password) (at flask_webgoat/auth.py line 20)
↘ "SELECT id, username, access_level FROM user WHERE username = '%s' AND password = '%s'"         % (username, password) (at flask_webgoat/auth.py line 19)
↘ query (at flask_webgoat/auth.py line 18)
↘ query_db(query, [], True) (at flask_webgoat/auth.py line 22)
↘ query (at flask_webgoat/init.py line 10)
↘ conn.cursor().execute(query, args) (at flask_webgoat/init.py line 14)

 Vulnerable data flow analysis result

↘ request.form (at flask_webgoat/auth.py line 10)
↘ request.form.get (at flask_webgoat/auth.py line 10)
↘ request.form.get("password") (at flask_webgoat/auth.py line 10)
↘ password (at flask_webgoat/auth.py line 10)
↘ (username, password) (at flask_webgoat/auth.py line 20)
↘ "SELECT id, username, access_level FROM user WHERE username = '%s' AND password = '%s'"         % (username, password) (at flask_webgoat/auth.py line 19)
↘ query (at flask_webgoat/auth.py line 18)
↘ query_db(query, [], True) (at flask_webgoat/auth.py line 22)
↘ query (at flask_webgoat/init.py line 10)
↘ conn.cursor().execute(query, args) (at flask_webgoat/init.py line 14)

 Vulnerable data flow analysis result

↘ request.form (at flask_webgoat/users.py line 19)
↘ request.form.get (at flask_webgoat/users.py line 19)
↘ request.form.get("username") (at flask_webgoat/users.py line 19)
↘ username (at flask_webgoat/users.py line 19)
↘ (username, password, int(access_level)) (at flask_webgoat/users.py line 40)
↘ "INSERT INTO user (username, password, access_level) VALUES ('%s', '%s', %d)"         % (username, password, int(access_level)) (at flask_webgoat/users.py line 39)
↘ query (at flask_webgoat/users.py line 38)
↘ query_db(query, [], False, True) (at flask_webgoat/users.py line 44)
↘ query (at flask_webgoat/init.py line 10)
↘ conn.cursor().execute(query, args) (at flask_webgoat/init.py line 14)

 Vulnerable data flow analysis result

↘ request.form (at flask_webgoat/users.py line 20)
↘ request.form.get (at flask_webgoat/users.py line 20)
↘ request.form.get("password") (at flask_webgoat/users.py line 20)
↘ password (at flask_webgoat/users.py line 20)
↘ (username, password, int(access_level)) (at flask_webgoat/users.py line 40)
↘ "INSERT INTO user (username, password, access_level) VALUES ('%s', '%s', %d)"         % (username, password, int(access_level)) (at flask_webgoat/users.py line 39)
↘ query (at flask_webgoat/users.py line 38)
↘ query_db(query, [], False, True) (at flask_webgoat/users.py line 44)
↘ query (at flask_webgoat/init.py line 10)
↘ conn.cursor().execute(query, args) (at flask_webgoat/init.py line 14)

🐸 JFrog Frogbot

🐸 JFrog Frogbot

pickle.loads(data)

at flask_webgoat/actions.py (line 61)
🎯 Static Application Security Testing (SAST) Vulnerability

Severity
Finding

    High
Unsafe Deserialization

 Full description

Overview
Unsafe deserialization is a security vulnerability that occurs when a program deserializes
untrusted data with a potentially dangerous deserializer.
Deserialization is the process of converting serialized data (data that
has been converted into a format that can be easily transmitted or stored) back into its
original form. In some ("unsafe") serialization protocols, if an attacker is able to
manipulate the serialized data, they may be able to execute arbitrary code or perform other
malicious actions when the data is deserialized.
Query operation
In this query we look for user input that can flow un-sanitized to potentially unsafe
deserialization methods
Vulnerable example
import yaml
from flask import Flask, request

app = Flask(__name__)

@app.route('/process', methods=['POST'])
def process():
    data = request.get_data()

    # Vulnerable deserialization
    obj = yaml.load(data)

    # Process the deserialized object (for simplicity, we're just printing it)
    print(obj)

    return 'Data processed'

if __name__ == '__main__':
    app.run()

In this example, the application exposes a /process endpoint that accepts data via a POST
request. The vulnerable code uses the yaml.load() function
to deserialize the received data.
The vulnerability lies in the fact that the yaml module can execute arbitrary code
during the deserialization process.
An attacker can exploit this by crafting a malicious payload
that executes arbitrary code when the yaml.load() function is called.
Remediation
Use deserialization routines that are known to handle untrusted data securely, such as
yaml.safe_load. It is highly recommended to use the json module for serialization, as it
deserializes untrusted data securely.
@app.route('/process', methods=['POST'])
def process():
    data = request.get_data()

    # Safe deserialization
-    obj = yaml.load(data)
+    obj = yaml.safe_load(data)

    # Process the deserialized object (for simplicity, we're just printing it)
    print(obj)

    return 'Data processed'

 Code Flows

 Vulnerable data flow analysis result

↘ request.form (at flask_webgoat/actions.py line 58)
↘ request.form.get (at flask_webgoat/actions.py line 58)
↘ request.form.get('pickled') (at flask_webgoat/actions.py line 58)
↘ pickled (at flask_webgoat/actions.py line 58)
↘ base64.urlsafe_b64decode(pickled) (at flask_webgoat/actions.py line 59)
↘ data (at flask_webgoat/actions.py line 59)
↘ pickle.loads(data) (at flask_webgoat/actions.py line 61)

🐸 JFrog Frogbot

🐸 JFrog Frogbot

subprocess.run(
        ["ps aux | grep " + name + " | awk '{print $11}'"],
        shell=True,
        capture_output=True,
    )

at flask_webgoat/actions.py (line 44)
🎯 Static Application Security Testing (SAST) Vulnerability

Severity
Finding

    High
Command Injection

 Full description

Command Injection is a type of vulnerability that allows an attacker
to execute arbitrary OS shell commands on the target computer.
This can allow the attacker to gain full control of the target system, potentially
leading to sensitive information being compromised or unauthorized actions being performed.
Vulnerable example
@app.route("/dir_list", methods=["POST"])
def calculate():
    path = request.form.get("path")
    os.system("/opt/proc/proc " + arg)

Remediation
-   os.system("/opt/proc/proc " + arg)
+   if arg in argument_options:
+       subprocess.run(["/opt/proc/proc", argument_options[arg]])

 Code Flows

 Vulnerable data flow analysis result

↘ request.args (at flask_webgoat/actions.py line 42)
↘ request.args.get (at flask_webgoat/actions.py line 42)
↘ request.args.get("name") (at flask_webgoat/actions.py line 42)
↘ name (at flask_webgoat/actions.py line 42)
↘ "ps aux | grep " + name (at flask_webgoat/actions.py line 45)
↘ "ps aux | grep " + name + " | awk '{print $11}'" (at flask_webgoat/actions.py line 45)
↘ ["ps aux | grep " + name + " | awk '{print $11}'"] (at flask_webgoat/actions.py line 45)
↘ subprocess.run(         ["ps aux | grep " + name + " | awk '{print $11}'"],         shell=True,         capture_output=True,     ) (at flask_webgoat/actions.py line 44)

🐸 JFrog Frogbot

🐸 JFrog Frogbot

conn.set_trace_callback(print)

at flask_webgoat/__init__.py (line 13)
🎯 Static Application Security Testing (SAST) Vulnerability

Severity
Finding

     Low
Stack Trace Exposure

 Full description

Overview
Stack trace exposure is a type of security vulnerability that occurs when a program reveals
sensitive information, such as the names and locations of internal files and variables,
in error messages or other diagnostic output. This can happen when a program crashes or
encounters an error, and the stack trace (a record of the program's call stack at the time
of the error) is included in the output. Stack trace exposure can provide attackers with
valuable information about a program's internal workings and vulnerabilities, making it
easier for them to exploit those vulnerabilities and gain unauthorized access
to the system.
Query operation
In this query we look for any stack trace information flowing into the output.
Vulnerable example
import traceback

def my_function():
    try:
        # Some code that may raise an exception
        raise ValueError('Something went wrong')
    except ValueError as e:
        traceback.print_tb(e.__traceback__)

my_function()

In this example, the my_function() function intentionally raises
a ValueError exception.
The traceback.print_tb() function is then used to print the stack trace
when the exception is caught. The vulnerability lies in using traceback.print_tb()
to output the stack trace directly to the console or any other output stream.
If this code were part of a web application or exposed through an API,
the stack trace would be exposed in the server logs or potentially returned
as part of an error response to the client.
Remediation
Log the exception to a logging framework or file, instead of outputting directly to the
console-
def log_exception(exception):
    logging.exception('An exception occurred', exc_info=exception)

def my_function():
    try:
        # Some code that may raise an exception
        raise ValueError('Something went wrong')
    except ValueError as e:
-       traceback.print_tb(e.__traceback__)
+       log_exception(e)

🐸 JFrog Frogbot

🐸 JFrog Frogbot

subprocess.run(
        ["ps aux | grep " + name + " | awk '{print $11}'"],
        shell=True,
        capture_output=True,
    )

at flask_webgoat/actions.py (line 44)
🎯 Static Application Security Testing (SAST) Vulnerability

Severity
Finding

     Low
Parameter Injection

 Full description

In a Parameter Injection vulnerability, the attacker may control a parameter passed
to a child process. The severity of the issue is lower than command injection, and
its impact will depend on the specifics of the child process being run.
Vulnerable example
    @app.route("/start_proc", methods=["POST"])
    def calculate():
        param_option = request.form.get("param")
        subprocess.run(["/opt/proc/proc", param_option])

Remediation
Avoid passing non-whitelisted arguments to child processes
-   subprocess.run(["/opt/proc/proc", param_option])
+   if param_option in whitelist:
+       subprocess.run(["/opt/proc/proc", whitelist[param_option]])

 Code Flows

 Vulnerable data flow analysis result

↘ request.args (at flask_webgoat/actions.py line 42)
↘ request.args.get (at flask_webgoat/actions.py line 42)
↘ request.args.get("name") (at flask_webgoat/actions.py line 42)
↘ name (at flask_webgoat/actions.py line 42)
↘ "ps aux | grep " + name (at flask_webgoat/actions.py line 45)
↘ "ps aux | grep " + name + " | awk '{print $11}'" (at flask_webgoat/actions.py line 45)
↘ ["ps aux | grep " + name + " | awk '{print $11}'"] (at flask_webgoat/actions.py line 45)
↘ subprocess.run(         ["ps aux | grep " + name + " | awk '{print $11}'"],         shell=True,         capture_output=True,     ) (at flask_webgoat/actions.py line 44)

🐸 JFrog Frogbot

🐸 JFrog Frogbot

pickle.loads(data)

at flask_webgoat/actions.py (line 61)
🎯 Static Application Security Testing (SAST) Vulnerability

Severity
Finding

    High
Unsafe Deserialization

 Full description

Overview
Unsafe deserialization is a security vulnerability that occurs when a program deserializes
untrusted data with a potentially dangerous deserializer.
Deserialization is the process of converting serialized data (data that
has been converted into a format that can be easily transmitted or stored) back into its
original form. In some ("unsafe") serialization protocols, if an attacker is able to
manipulate the serialized data, they may be able to execute arbitrary code or perform other
malicious actions when the data is deserialized.
Query operation
In this query we look for user input that can flow un-sanitized to potentially unsafe
deserialization methods
Vulnerable example
import yaml
from flask import Flask, request

app = Flask(__name__)

@app.route('/process', methods=['POST'])
def process():
    data = request.get_data()

    # Vulnerable deserialization
    obj = yaml.load(data)

    # Process the deserialized object (for simplicity, we're just printing it)
    print(obj)

    return 'Data processed'

if __name__ == '__main__':
    app.run()

In this example, the application exposes a /process endpoint that accepts data via a POST
request. The vulnerable code uses the yaml.load() function
to deserialize the received data.
The vulnerability lies in the fact that the yaml module can execute arbitrary code
during the deserialization process.
An attacker can exploit this by crafting a malicious payload
that executes arbitrary code when the yaml.load() function is called.
Remediation
Use deserialization routines that are known to handle untrusted data securely, such as
yaml.safe_load. It is highly recommended to use the json module for serialization, as it
deserializes untrusted data securely.
@app.route('/process', methods=['POST'])
def process():
    data = request.get_data()

    # Safe deserialization
-    obj = yaml.load(data)
+    obj = yaml.safe_load(data)

    # Process the deserialized object (for simplicity, we're just printing it)
    print(obj)

    return 'Data processed'

 Code Flows

 Vulnerable data flow analysis result

↘ request.form (at flask_webgoat/actions.py line 58)
↘ request.form.get (at flask_webgoat/actions.py line 58)
↘ request.form.get('pickled') (at flask_webgoat/actions.py line 58)
↘ pickled (at flask_webgoat/actions.py line 58)
↘ base64.urlsafe_b64decode(pickled) (at flask_webgoat/actions.py line 59)
↘ data (at flask_webgoat/actions.py line 59)
↘ pickle.loads(data) (at flask_webgoat/actions.py line 61)

🐸 JFrog Frogbot

🐸 JFrog Frogbot

subprocess.run(
        ["ps aux | grep " + name + " | awk '{print $11}'"],
        shell=True,
        capture_output=True,
    )

at flask_webgoat/actions.py (line 44)
🎯 Static Application Security Testing (SAST) Vulnerability

Severity
Finding

    High
Command Injection

 Full description

Command Injection is a type of vulnerability that allows an attacker
to execute arbitrary OS shell commands on the target computer.
This can allow the attacker to gain full control of the target system, potentially
leading to sensitive information being compromised or unauthorized actions being performed.
Vulnerable example
@app.route("/dir_list", methods=["POST"])
def calculate():
    path = request.form.get("path")
    os.system("/opt/proc/proc " + arg)

Remediation
-   os.system("/opt/proc/proc " + arg)
+   if arg in argument_options:
+       subprocess.run(["/opt/proc/proc", argument_options[arg]])

 Code Flows

 Vulnerable data flow analysis result

↘ request.args (at flask_webgoat/actions.py line 42)
↘ request.args.get (at flask_webgoat/actions.py line 42)
↘ request.args.get("name") (at flask_webgoat/actions.py line 42)
↘ name (at flask_webgoat/actions.py line 42)
↘ "ps aux | grep " + name (at flask_webgoat/actions.py line 45)
↘ "ps aux | grep " + name + " | awk '{print $11}'" (at flask_webgoat/actions.py line 45)
↘ ["ps aux | grep " + name + " | awk '{print $11}'"] (at flask_webgoat/actions.py line 45)
↘ subprocess.run(         ["ps aux | grep " + name + " | awk '{print $11}'"],         shell=True,         capture_output=True,     ) (at flask_webgoat/actions.py line 44)

🐸 JFrog Frogbot

🐸 JFrog Frogbot

Path(user_dir + "/" + filename)

at flask_webgoat/actions.py (line 33)
🎯 Static Application Security Testing (SAST) Vulnerability

Severity
Finding

    High
Path Traversal

 Full description

Overview
Path traversal, also known as directory traversal, is a type of vulnerability that allows an
attacker to access files or directories on a computer or device that are outside of
the intended directory.
Allowing arbitrary read access can allow the attacker to read sensitive files, such as
configuration files or sensitive data, potentially leading data loss
or even system compromise.
Allowing arbitrary write access is more severe and in most cases leads to arbitrary code
execution, via editing important system files or sensitive data.
Query operation
In this query we look for user input that can flow un-sanitized as a path into file access
functions
(either read or write access)
Vulnerable example
from flask import Flask, request, send_file
app = Flask(__name__)

@app.route('/files/')
def serve_file():
    filename = request.args.get('filename')
    basepath = 'static/files/'
    return send_file(basepath + filename)

if __name__ == '__main__':
    app.run()

In this example, the application has a route /files/ that serves files from a directory
called static/files. The vulnerability lies in the fact that the application does not
properly validate or sanitize the filename parameter, allowing an attacker to traverse
beyond the intended directory and access sensitive files on the server.
An attacker could exploit this vulnerability by manipulating the filename parameter
and providing a relative path to access files outside of the static/files directory.
For example, they could craft a URL like this:
http://localhost:5000/files/?filename=../../../etc/passwd
Remediation
When possible, use inherently safe path functions such as send_from_directory that perform
filename escaping -
@app.route('/files/')
def serve_file():
    filename = request.args.get('filename')
    basepath = 'static/files/'
-    return send_file(basepath + filename)
+    return send_from_directory(basepath, filename)

Alternatively, before accessing a potential path, check that the user's filename does not
escape the intended path -
from pathlib import Path
def is_escaping_path(basepath, userpath):
    try:
        Path(basepath).joinpath(userpath).resolve().relative_to(basepath.resolve())
        return False
    except ValueError:
        return True

@app.route('/files/')
def serve_file():
    filename = request.args.get('filename')
    basepath = 'static/files/'
+    if is_escaping_path(basepath, filename):
+         abort(400)  # Bad Request
    return send_file(basepath + filename)

 Code Flows

 Vulnerable data flow analysis result

↘ request.form (at flask_webgoat/actions.py line 19)
↘ request.form.get (at flask_webgoat/actions.py line 19)
↘ request.form.get("filename") (at flask_webgoat/actions.py line 19)
↘ filename_param (at flask_webgoat/actions.py line 19)
↘ filename_param + ".txt" (at flask_webgoat/actions.py line 32)
↘ filename (at flask_webgoat/actions.py line 32)
↘ user_dir + "/" + filename (at flask_webgoat/actions.py line 33)
↘ Path(user_dir + "/" + filename) (at flask_webgoat/actions.py line 33)

🐸 JFrog Frogbot

🐸 JFrog Frogbot

conn.cursor().execute(query, args)

at flask_webgoat/__init__.py (line 14)
🎯 Static Application Security Testing (SAST) Vulnerability

Severity
Finding

    High
SQL Injection

 Full description

Overview
SQL injection is a type of vulnerability that allows an attacker to execute arbitrary SQL
commands on a database.
This can allow the attacker to gain access to sensitive information,
such as user credentials or sensitive data, or to perform unauthorized actions,
such as deleting or modifying data.
Query operation
In this query we check if a user input can flow un-sanitized into an SQL query.
Vulnerable example
from flask import Flask, request
import sqlite3

app = Flask(__name__)

@app.route('/login', methods=['POST'])
def login():
    username = request.form.get('username')
    password = request.form.get('password')

    # Vulnerable SQL query
    query = f"SELECT * FROM users WHERE username = '{username}' AND password = '{password}'"

    # Execute the query
    conn = sqlite3.connect('database.db')
    cursor = conn.cursor()
    cursor.execute(query)
    user = cursor.fetchone()
    conn.close()

    if user:
        return 'Login successful'
    else:
        return 'Login failed'

if __name__ == '__main__':
    app.run()

In this example, the application accepts a username and password from a login form via a
POST request. The SQL query is constructed using string concatenation, which makes it
vulnerable to SQL injection attacks.
An attacker can exploit this vulnerability by entering ' OR 1=1 -- as the username.
The resulting query would become -
SELECT * FROM users WHERE username = '' OR 1=1 --' AND password = ''

which will always evaluate to TRUE, leading to an authentication bypass
since the attacker has no valid credentials.
Remediation
Replace the vulnerable string concatenation with a parameterized query
using ? placeholders -
@app.route('/login', methods=['POST'])
    def login():
    username = request.form.get('username')
    password = request.form.get('password')

    # Vulnerable SQL query
-   query = f"SELECT * FROM users WHERE username = '{username}' AND password = '{password}'"
+   query = "SELECT * FROM users WHERE username = ? AND password = ?"

    # Execute the query
    conn = sqlite3.connect('database.db')
    cursor = conn.cursor()
-    cursor.execute(query)
+    cursor.execute(query, (username, password))
    user = cursor.fetchone()
    conn.close()

    if user:
        return 'Login successful'
    else:
        return 'Login failed'

 Code Flows

 Vulnerable data flow analysis result

↘ request.form (at flask_webgoat/auth.py line 9)
↘ request.form.get (at flask_webgoat/auth.py line 9)
↘ request.form.get("username") (at flask_webgoat/auth.py line 9)
↘ username (at flask_webgoat/auth.py line 9)
↘ (username, password) (at flask_webgoat/auth.py line 20)
↘ "SELECT id, username, access_level FROM user WHERE username = '%s' AND password = '%s'"         % (username, password) (at flask_webgoat/auth.py line 19)
↘ query (at flask_webgoat/auth.py line 18)
↘ query_db(query, [], True) (at flask_webgoat/auth.py line 22)
↘ query (at flask_webgoat/init.py line 10)
↘ conn.cursor().execute(query, args) (at flask_webgoat/init.py line 14)

 Vulnerable data flow analysis result

↘ request.form (at flask_webgoat/auth.py line 10)
↘ request.form.get (at flask_webgoat/auth.py line 10)
↘ request.form.get("password") (at flask_webgoat/auth.py line 10)
↘ password (at flask_webgoat/auth.py line 10)
↘ (username, password) (at flask_webgoat/auth.py line 20)
↘ "SELECT id, username, access_level FROM user WHERE username = '%s' AND password = '%s'"         % (username, password) (at flask_webgoat/auth.py line 19)
↘ query (at flask_webgoat/auth.py line 18)
↘ query_db(query, [], True) (at flask_webgoat/auth.py line 22)
↘ query (at flask_webgoat/init.py line 10)
↘ conn.cursor().execute(query, args) (at flask_webgoat/init.py line 14)

 Vulnerable data flow analysis result

↘ request.form (at flask_webgoat/users.py line 19)
↘ request.form.get (at flask_webgoat/users.py line 19)
↘ request.form.get("username") (at flask_webgoat/users.py line 19)
↘ username (at flask_webgoat/users.py line 19)
↘ (username, password, int(access_level)) (at flask_webgoat/users.py line 40)
↘ "INSERT INTO user (username, password, access_level) VALUES ('%s', '%s', %d)"         % (username, password, int(access_level)) (at flask_webgoat/users.py line 39)
↘ query (at flask_webgoat/users.py line 38)
↘ query_db(query, [], False, True) (at flask_webgoat/users.py line 44)
↘ query (at flask_webgoat/init.py line 10)
↘ conn.cursor().execute(query, args) (at flask_webgoat/init.py line 14)

 Vulnerable data flow analysis result

↘ request.form (at flask_webgoat/users.py line 20)
↘ request.form.get (at flask_webgoat/users.py line 20)
↘ request.form.get("password") (at flask_webgoat/users.py line 20)
↘ password (at flask_webgoat/users.py line 20)
↘ (username, password, int(access_level)) (at flask_webgoat/users.py line 40)
↘ "INSERT INTO user (username, password, access_level) VALUES ('%s', '%s', %d)"         % (username, password, int(access_level)) (at flask_webgoat/users.py line 39)
↘ query (at flask_webgoat/users.py line 38)
↘ query_db(query, [], False, True) (at flask_webgoat/users.py line 44)
↘ query (at flask_webgoat/init.py line 10)
↘ conn.cursor().execute(query, args) (at flask_webgoat/init.py line 14)

🐸 JFrog Frogbot

🐸 JFrog Frogbot

conn.set_trace_callback(print)

at flask_webgoat/__init__.py (line 13)
🎯 Static Application Security Testing (SAST) Vulnerability

Severity
Finding

     Low
Stack Trace Exposure

 Full description

Overview
Stack trace exposure is a type of security vulnerability that occurs when a program reveals
sensitive information, such as the names and locations of internal files and variables,
in error messages or other diagnostic output. This can happen when a program crashes or
encounters an error, and the stack trace (a record of the program's call stack at the time
of the error) is included in the output. Stack trace exposure can provide attackers with
valuable information about a program's internal workings and vulnerabilities, making it
easier for them to exploit those vulnerabilities and gain unauthorized access
to the system.
Query operation
In this query we look for any stack trace information flowing into the output.
Vulnerable example
import traceback

def my_function():
    try:
        # Some code that may raise an exception
        raise ValueError('Something went wrong')
    except ValueError as e:
        traceback.print_tb(e.__traceback__)

my_function()

In this example, the my_function() function intentionally raises
a ValueError exception.
The traceback.print_tb() function is then used to print the stack trace
when the exception is caught. The vulnerability lies in using traceback.print_tb()
to output the stack trace directly to the console or any other output stream.
If this code were part of a web application or exposed through an API,
the stack trace would be exposed in the server logs or potentially returned
as part of an error response to the client.
Remediation
Log the exception to a logging framework or file, instead of outputting directly to the
console-
def log_exception(exception):
    logging.exception('An exception occurred', exc_info=exception)

def my_function():
    try:
        # Some code that may raise an exception
        raise ValueError('Something went wrong')
    except ValueError as e:
-       traceback.print_tb(e.__traceback__)
+       log_exception(e)

🐸 JFrog Frogbot

🐸 JFrog Frogbot

subprocess.run(
        ["ps aux | grep " + name + " | awk '{print $11}'"],
        shell=True,
        capture_output=True,
    )

at flask_webgoat/actions.py (line 44)
🎯 Static Application Security Testing (SAST) Vulnerability

Severity
Finding

     Low
Parameter Injection

 Full description

In a Parameter Injection vulnerability, the attacker may control a parameter passed
to a child process. The severity of the issue is lower than command injection, and
its impact will depend on the specifics of the child process being run.
Vulnerable example
    @app.route("/start_proc", methods=["POST"])
    def calculate():
        param_option = request.form.get("param")
        subprocess.run(["/opt/proc/proc", param_option])

Remediation
Avoid passing non-whitelisted arguments to child processes
-   subprocess.run(["/opt/proc/proc", param_option])
+   if param_option in whitelist:
+       subprocess.run(["/opt/proc/proc", whitelist[param_option]])

 Code Flows

 Vulnerable data flow analysis result

↘ request.args (at flask_webgoat/actions.py line 42)
↘ request.args.get (at flask_webgoat/actions.py line 42)
↘ request.args.get("name") (at flask_webgoat/actions.py line 42)
↘ name (at flask_webgoat/actions.py line 42)
↘ "ps aux | grep " + name (at flask_webgoat/actions.py line 45)
↘ "ps aux | grep " + name + " | awk '{print $11}'" (at flask_webgoat/actions.py line 45)
↘ ["ps aux | grep " + name + " | awk '{print $11}'"] (at flask_webgoat/actions.py line 45)
↘ subprocess.run(         ["ps aux | grep " + name + " | awk '{print $11}'"],         shell=True,         capture_output=True,     ) (at flask_webgoat/actions.py line 44)

🐸 JFrog Frogbot

🐸 JFrog Frogbot

📦 Vulnerable Dependencies
✍ Summary

SEVERITY
CONTEXTUAL ANALYSIS
DIRECT DEPENDENCIES
IMPACTED DEPENDENCY
FIXED VERSIONS
CVES

    High
Undetermined
pip:21.2.3
pip 21.2.3
-
CVE-2018-20225

     Low
Undetermined
pip:21.2.3
pip 21.2.3
[23.3]
CVE-2023-5752

    High
Not Applicable
flask:1.1.2
flask 1.1.2
[2.2.5][2.3.2]
CVE-2023-30861

  Medium
Not Applicable
setuptools:57.4.0
setuptools 57.4.0
[65.5.1]
CVE-2022-40897

Critical
Applicable
werkzeug:1.0.1
werkzeug 1.0.1
[2.1.1]
CVE-2022-29361

    High
Undetermined
pip:21.2.3
pip 21.2.3
-
CVE-2018-20225

    High
Undetermined
werkzeug:1.0.1
werkzeug 1.0.1
[2.3.8][3.0.1]
CVE-2023-46136

  Medium
Undetermined
jinja2:2.11.3
jinja2 2.11.3
[3.1.3]
CVE-2024-22195

     Low
Undetermined
werkzeug:1.0.1
werkzeug 1.0.1
[2.2.3]
CVE-2023-23934

     Low
Undetermined
pip:21.2.3
pip 21.2.3
[23.3]
CVE-2023-5752

    High
Not Applicable
werkzeug:1.0.1
werkzeug 1.0.1
[2.2.3]
CVE-2023-25577

  Medium
Not Applicable
setuptools:57.4.0
setuptools 57.4.0
[65.5.1]
CVE-2022-40897

 🔬 Research Details

 [ CVE-2018-20225 ] pip 21.2.3

Description:
This CVE refers to the possibility of a "dependency confusion" attack when using pip with the --extra-index-url flag. This vulnerability has been disputed by the maintainers of pip as the described behavior is intended (although potentially insecure) and as such there are no plans to fix it.
If pip is executed with the --extra-index-url when using a private PyPI repository, an attacker could cause pip to download a private package (for example one named private_package) by adding a package with the same name (private_package) in the public PyPI repository. This would lead to remote code execution as pip will download the public package that could contain malicious code. This dependency confusion attack was demonstrated in 2021 by Alex Birsan.
Remediation:
Deployment mitigations
Do not use the --extra-index-url flag with pip and consider using version pinning for deployments.

 [ CVE-2023-5752 ] pip 21.2.3

Description:
When installing a package from a Mercurial VCS URL  (ie "pip install
hg+...") with pip prior to v23.3, the specified Mercurial revision could
be used to inject arbitrary configuration options to the "hg clone"
call (ie "--config"). Controlling the Mercurial configuration can modify
how and which repository is installed. This vulnerability does not
affect users who aren't installing from Mercurial.

 [ CVE-2023-30861 ] flask 1.1.2

Description:
Flask is a lightweight web framework for Python used for building web applications.
An issue arises when using a caching proxy that caches cookies (specifically, the Set-Cookie headers) from responses intended for clients. This situation can result in the proxy sending one client's session cookies to other clients, leading to data leakage or even privilege escalation.
The root cause of this issue is the absence of the Vary: Cookie header, which informs the proxy not to cache session cookies when the session is refreshed (i.e., resent to update the expiration) without being accessed or modified. The Vary: Cookie header is typically set when the session is accessed or modified.
To exploit this vulnerability, several specific conditions must be met:

The application must be hosted behind a proxy that caches responses along with their cookies.
The application must have the session.permanent attribute set to True.
The session must not be accessed or modified before the request is made.
The SESSION_REFRESH_EACH_REQUEST feature must be enabled (which is the default behavior).
The application should not set a Cache-Control header to indicate that a page is private and should not be cached.

Example of vulnerable code:
from flask import Flask, session

app = Flask(__name__)
app.secret_key = 'your_secret_key'

@app.route('/')
def index():
    session.permanent = True
    # Other code logic...
    return privateData(user)

In this example, a Flask application is used, and the session.permanent attribute is set to True. If this application is deployed behind a caching proxy without proper handling of session cookies and caching directives, the issue may be present.
Remediation:
Development mitigations
Add a Cache-Control in all requests/responses sent by the application explicitly instructing the caching proxy not to cache any content:
@app.after_request
def add_cache_control(response):
    response.headers['Cache-Control'] = 'no-store, no-cache, private, must-revalidate, max-age=0'
    return response

Development mitigations
Disable the SESSION_REFRESH_EACH_REQUEST setting of the Flask application:
app = Flask(__name__)
app.config['SESSION_REFRESH_EACH_REQUEST'] = False

 [ CVE-2022-40897 ] setuptools 57.4.0

Description:
Setuptools is a package for managing Python packages and dependencies, including tools for building and distributing packages, as well as for discovering and managing 3rd party packages available on PyPI.
The find_external_links function in the setuptools.package_index module is used to find external links that are associated with a package available on the Python Package Index (PyPI). These external links are typically URLs to the package's homepage, documentation, source code repository, and other resources that are related to the package.
The most common scenario of triggering this issue is when running pip with the --editable flag. This will cause the vulnerable find_external_links function to be invoked
Example of manual usage of find_external_links -
from setuptools.package_index import PackageIndex
import requests

# Specify the URL of the package page on PyPI
url = 'https://pypi.org/project/requests'

# Use the requests library to retrieve the HTML content of the package page
response = requests.get(url)

# Create an instance of the PackageIndex class
index = PackageIndex()

# Use the find_external_links function to find external links for the package
links = index.find_external_links(url, response.text)

# Print the name and URL of each external link
for link_name, link_url in links:
    print(f'{link_name}: {link_url}')

This example will find and print all external links for a package.
To find a specific url, i.e. the tag containing the rel= property, the find_external_links function uses a Regular Expression (regex). The regex is too not efficient which can lead to ReDoS on specific user inputs.
As a result, a user fetching malicious HTML from a package in PyPI or a custom PackageIndex page may be attacked.

 [ CVE-2022-29361 ] werkzeug 1.0.1

Description:
Improper parsing of HTTP requests in Pallets Werkzeug v2.1.0 and below allows attackers to perform HTTP Request Smuggling using a crafted HTTP request with multiple requests included inside the body. NOTE: the vendor's position is that this behavior can only occur in unsupported configurations involving development mode and an HTTP server from outside the Werkzeug project

 [ CVE-2018-20225 ] pip 21.2.3

Description:
This CVE refers to the possibility of a "dependency confusion" attack when using pip with the --extra-index-url flag. This vulnerability has been disputed by the maintainers of pip as the described behavior is intended (although potentially insecure) and as such there are no plans to fix it.
If pip is executed with the --extra-index-url when using a private PyPI repository, an attacker could cause pip to download a private package (for example one named private_package) by adding a package with the same name (private_package) in the public PyPI repository. This would lead to remote code execution as pip will download the public package that could contain malicious code. This dependency confusion attack was demonstrated in 2021 by Alex Birsan.
Remediation:
Deployment mitigations
Do not use the --extra-index-url flag with pip and consider using version pinning for deployments.

 [ CVE-2023-46136 ] werkzeug 1.0.1

Description:
Werkzeug is a comprehensive WSGI web application library. If an upload of a file that starts with CR or LF and then is followed by megabytes of data without these characters: all of these bytes are appended chunk by chunk into internal bytearray and lookup for boundary is performed on growing buffer. This allows an attacker to cause a denial of service by sending crafted multipart data to an endpoint that will parse it. The amount of CPU time required can block worker processes from handling legitimate requests. This vulnerability has been patched in version 3.0.1.

 [ CVE-2024-22195 ] jinja2 2.11.3

Description:
Jinja is an extensible templating engine. Special placeholders in the template allow writing code similar to Python syntax. It is possible to inject arbitrary HTML attributes into the rendered HTML template, potentially leading to Cross-Site Scripting (XSS). The Jinja xmlattr filter can be abused to inject arbitrary HTML attribute keys and values, bypassing the auto escaping mechanism and potentially leading to XSS. It may also be possible to bypass attribute validation checks if they are blacklist-based.

 [ CVE-2023-23934 ] werkzeug 1.0.1

Description:
Werkzeug is a comprehensive WSGI web application library. Browsers may allow "nameless" cookies that look like =value instead of key=value. A vulnerable browser may allow a compromised application on an adjacent subdomain to exploit this to set a cookie like =__Host-test=bad for another subdomain. Werkzeug prior to 2.2.3 will parse the cookie =__Host-test=bad as __Host-test=bad`. If a Werkzeug application is running next to a vulnerable or malicious subdomain which sets such a cookie using a vulnerable browser, the Werkzeug application will see the bad cookie value but the valid cookie key. The issue is fixed in Werkzeug 2.2.3.

 [ CVE-2023-5752 ] pip 21.2.3

Description:
When installing a package from a Mercurial VCS URL  (ie "pip install
hg+...") with pip prior to v23.3, the specified Mercurial revision could
be used to inject arbitrary configuration options to the "hg clone"
call (ie "--config"). Controlling the Mercurial configuration can modify
how and which repository is installed. This vulnerability does not
affect users who aren't installing from Mercurial.

 [ CVE-2023-25577 ] werkzeug 1.0.1

Description:
Werkzeug is a comprehensive WSGI web application library. Prior to version 2.2.3, Werkzeug's multipart form data parser will parse an unlimited number of parts, including file parts. Parts can be a small amount of bytes, but each requires CPU time to parse and may use more memory as Python data. If a request can be made to an endpoint that accesses request.data, request.form, request.files, or request.get_data(parse_form_data=False), it can cause unexpectedly high resource usage. This allows an attacker to cause a denial of service by sending crafted multipart data to an endpoint that will parse it. The amount of CPU time required can block worker processes from handling legitimate requests. The amount of RAM required can trigger an out of memory kill of the process. Unlimited file parts can use up memory and file handles. If many concurrent requests are sent continuously, this can exhaust or kill all available workers. Version 2.2.3 contains a patch for this issue.

 [ CVE-2022-40897 ] setuptools 57.4.0

Description:
Setuptools is a package for managing Python packages and dependencies, including tools for building and distributing packages, as well as for discovering and managing 3rd party packages available on PyPI.
The find_external_links function in the setuptools.package_index module is used to find external links that are associated with a package available on the Python Package Index (PyPI). These external links are typically URLs to the package's homepage, documentation, source code repository, and other resources that are related to the package.
The most common scenario of triggering this issue is when running pip with the --editable flag. This will cause the vulnerable find_external_links function to be invoked
Example of manual usage of find_external_links -
from setuptools.package_index import PackageIndex
import requests

# Specify the URL of the package page on PyPI
url = 'https://pypi.org/project/requests'

# Use the requests library to retrieve the HTML content of the package page
response = requests.get(url)

# Create an instance of the PackageIndex class
index = PackageIndex()

# Use the find_external_links function to find external links for the package
links = index.find_external_links(url, response.text)

# Print the name and URL of each external link
for link_name, link_url in links:
    print(f'{link_name}: {link_url}')

This example will find and print all external links for a package.
To find a specific url, i.e. the tag containing the rel= property, the find_external_links function uses a Regular Expression (regex). The regex is too not efficient which can lead to ReDoS on specific user inputs.
As a result, a user fetching malicious HTML from a package in PyPI or a custom PackageIndex page may be attacked.

🐸 JFrog Frogbot

pickle.loads(data)

at flask_webgoat/actions.py (line 61)
🎯 Static Application Security Testing (SAST) Vulnerability

Severity
Finding

    High
Unsafe Deserialization

 Full description

Overview
Unsafe deserialization is a security vulnerability that occurs when a program deserializes
untrusted data with a potentially dangerous deserializer.
Deserialization is the process of converting serialized data (data that
has been converted into a format that can be easily transmitted or stored) back into its
original form. In some ("unsafe") serialization protocols, if an attacker is able to
manipulate the serialized data, they may be able to execute arbitrary code or perform other
malicious actions when the data is deserialized.
Query operation
In this query we look for user input that can flow un-sanitized to potentially unsafe
deserialization methods
Vulnerable example
import yaml
from flask import Flask, request

app = Flask(__name__)

@app.route('/process', methods=['POST'])
def process():
    data = request.get_data()

    # Vulnerable deserialization
    obj = yaml.load(data)

    # Process the deserialized object (for simplicity, we're just printing it)
    print(obj)

    return 'Data processed'

if __name__ == '__main__':
    app.run()

In this example, the application exposes a /process endpoint that accepts data via a POST
request. The vulnerable code uses the yaml.load() function
to deserialize the received data.
The vulnerability lies in the fact that the yaml module can execute arbitrary code
during the deserialization process.
An attacker can exploit this by crafting a malicious payload
that executes arbitrary code when the yaml.load() function is called.
Remediation
Use deserialization routines that are known to handle untrusted data securely, such as
yaml.safe_load. It is highly recommended to use the json module for serialization, as it
deserializes untrusted data securely.
@app.route('/process', methods=['POST'])
def process():
    data = request.get_data()

    # Safe deserialization
-    obj = yaml.load(data)
+    obj = yaml.safe_load(data)

    # Process the deserialized object (for simplicity, we're just printing it)
    print(obj)

    return 'Data processed'

 Code Flows

 Vulnerable data flow analysis result

↘ request.form (at flask_webgoat/actions.py line 58)
↘ request.form.get (at flask_webgoat/actions.py line 58)
↘ request.form.get('pickled') (at flask_webgoat/actions.py line 58)
↘ pickled (at flask_webgoat/actions.py line 58)
↘ base64.urlsafe_b64decode(pickled) (at flask_webgoat/actions.py line 59)
↘ data (at flask_webgoat/actions.py line 59)
↘ pickle.loads(data) (at flask_webgoat/actions.py line 61)

🐸 JFrog Frogbot

🐸 JFrog Frogbot

📦 Vulnerable Dependencies
✍ Summary

SEVERITY
CONTEXTUAL ANALYSIS
DIRECT DEPENDENCIES
IMPACTED DEPENDENCY
FIXED VERSIONS
CVES

    High
Undetermined
pip:21.2.3
pip 21.2.3
-
CVE-2018-20225

     Low
Undetermined
pip:21.2.3
pip 21.2.3
[23.3]
CVE-2023-5752

    High
Not Applicable
flask:1.1.2
flask 1.1.2
[2.2.5][2.3.2]
CVE-2023-30861

  Medium
Not Applicable
setuptools:57.4.0
setuptools 57.4.0
[65.5.1]
CVE-2022-40897

Critical
Applicable
werkzeug:1.0.1
werkzeug 1.0.1
[2.1.1]
CVE-2022-29361

    High
Undetermined
werkzeug:1.0.1
werkzeug 1.0.1
[2.3.8][3.0.1]
CVE-2023-46136

    High
Undetermined
pip:21.2.3
pip 21.2.3
-
CVE-2018-20225

  Medium
Undetermined
jinja2:2.11.3
jinja2 2.11.3
[3.1.3]
CVE-2024-22195

     Low
Undetermined
pip:21.2.3
pip 21.2.3
[23.3]
CVE-2023-5752

     Low
Undetermined
werkzeug:1.0.1
werkzeug 1.0.1
[2.2.3]
CVE-2023-23934

    High
Not Applicable
werkzeug:1.0.1
werkzeug 1.0.1
[2.2.3]
CVE-2023-25577

  Medium
Not Applicable
setuptools:57.4.0
setuptools 57.4.0
[65.5.1]
CVE-2022-40897

 🔬 Research Details

 [ CVE-2018-20225 ] pip 21.2.3

Description:
This CVE refers to the possibility of a "dependency confusion" attack when using pip with the --extra-index-url flag. This vulnerability has been disputed by the maintainers of pip as the described behavior is intended (although potentially insecure) and as such there are no plans to fix it.
If pip is executed with the --extra-index-url when using a private PyPI repository, an attacker could cause pip to download a private package (for example one named private_package) by adding a package with the same name (private_package) in the public PyPI repository. This would lead to remote code execution as pip will download the public package that could contain malicious code. This dependency confusion attack was demonstrated in 2021 by Alex Birsan.
Remediation:
Deployment mitigations
Do not use the --extra-index-url flag with pip and consider using version pinning for deployments.

 [ CVE-2023-5752 ] pip 21.2.3

Description:
When installing a package from a Mercurial VCS URL  (ie "pip install
hg+...") with pip prior to v23.3, the specified Mercurial revision could
be used to inject arbitrary configuration options to the "hg clone"
call (ie "--config"). Controlling the Mercurial configuration can modify
how and which repository is installed. This vulnerability does not
affect users who aren't installing from Mercurial.

 [ CVE-2023-30861 ] flask 1.1.2

Description:
Flask is a lightweight web framework for Python used for building web applications.
An issue arises when using a caching proxy that caches cookies (specifically, the Set-Cookie headers) from responses intended for clients. This situation can result in the proxy sending one client's session cookies to other clients, leading to data leakage or even privilege escalation.
The root cause of this issue is the absence of the Vary: Cookie header, which informs the proxy not to cache session cookies when the session is refreshed (i.e., resent to update the expiration) without being accessed or modified. The Vary: Cookie header is typically set when the session is accessed or modified.
To exploit this vulnerability, several specific conditions must be met:

The application must be hosted behind a proxy that caches responses along with their cookies.
The application must have the session.permanent attribute set to True.
The session must not be accessed or modified before the request is made.
The SESSION_REFRESH_EACH_REQUEST feature must be enabled (which is the default behavior).
The application should not set a Cache-Control header to indicate that a page is private and should not be cached.

Example of vulnerable code:
from flask import Flask, session

app = Flask(__name__)
app.secret_key = 'your_secret_key'

@app.route('/')
def index():
    session.permanent = True
    # Other code logic...
    return privateData(user)

In this example, a Flask application is used, and the session.permanent attribute is set to True. If this application is deployed behind a caching proxy without proper handling of session cookies and caching directives, the issue may be present.
Remediation:
Development mitigations
Add a Cache-Control in all requests/responses sent by the application explicitly instructing the caching proxy not to cache any content:
@app.after_request
def add_cache_control(response):
    response.headers['Cache-Control'] = 'no-store, no-cache, private, must-revalidate, max-age=0'
    return response

Development mitigations
Disable the SESSION_REFRESH_EACH_REQUEST setting of the Flask application:
app = Flask(__name__)
app.config['SESSION_REFRESH_EACH_REQUEST'] = False

 [ CVE-2022-40897 ] setuptools 57.4.0

Description:
Setuptools is a package for managing Python packages and dependencies, including tools for building and distributing packages, as well as for discovering and managing 3rd party packages available on PyPI.
The find_external_links function in the setuptools.package_index module is used to find external links that are associated with a package available on the Python Package Index (PyPI). These external links are typically URLs to the package's homepage, documentation, source code repository, and other resources that are related to the package.
The most common scenario of triggering this issue is when running pip with the --editable flag. This will cause the vulnerable find_external_links function to be invoked
Example of manual usage of find_external_links -
from setuptools.package_index import PackageIndex
import requests

# Specify the URL of the package page on PyPI
url = 'https://pypi.org/project/requests'

# Use the requests library to retrieve the HTML content of the package page
response = requests.get(url)

# Create an instance of the PackageIndex class
index = PackageIndex()

# Use the find_external_links function to find external links for the package
links = index.find_external_links(url, response.text)

# Print the name and URL of each external link
for link_name, link_url in links:
    print(f'{link_name}: {link_url}')

This example will find and print all external links for a package.
To find a specific url, i.e. the tag containing the rel= property, the find_external_links function uses a Regular Expression (regex). The regex is too not efficient which can lead to ReDoS on specific user inputs.
As a result, a user fetching malicious HTML from a package in PyPI or a custom PackageIndex page may be attacked.

 [ CVE-2022-29361 ] werkzeug 1.0.1

Description:
Improper parsing of HTTP requests in Pallets Werkzeug v2.1.0 and below allows attackers to perform HTTP Request Smuggling using a crafted HTTP request with multiple requests included inside the body. NOTE: the vendor's position is that this behavior can only occur in unsupported configurations involving development mode and an HTTP server from outside the Werkzeug project

 [ CVE-2023-46136 ] werkzeug 1.0.1

Description:
Werkzeug is a comprehensive WSGI web application library. If an upload of a file that starts with CR or LF and then is followed by megabytes of data without these characters: all of these bytes are appended chunk by chunk into internal bytearray and lookup for boundary is performed on growing buffer. This allows an attacker to cause a denial of service by sending crafted multipart data to an endpoint that will parse it. The amount of CPU time required can block worker processes from handling legitimate requests. This vulnerability has been patched in version 3.0.1.

 [ CVE-2018-20225 ] pip 21.2.3

Description:
This CVE refers to the possibility of a "dependency confusion" attack when using pip with the --extra-index-url flag. This vulnerability has been disputed by the maintainers of pip as the described behavior is intended (although potentially insecure) and as such there are no plans to fix it.
If pip is executed with the --extra-index-url when using a private PyPI repository, an attacker could cause pip to download a private package (for example one named private_package) by adding a package with the same name (private_package) in the public PyPI repository. This would lead to remote code execution as pip will download the public package that could contain malicious code. This dependency confusion attack was demonstrated in 2021 by Alex Birsan.
Remediation:
Deployment mitigations
Do not use the --extra-index-url flag with pip and consider using version pinning for deployments.

 [ CVE-2024-22195 ] jinja2 2.11.3

Description:
Jinja is an extensible templating engine. Special placeholders in the template allow writing code similar to Python syntax. It is possible to inject arbitrary HTML attributes into the rendered HTML template, potentially leading to Cross-Site Scripting (XSS). The Jinja xmlattr filter can be abused to inject arbitrary HTML attribute keys and values, bypassing the auto escaping mechanism and potentially leading to XSS. It may also be possible to bypass attribute validation checks if they are blacklist-based.

 [ CVE-2023-5752 ] pip 21.2.3

Description:
When installing a package from a Mercurial VCS URL  (ie "pip install
hg+...") with pip prior to v23.3, the specified Mercurial revision could
be used to inject arbitrary configuration options to the "hg clone"
call (ie "--config"). Controlling the Mercurial configuration can modify
how and which repository is installed. This vulnerability does not
affect users who aren't installing from Mercurial.

 [ CVE-2023-23934 ] werkzeug 1.0.1

Description:
Werkzeug is a comprehensive WSGI web application library. Browsers may allow "nameless" cookies that look like =value instead of key=value. A vulnerable browser may allow a compromised application on an adjacent subdomain to exploit this to set a cookie like =__Host-test=bad for another subdomain. Werkzeug prior to 2.2.3 will parse the cookie =__Host-test=bad as __Host-test=bad`. If a Werkzeug application is running next to a vulnerable or malicious subdomain which sets such a cookie using a vulnerable browser, the Werkzeug application will see the bad cookie value but the valid cookie key. The issue is fixed in Werkzeug 2.2.3.

 [ CVE-2023-25577 ] werkzeug 1.0.1

Description:
Werkzeug is a comprehensive WSGI web application library. Prior to version 2.2.3, Werkzeug's multipart form data parser will parse an unlimited number of parts, including file parts. Parts can be a small amount of bytes, but each requires CPU time to parse and may use more memory as Python data. If a request can be made to an endpoint that accesses request.data, request.form, request.files, or request.get_data(parse_form_data=False), it can cause unexpectedly high resource usage. This allows an attacker to cause a denial of service by sending crafted multipart data to an endpoint that will parse it. The amount of CPU time required can block worker processes from handling legitimate requests. The amount of RAM required can trigger an out of memory kill of the process. Unlimited file parts can use up memory and file handles. If many concurrent requests are sent continuously, this can exhaust or kill all available workers. Version 2.2.3 contains a patch for this issue.

 [ CVE-2022-40897 ] setuptools 57.4.0

Description:
Setuptools is a package for managing Python packages and dependencies, including tools for building and distributing packages, as well as for discovering and managing 3rd party packages available on PyPI.
The find_external_links function in the setuptools.package_index module is used to find external links that are associated with a package available on the Python Package Index (PyPI). These external links are typically URLs to the package's homepage, documentation, source code repository, and other resources that are related to the package.
The most common scenario of triggering this issue is when running pip with the --editable flag. This will cause the vulnerable find_external_links function to be invoked
Example of manual usage of find_external_links -
from setuptools.package_index import PackageIndex
import requests

# Specify the URL of the package page on PyPI
url = 'https://pypi.org/project/requests'

# Use the requests library to retrieve the HTML content of the package page
response = requests.get(url)

# Create an instance of the PackageIndex class
index = PackageIndex()

# Use the find_external_links function to find external links for the package
links = index.find_external_links(url, response.text)

# Print the name and URL of each external link
for link_name, link_url in links:
    print(f'{link_name}: {link_url}')

This example will find and print all external links for a package.
To find a specific url, i.e. the tag containing the rel= property, the find_external_links function uses a Regular Expression (regex). The regex is too not efficient which can lead to ReDoS on specific user inputs.
As a result, a user fetching malicious HTML from a package in PyPI or a custom PackageIndex page may be attacked.

🐸 JFrog Frogbot

Path(user_dir + "/" + filename)

at flask_webgoat/actions.py (line 33)
🎯 Static Application Security Testing (SAST) Vulnerability

Severity
Finding

    High
Path Traversal

 Full description

Overview
Path traversal, also known as directory traversal, is a type of vulnerability that allows an
attacker to access files or directories on a computer or device that are outside of
the intended directory.
Allowing arbitrary read access can allow the attacker to read sensitive files, such as
configuration files or sensitive data, potentially leading data loss
or even system compromise.
Allowing arbitrary write access is more severe and in most cases leads to arbitrary code
execution, via editing important system files or sensitive data.
Query operation
In this query we look for user input that can flow un-sanitized as a path into file access
functions
(either read or write access)
Vulnerable example
from flask import Flask, request, send_file
app = Flask(__name__)

@app.route('/files/')
def serve_file():
    filename = request.args.get('filename')
    basepath = 'static/files/'
    return send_file(basepath + filename)

if __name__ == '__main__':
    app.run()

In this example, the application has a route /files/ that serves files from a directory
called static/files. The vulnerability lies in the fact that the application does not
properly validate or sanitize the filename parameter, allowing an attacker to traverse
beyond the intended directory and access sensitive files on the server.
An attacker could exploit this vulnerability by manipulating the filename parameter
and providing a relative path to access files outside of the static/files directory.
For example, they could craft a URL like this:
http://localhost:5000/files/?filename=../../../etc/passwd
Remediation
When possible, use inherently safe path functions such as send_from_directory that perform
filename escaping -
@app.route('/files/')
def serve_file():
    filename = request.args.get('filename')
    basepath = 'static/files/'
-    return send_file(basepath + filename)
+    return send_from_directory(basepath, filename)

Alternatively, before accessing a potential path, check that the user's filename does not
escape the intended path -
from pathlib import Path
def is_escaping_path(basepath, userpath):
    try:
        Path(basepath).joinpath(userpath).resolve().relative_to(basepath.resolve())
        return False
    except ValueError:
        return True

@app.route('/files/')
def serve_file():
    filename = request.args.get('filename')
    basepath = 'static/files/'
+    if is_escaping_path(basepath, filename):
+         abort(400)  # Bad Request
    return send_file(basepath + filename)

 Code Flows

 Vulnerable data flow analysis result

↘ request.form (at flask_webgoat/actions.py line 19)
↘ request.form.get (at flask_webgoat/actions.py line 19)
↘ request.form.get("filename") (at flask_webgoat/actions.py line 19)
↘ filename_param (at flask_webgoat/actions.py line 19)
↘ filename_param + ".txt" (at flask_webgoat/actions.py line 32)
↘ filename (at flask_webgoat/actions.py line 32)
↘ user_dir + "/" + filename (at flask_webgoat/actions.py line 33)
↘ Path(user_dir + "/" + filename) (at flask_webgoat/actions.py line 33)

🐸 JFrog Frogbot

🐸 JFrog Frogbot

📦 Vulnerable Dependencies
✍ Summary

SEVERITY
CONTEXTUAL ANALYSIS
DIRECT DEPENDENCIES
IMPACTED DEPENDENCY
FIXED VERSIONS
CVES

    High
Undetermined
pip:21.2.3
pip 21.2.3
-
CVE-2018-20225

     Low
Undetermined
pip:21.2.3
pip 21.2.3
[23.3]
CVE-2023-5752

    High
Not Applicable
flask:1.1.2
flask 1.1.2
[2.2.5][2.3.2]
CVE-2023-30861

  Medium
Not Applicable
setuptools:57.4.0
setuptools 57.4.0
[65.5.1]
CVE-2022-40897

Critical
Applicable
werkzeug:1.0.1
werkzeug 1.0.1
[2.1.1]
CVE-2022-29361

    High
Undetermined
pip:21.2.3
pip 21.2.3
-
CVE-2018-20225

    High
Undetermined
werkzeug:1.0.1
werkzeug 1.0.1
[2.3.8][3.0.1]
CVE-2023-46136

  Medium
Undetermined
jinja2:2.11.3
jinja2 2.11.3
[3.1.3]
CVE-2024-22195

     Low
Undetermined
werkzeug:1.0.1
werkzeug 1.0.1
[2.2.3]
CVE-2023-23934

     Low
Undetermined
pip:21.2.3
pip 21.2.3
[23.3]
CVE-2023-5752

    High
Not Applicable
werkzeug:1.0.1
werkzeug 1.0.1
[2.2.3]
CVE-2023-25577

  Medium
Not Applicable
setuptools:57.4.0
setuptools 57.4.0
[65.5.1]
CVE-2022-40897

 🔬 Research Details

 [ CVE-2018-20225 ] pip 21.2.3

Description:
This CVE refers to the possibility of a "dependency confusion" attack when using pip with the --extra-index-url flag. This vulnerability has been disputed by the maintainers of pip as the described behavior is intended (although potentially insecure) and as such there are no plans to fix it.
If pip is executed with the --extra-index-url when using a private PyPI repository, an attacker could cause pip to download a private package (for example one named private_package) by adding a package with the same name (private_package) in the public PyPI repository. This would lead to remote code execution as pip will download the public package that could contain malicious code. This dependency confusion attack was demonstrated in 2021 by Alex Birsan.
Remediation:
Deployment mitigations
Do not use the --extra-index-url flag with pip and consider using version pinning for deployments.

 [ CVE-2023-5752 ] pip 21.2.3

Description:
When installing a package from a Mercurial VCS URL  (ie "pip install
hg+...") with pip prior to v23.3, the specified Mercurial revision could
be used to inject arbitrary configuration options to the "hg clone"
call (ie "--config"). Controlling the Mercurial configuration can modify
how and which repository is installed. This vulnerability does not
affect users who aren't installing from Mercurial.

 [ CVE-2023-30861 ] flask 1.1.2

Description:
Flask is a lightweight web framework for Python used for building web applications.
An issue arises when using a caching proxy that caches cookies (specifically, the Set-Cookie headers) from responses intended for clients. This situation can result in the proxy sending one client's session cookies to other clients, leading to data leakage or even privilege escalation.
The root cause of this issue is the absence of the Vary: Cookie header, which informs the proxy not to cache session cookies when the session is refreshed (i.e., resent to update the expiration) without being accessed or modified. The Vary: Cookie header is typically set when the session is accessed or modified.
To exploit this vulnerability, several specific conditions must be met:

The application must be hosted behind a proxy that caches responses along with their cookies.
The application must have the session.permanent attribute set to True.
The session must not be accessed or modified before the request is made.
The SESSION_REFRESH_EACH_REQUEST feature must be enabled (which is the default behavior).
The application should not set a Cache-Control header to indicate that a page is private and should not be cached.

Example of vulnerable code:
from flask import Flask, session

app = Flask(__name__)
app.secret_key = 'your_secret_key'

@app.route('/')
def index():
    session.permanent = True
    # Other code logic...
    return privateData(user)

In this example, a Flask application is used, and the session.permanent attribute is set to True. If this application is deployed behind a caching proxy without proper handling of session cookies and caching directives, the issue may be present.
Remediation:
Development mitigations
Add a Cache-Control in all requests/responses sent by the application explicitly instructing the caching proxy not to cache any content:
@app.after_request
def add_cache_control(response):
    response.headers['Cache-Control'] = 'no-store, no-cache, private, must-revalidate, max-age=0'
    return response

Development mitigations
Disable the SESSION_REFRESH_EACH_REQUEST setting of the Flask application:
app = Flask(__name__)
app.config['SESSION_REFRESH_EACH_REQUEST'] = False

 [ CVE-2022-40897 ] setuptools 57.4.0

Description:
Setuptools is a package for managing Python packages and dependencies, including tools for building and distributing packages, as well as for discovering and managing 3rd party packages available on PyPI.
The find_external_links function in the setuptools.package_index module is used to find external links that are associated with a package available on the Python Package Index (PyPI). These external links are typically URLs to the package's homepage, documentation, source code repository, and other resources that are related to the package.
The most common scenario of triggering this issue is when running pip with the --editable flag. This will cause the vulnerable find_external_links function to be invoked
Example of manual usage of find_external_links -
from setuptools.package_index import PackageIndex
import requests

# Specify the URL of the package page on PyPI
url = 'https://pypi.org/project/requests'

# Use the requests library to retrieve the HTML content of the package page
response = requests.get(url)

# Create an instance of the PackageIndex class
index = PackageIndex()

# Use the find_external_links function to find external links for the package
links = index.find_external_links(url, response.text)

# Print the name and URL of each external link
for link_name, link_url in links:
    print(f'{link_name}: {link_url}')

This example will find and print all external links for a package.
To find a specific url, i.e. the tag containing the rel= property, the find_external_links function uses a Regular Expression (regex). The regex is too not efficient which can lead to ReDoS on specific user inputs.
As a result, a user fetching malicious HTML from a package in PyPI or a custom PackageIndex page may be attacked.

 [ CVE-2022-29361 ] werkzeug 1.0.1

Description:
Improper parsing of HTTP requests in Pallets Werkzeug v2.1.0 and below allows attackers to perform HTTP Request Smuggling using a crafted HTTP request with multiple requests included inside the body. NOTE: the vendor's position is that this behavior can only occur in unsupported configurations involving development mode and an HTTP server from outside the Werkzeug project

 [ CVE-2018-20225 ] pip 21.2.3

Description:
This CVE refers to the possibility of a "dependency confusion" attack when using pip with the --extra-index-url flag. This vulnerability has been disputed by the maintainers of pip as the described behavior is intended (although potentially insecure) and as such there are no plans to fix it.
If pip is executed with the --extra-index-url when using a private PyPI repository, an attacker could cause pip to download a private package (for example one named private_package) by adding a package with the same name (private_package) in the public PyPI repository. This would lead to remote code execution as pip will download the public package that could contain malicious code. This dependency confusion attack was demonstrated in 2021 by Alex Birsan.
Remediation:
Deployment mitigations
Do not use the --extra-index-url flag with pip and consider using version pinning for deployments.

 [ CVE-2023-46136 ] werkzeug 1.0.1

Description:
Werkzeug is a comprehensive WSGI web application library. If an upload of a file that starts with CR or LF and then is followed by megabytes of data without these characters: all of these bytes are appended chunk by chunk into internal bytearray and lookup for boundary is performed on growing buffer. This allows an attacker to cause a denial of service by sending crafted multipart data to an endpoint that will parse it. The amount of CPU time required can block worker processes from handling legitimate requests. This vulnerability has been patched in version 3.0.1.

 [ CVE-2024-22195 ] jinja2 2.11.3

Description:
Jinja is an extensible templating engine. Special placeholders in the template allow writing code similar to Python syntax. It is possible to inject arbitrary HTML attributes into the rendered HTML template, potentially leading to Cross-Site Scripting (XSS). The Jinja xmlattr filter can be abused to inject arbitrary HTML attribute keys and values, bypassing the auto escaping mechanism and potentially leading to XSS. It may also be possible to bypass attribute validation checks if they are blacklist-based.

 [ CVE-2023-23934 ] werkzeug 1.0.1

Description:
Werkzeug is a comprehensive WSGI web application library. Browsers may allow "nameless" cookies that look like =value instead of key=value. A vulnerable browser may allow a compromised application on an adjacent subdomain to exploit this to set a cookie like =__Host-test=bad for another subdomain. Werkzeug prior to 2.2.3 will parse the cookie =__Host-test=bad as __Host-test=bad`. If a Werkzeug application is running next to a vulnerable or malicious subdomain which sets such a cookie using a vulnerable browser, the Werkzeug application will see the bad cookie value but the valid cookie key. The issue is fixed in Werkzeug 2.2.3.

 [ CVE-2023-5752 ] pip 21.2.3

Description:
When installing a package from a Mercurial VCS URL  (ie "pip install
hg+...") with pip prior to v23.3, the specified Mercurial revision could
be used to inject arbitrary configuration options to the "hg clone"
call (ie "--config"). Controlling the Mercurial configuration can modify
how and which repository is installed. This vulnerability does not
affect users who aren't installing from Mercurial.

 [ CVE-2023-25577 ] werkzeug 1.0.1

Description:
Werkzeug is a comprehensive WSGI web application library. Prior to version 2.2.3, Werkzeug's multipart form data parser will parse an unlimited number of parts, including file parts. Parts can be a small amount of bytes, but each requires CPU time to parse and may use more memory as Python data. If a request can be made to an endpoint that accesses request.data, request.form, request.files, or request.get_data(parse_form_data=False), it can cause unexpectedly high resource usage. This allows an attacker to cause a denial of service by sending crafted multipart data to an endpoint that will parse it. The amount of CPU time required can block worker processes from handling legitimate requests. The amount of RAM required can trigger an out of memory kill of the process. Unlimited file parts can use up memory and file handles. If many concurrent requests are sent continuously, this can exhaust or kill all available workers. Version 2.2.3 contains a patch for this issue.

 [ CVE-2022-40897 ] setuptools 57.4.0

Description:
Setuptools is a package for managing Python packages and dependencies, including tools for building and distributing packages, as well as for discovering and managing 3rd party packages available on PyPI.
The find_external_links function in the setuptools.package_index module is used to find external links that are associated with a package available on the Python Package Index (PyPI). These external links are typically URLs to the package's homepage, documentation, source code repository, and other resources that are related to the package.
The most common scenario of triggering this issue is when running pip with the --editable flag. This will cause the vulnerable find_external_links function to be invoked
Example of manual usage of find_external_links -
from setuptools.package_index import PackageIndex
import requests

# Specify the URL of the package page on PyPI
url = 'https://pypi.org/project/requests'

# Use the requests library to retrieve the HTML content of the package page
response = requests.get(url)

# Create an instance of the PackageIndex class
index = PackageIndex()

# Use the find_external_links function to find external links for the package
links = index.find_external_links(url, response.text)

# Print the name and URL of each external link
for link_name, link_url in links:
    print(f'{link_name}: {link_url}')

This example will find and print all external links for a package.
To find a specific url, i.e. the tag containing the rel= property, the find_external_links function uses a Regular Expression (regex). The regex is too not efficient which can lead to ReDoS on specific user inputs.
As a result, a user fetching malicious HTML from a package in PyPI or a custom PackageIndex page may be attacked.

🐸 JFrog Frogbot

repo: eranturgeman/flask-webgoat


text:
Add iamb

Thx!

source: gharchive/pull-request

authors: austinbutler erikw

license: MIT

license_type: permissive

license_source: github-api


text:
How do i use this.

install npm
run npm i
run npm run start

source: gharchive/issue

authors: EnderActually ethanaobrien

repo: ethanaobrien/web-proxy


text:
Make system panel read only

@TheAndrewJackson is this done?

@rsilvery Yes, I have a branch with this work finished. This was waiting on the schema changes to get merged into main. I can open a PR for this now.

moving to done

authors: Kelsey-Ethyca Roger-Ethyca TheAndrewJackson rsilvery

repo: ethyca/fides


text:
E2E implementation

Qovery can create a Preview Environment for this PR.
To trigger its creation, please post a comment with one of the following command.

Command
Blueprint environment

/qovery  preview 13a77fc7-ab42-4472-b9a2-15ee0346f6f0
blueprint

/qovery  preview {all|UUID1,UUID2,...}
To preview multiple environments

This comment has been generated from Qovery AI :robot:.
Below, a word from its wisdom :

Write comments that add new information that doesn’t exist in the code

Qovery can create a Preview Environment for this PR.
To trigger its creation, please post a comment with one of the following command.

Command
Blueprint environment

/qovery  preview 13a77fc7-ab42-4472-b9a2-15ee0346f6f0
blueprint

/qovery  preview {all|UUID1,UUID2,...}
To preview multiple environments

This comment has been generated from Qovery AI :robot:.
Below, a word from its wisdom :

Don’t Sacrifice Readability, you are going to debug it in 6 months

repo: evoxmusic/todo-demo-app