Skip to content

Latest commit

 

History

History
238 lines (223 loc) · 22.6 KB

vulnerabilities-workflow-1.md

File metadata and controls

238 lines (223 loc) · 22.6 KB

Here is the combined list of vulnerabilities in markdown format, with duplicates removed:

Vulnerability List

1. Cross-Site Scripting (XSS) vulnerability in SQL query display

  • Description: An attacker can craft a malicious SQL query that, when displayed in the Silk UI, executes arbitrary JavaScript code in the victim's browser. This is possible because the SQL query content is not properly sanitized before being displayed in the SQL detail view. An administrator viewing the Silk UI could be compromised if a malicious SQL query is logged. Steps to trigger:
    1. An attacker needs to trigger the logging of a malicious SQL query.
    2. The malicious SQL query string should contain JavaScript code disguised within the query.
    3. An administrator logs into the Silk UI and navigates to the SQL detail view for the request that triggered the malicious query.
    4. When the SQL detail page renders, the unsanitized malicious SQL query is displayed, and the JavaScript code embedded within it is executed in the administrator's browser.
  • Impact: Cross-Site Scripting (XSS). If an administrator views the malicious SQL query, arbitrary JavaScript code can be executed in their browser within the context of the Silk UI. This could lead to session hijacking, account takeover, or other malicious actions performed on behalf of the administrator.
  • Vulnerability Rank: High
  • Currently Implemented Mitigations: None
  • Missing Mitigations: Implement output sanitization/escaping in the template silk/templates/silk/sql_detail.html for sql_query.formatted_query.
  • Preconditions: Django-silk is installed and enabled in a Django project. An attacker can somehow cause a malicious SQL query to be logged by django-silk. An administrator with access to the Silk UI views the SQL detail page containing the malicious query.
  • Source Code Analysis: Template silk/templates/silk/sql_detail.html renders sql_query.formatted_query without any sanitization. sql_query.formatted_query is obtained from sqlparse.format(self.query, reindent=True, keyword_case='upper') in silk/models.py, which does not sanitize HTML characters.
  • Security Test Case:
    1. Craft a malicious SQL query string containing JavaScript code: SELECT '<img src=x onerror=alert(\'XSS\')>' AS malicious_query;
    2. Execute this malicious SQL query in the monitored Django application to ensure it gets logged by django-silk.
    3. Log in to the Silk UI as an administrator.
    4. Navigate to the "Requests" view in the Silk UI.
    5. Find the request that corresponds to the execution of the malicious SQL query.
    6. Click on the request to view its details and then go to the "SQL" tab.
    7. Click on the SQL query to view its details.
    8. Observe that an alert box appears in your browser, confirming the XSS vulnerability.

2. Potential Cross-Site Scripting (XSS) vulnerability in raw request/response body display

  • Description: An attacker could potentially inject malicious JavaScript code within the raw request or response body of an HTTP request handled by the monitored application. If an administrator views the raw body in the Silk UI, this JavaScript code could be executed in their browser due to insufficient sanitization of the raw body content before rendering in the silk/raw.html template. Steps to trigger:
    1. An attacker needs to send a request to the monitored application with a malicious JavaScript payload embedded in the request body or trigger a response with a malicious payload.
    2. The malicious JavaScript code should be embedded within the raw body.
    3. An administrator logs into the Silk UI and navigates to the request detail view.
    4. The administrator views the raw request or response body by navigating to the "Raw" tab.
    5. When the raw body is rendered in silk/raw.html, and if it's unsanitized, the JavaScript code is executed.
  • Impact: Cross-Site Scripting (XSS). If an administrator views the raw request or response body containing malicious JavaScript, arbitrary JavaScript code can be executed in their browser within the context of the Silk UI, potentially leading to session hijacking, account takeover.
  • Vulnerability Rank: High
  • Currently Implemented Mitigations: Unknown. Assumed none.
  • Missing Mitigations: Implement output sanitization/escaping in silk/templates/silk/raw.html for the body variable.
  • Preconditions: Django-silk is installed and enabled. An attacker can inject malicious JavaScript into the raw request or response body. An administrator with access to the Silk UI views the raw body.
  • Source Code Analysis: The Raw view in silk/views/raw.py passes the body variable to silk/raw.html without sanitization. Assuming silk/raw.html renders body directly without sanitization.
  • Security Test Case:
    1. Craft a malicious JS payload in the response body, e.g., a JSON response: {"data": "<img src=x onerror=alert('XSS_RAW_BODY')>"}.
    2. Trigger a request to an endpoint in the monitored application that returns this malicious response.
    3. Log in to the Silk UI as an administrator.
    4. Navigate to the "Requests" view.
    5. Find the request corresponding to the endpoint returning the malicious response.
    6. Click on the request to view details and go to the "Raw" tab.
    7. Select 'response' and 'raw' in the dropdowns.
    8. Observe if an alert box appears, confirming XSS in raw body display.

3. Unauthenticated Access to Profiling and Inspection Interface

  • Vulnerability Name: Unauthenticated Access to Profiling and Inspection Interface
  • Description: An external attacker can directly navigate to any Silk UI endpoint (by default mounted under “/silk/”) without any authentication. An attacker can view detailed profiling data including intercepted HTTP requests and responses, database queries (with timings and even the raw SQL), request headers (which may include sensitive cookies or API tokens) and even sampled stack traces.
  • Impact: Attackers may learn internal data about application logic, database structure and query performance, helping them refine further attacks such as targeted injections or remote code execution exploits.
  • Vulnerability Rank: High
  • Currently Implemented Mitigations:
    • Optional configuration settings (e.g. SILKY_AUTHENTICATION and SILKY_AUTHORISATION) exist in the Silk config.
    • Authentication/authorisation decorators (e.g. login_possibly_required) are present in the codebase but are no‑ops when the corresponding flags are disabled.
  • Missing Mitigations:
    • By default, both authentication and authorisation for the Silk UI are disabled.
    • No built‑in CSRF protection or enforced access control exists unless developers explicitly enable these settings.
  • Preconditions: The application is deployed in a publicly accessible environment with the default Silk settings (debug/profiling enabled and no authentication).
  • Source Code Analysis:
    • The README and configuration documents state that “by default anybody can access the Silk user interface by heading to /silk/.”
    • In silk/middleware.py and various view modules (e.g. silk/views/summary.py), the authentication decorators are implemented as pass‑through functions unless the settings flags are turned on.
  • Security Test Case:
    1. Using an external HTTP client (such as cURL or a web browser), send a GET request to an endpoint under /silk/ (for example, http://<target_host>/silk/).
    2. Verify that the response returns the Silk summary page or other sensitive profiling details (headers, SQL timings, etc.) without any authentication prompt.
    3. Repeat for endpoints like /silk/request/<uuid>/ and /silk/cleardb/ to confirm that no access control is enforced.

4. Unauthenticated Access to Administrative Data Deletion Endpoint

  • Vulnerability Name: Unauthenticated Access to Administrative Data Deletion Endpoint
  • Description: The Silk project provides a “clear DB” view (mounted at “/silk/cleardb/”) which allows an administrator to purge all logged requests and profiling data. By default this endpoint is unprotected, and an attacker who discovers it may submit a POST request to delete critical diagnostic and forensic data.
  • Impact: An attacker could sabotage system diagnostics and security investigations by wiping out historical logs, making it harder to detect and analyze more severe attacks later.
  • Vulnerability Rank: High
  • Currently Implemented Mitigations:
    • The view uses optional authentication/authorisation wrappers (via decorators like login_possibly_required) that only enforce checks when configuration flags are enabled.
  • Missing Mitigations:
    • With the default configuration (SILKY_AUTHENTICATION and SILKY_AUTHORISATION off), no authentication check is performed.
    • No additional confirmation prompt or audit logging exists to help prevent inadvertent or malicious deletion of log data.
  • Preconditions: The application is deployed with the default Silk settings in a production or publicly accessible environment, leaving the “/silk/cleardb/” endpoint fully open.
  • Source Code Analysis:
    • In silk/views/clear_db.py, the GET handler displays a confirmation page and the POST handler checks for a simple form field (e.g. clear_all=on), then deletes data from multiple models without verifying the user’s identity.
    • The authentication decorators are no‑ops when the related settings are not enabled.
  • Security Test Case:
    1. Using an HTTP client, send a POST request to http://<target_host>/silk/cleardb/ with the form parameter clear_all=on.
    2. Confirm that the response indicates the Silk logging data has been deleted.
    3. Optionally, verify via the Silk UI or the database that the log records have been cleared.

5. Debug Mode Enabled in Production

  • Vulnerability Name: Debug Mode Enabled in Production
  • Description: The Django application’s settings (in /code/project/project/settings.py) specify DEBUG = True and DEBUG_PROPAGATE_EXCEPTIONS = True. When deployed in production, these settings cause detailed error pages—including stack traces and sensitive configuration data—to be shown when errors occur. An external attacker can deliberately trigger errors (for example, by accessing non-existent URLs) to obtain internal system details.
  • Impact: Detailed disclosure of internal application state, configuration settings, and potentially sensitive data (such as database credentials and the secret key) can facilitate targeted attacks including session forgery, remote code execution, and privilege escalation.
  • Vulnerability Rank: High
  • Currently Implemented Mitigations: None; the default settings hardcode DEBUG = True for development purposes.
  • Missing Mitigations:
    • In production, DEBUG should be set to False and DEBUG_PROPAGATE_EXCEPTIONS adjusted accordingly.
    • Use environment variables or dedicated configuration management to ensure production settings do not expose sensitive information.
  • Preconditions: The application is deployed using the project’s default settings, leaving it in development mode in a publicly accessible environment.
  • Source Code Analysis:
    • In /code/project/project/settings.py, the values DEBUG = True and DEBUG_PROPAGATE_EXCEPTIONS = True are explicitly set.
    • This configuration ensures that any unhandled exception will render a detailed debug page with stack traces and internal data.
  • Security Test Case:
    1. Deploy the application with the default settings.
    2. Use a web browser or HTTP client (like cURL) to deliberately trigger an error (e.g., request a non-existent URL such as http://<target_host>/nonexistent).
    3. Examine the returned error page and verify that it contains detailed debug information including stack traces, configuration variables, and possibly the SECRET_KEY.
    4. Confirm that this sensitive information is exposed to the attacker.

6. Hard-Coded Secret Key in Application Settings

  • Vulnerability Name: Hard-Coded Secret Key in Application Settings
  • Description: The application’s settings file (/code/project/project/settings.py) defines a fixed SECRET_KEY that is embedded directly in the source code. If this key is ever exposed—especially via debug error pages when DEBUG = True—an attacker could use it to forge session cookies, tamper with cryptographic signatures, and bypass security controls.
  • Impact: Exposure of the hard-coded secret key can allow an attacker to impersonate users (by forging cookies or tokens) and compromise session integrity, which might lead to unauthorized actions or access escalation.
  • Vulnerability Rank: High
  • Currently Implemented Mitigations: There are no runtime safeguards to protect the embedded secret key; it is stored in the settings file and committed to source control.
  • Missing Mitigations: The secret key should not be hard-coded. Instead, it should be injected via secure external sources such as environment variables or a secrets management service.
  • Preconditions: The application must be deployed using the default settings, and debug mode (or similar functionality) must allow internal configuration details (including the SECRET_KEY) to be revealed during error conditions.
  • Source Code Analysis:
    • In /code/project/project/settings.py, the SECRET_KEY is defined as: SECRET_KEY = 'ey5!m&h-uj6c7dzp@(o1%96okkq4!&bjja%oi*v3r=2t(!$7os' This hard-coded key is permanently stored in the source code with no alternative configuration mechanism.
  • Security Test Case:
    1. Deploy the application with the provided settings.
    2. Trigger an application error (for example, by accessing a non-existent URL) that causes the debug error page to be displayed.
    3. Inspect the error page to verify whether the SECRET_KEY is visible in the configuration details.
    4. Optionally, attempt to use the disclosed key to craft forged session cookies and determine if the application accepts them as valid.

7. Local File Inclusion in SQL and Profile Detail Views

  • Vulnerability Name: Local File Inclusion in SQL and Profile Detail Views

  • Description:

    1. An attacker can access the Silk UI, assuming authentication and authorization are either disabled or bypassed.
    2. The attacker navigates to the SQL detail view for any captured SQL query (e.g., /silk/request/<request_id>/sql/<sql_id>/) or the Profile detail view for any captured profile (e.g., /silk/profile/<profile_id>/).
    3. In both SQL and Profile detail views, the traceback might be displayed with file paths. These file paths are made clickable by the filepath_urlify template filter, pointing to the respective detail view but with file_path and line_num parameters in the URL.
    4. An attacker can manually craft a URL to either the SQL or Profile detail view, adding file_path and line_num GET parameters with arbitrary file paths on the server.
    5. The application, in silk/views/code.py's _code function, directly opens and reads the file specified by the file_path parameter without any validation or sanitization. This function is called by both silk/views/sql_detail.py's SQLDetailView and silk/views/profile_detail.py's ProfilingDetailView.
    6. The content of the file is then displayed in the respective detail view within the "Code" section.

  • Impact: An external attacker can read arbitrary files from the server's filesystem that the Django application has read permissions to. This could include sensitive source code, configuration files, data files, or environment variables, potentially leading to full server compromise or data breaches.

  • Vulnerability Rank: High

  • Currently Implemented Mitigations: None. The application directly opens and reads files based on user-provided input without validation in both SQL and Profile detail views.

  • Missing Mitigations:

    • Input validation and sanitization for the file_path parameter in silk/views/code.py's _code function, silk/views/sql_detail.py's SQLDetailView, and silk/views/profile_detail.py's ProfilingDetailView.
    • Implement proper access control to the Silk UI to restrict access to authorized users only. Enabling SILKY_AUTHENTICATION and SILKY_AUTHORISATION settings and configuring SILKY_PERMISSIONS to restrict access to staff or superuser accounts is crucial.

  • Preconditions:

    • Silk is installed and enabled in a Django project.
    • The Silk UI is accessible to the attacker (either SILKY_AUTHENTICATION and SILKY_AUTHORISATION are disabled, or the attacker has bypassed authentication/authorization).
    • For SQL detail view: There must be at least one SQL query captured by Silk to access the SQL detail view initially and obtain a valid URL structure to modify.
    • For Profile detail view: There must be at least one profile captured by Silk to access the Profile detail view initially and obtain a valid URL structure to modify.

  • Source Code Analysis:

    1. File: /code/silk/views/sql_detail.py

      from silk.views.code import _code

class SQLDetailView(View):
    # ...
    def get(self, request, *_, **kwargs):
        # ...
        file_path = request.GET.get('file_path', '')
        line_num = int(request.GET.get('line_num', 0))
        # ...
        if pos and file_path and line_num:
            actual_line, code = _code(file_path, line_num) # [!] file_path from request.GET is passed directly to _code
            context['code'] = code
            context['actual_line'] = actual_line
        return render(request, 'silk/sql_detail.html', context)

      The SQLDetailView retrieves the file_path parameter directly from the GET request and passes it to the _code function.

    2. File: /code/silk/views/profile_detail.py

      from silk.views.code import _code_context, _code_context_from_request
...
class ProfilingDetailView(View):
    # ...
    def get(self, request, *_, **kwargs):
        # ...
        context['pos'] = pos = int(request.GET.get('pos', 0))
        if pos:
            context.update(_code_context_from_request(request, prefix='pyprofile_')) # [!] Calls _code_context_from_request which uses _code
...
        if file_path and line_num:
            try:
                context.update(_code_context(file_path, line_num, profile.end_line_num)) # [!] Calls _code_context which uses _code
            except OSError as e:
                ...

      The ProfilingDetailView also uses _code_context_from_request and _code_context, both of which eventually call the vulnerable _code function with user-controlled file_path.

    3. File: /code/silk/views/code.py

      from silk.config import SilkyConfig

def _code(file_path, line_num, end_line_num=None):
    # ...
    with open(file_path, encoding='utf-8') as f: # [!] file_path is opened without validation
        # ...
        for i, line in enumerate(f):
            if i in r:
                lines += line
            if i + 1 in range(line_num, end_line_num + 1):
                actual_line.append(line)
    code = lines.split('\n')
    return actual_line, code

      The _code function directly uses the file_path argument in open(file_path, encoding='utf-8') without any validation.

    4. Visualization:

      graph LR
    A[User crafts malicious URL with file_path (SQL or Profile Detail)] --> B(SQLDetailView.get / ProfilingDetailView.get);
    B --> C{request.GET.get('file_path')};
    C -- file_path --> D[_code(file_path, line_num)];
    D --> E{open(file_path)};
    E --> F[Read arbitrary file content];
    F --> G(Display file content in Detail View);
    G --> H[Attacker views content];
      Loading

  • Security Test Case:

    1. Deploy a Django application with django-silk installed and configured (ensure SILKY_AUTHENTICATION and SILKY_AUTHORISATION are disabled for easy testing, but in a real-world scenario, test after bypassing authentication).
    2. Trigger any Django view that executes at least one SQL query and one profile to ensure there is data in Silk.
    3. Access the Silk UI (e.g., /silk/).
    4. For SQL Detail View: a. Navigate to the "Requests" tab and select any request. b. Go to the "SQL" tab for the selected request and click on any SQL query to view its details. This will lead you to the SQL detail view (e.g., /silk/request/<request_id>/sql/<sql_id>/). c. Observe the URL of the SQL detail page. It should look something like /silk/request/<request_id>/sql/<sql_id>/. d. Manually modify the URL by adding the file_path and line_num parameters. For example, to attempt to read /etc/passwd, construct a URL like: /silk/request/<request_id>/sql/<sql_id>/?file_path=/etc/passwd&line_num=1. e. Access the crafted URL in your browser. f. Check the "Code" section in the SQL detail view. If the vulnerability exists, you should see the content of the /etc/passwd file (or any other file you attempted to read, assuming the Django application has read permissions). If you are testing on Windows, try to read C:\Windows\win.ini for example. g. If the file content is displayed, the Local File Inclusion vulnerability is confirmed in SQL detail view.
    5. For Profile Detail View: a. Navigate to the "Profiling" tab and select any profile. This will lead you to the Profile detail view (e.g., /silk/profile/<profile_id>/). b. Observe the URL of the Profile detail page. It should look something like /silk/profile/<profile_id>/. c. Manually modify the URL by adding the file_path and line_num parameters. For example, to attempt to read /etc/passwd, construct a URL like: /silk/profile/<profile_id>/?file_path=/etc/passwd&line_num=1. d. Access the crafted URL in your browser. e. Check the "Code" section in the Profile detail view. If the vulnerability exists, you should see the content of the /etc/passwd file (or any other file you attempted to read, assuming the Django application has read permissions). If you are testing on Windows, try to read C:\Windows\win.ini for example. f. If the file content is displayed, the Local File Inclusion vulnerability is confirmed in Profile detail view.
    6. If the file content is displayed in either SQL or Profile detail view, the Local File Inclusion vulnerability is confirmed.