Skip to content

Update README.md - #5

Closed
davidka91 wants to merge 4 commits into
mainfrom
dev
Closed

Update README.md#5
davidka91 wants to merge 4 commits into
mainfrom
dev

Conversation

@davidka91

Copy link
Copy Markdown
Owner

No description provided.

@davidka91

Copy link
Copy Markdown
Owner Author

🚨 Frogbot scanned this pull request and found the below:

📗 Scan Summary

  • Frogbot scanned for violations and found 1 issues
Scan Category Status Security Issues
Software Composition Analysis ✅ Done
1 Issues Found 1 High
Contextual Analysis ✅ Done -
Static Application Security Testing (SAST) ✅ Done Not Found
Secrets ✅ Done -
Infrastructure as Code (IaC) ✅ Done Not Found

🚥 Policy Violations

🚨 Security Violations

Severity ID Contextual Analysis Direct Dependencies Impacted Dependency Watch Name
high (not applicable)
High
CVE-2023-30861 Not Applicable flask:2.2.2 flask:2.2.2 dk-a-high

🔖 Details

Violation Details

Policies: proj-hudson
Watch Name: dk-a-high
Jfrog Research Severity: Medium
Contextual Analysis: Not Applicable
Direct Dependencies: flask:2.2.2
Impacted Dependency: flask:2.2.2
Fixed Versions: [2.2.5], [2.3.2]
CVSS V3: 7.5

Persistent session cookies in Flask can lead to data leakage or privilege escalation when the application is hosted behind a caching proxy.

🔬 JFrog Research Details

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

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant