Skip to content

Latest commit

 

History

History
150 lines (114 loc) · 14.9 KB

File metadata and controls

150 lines (114 loc) · 14.9 KB

Attack Tree Analysis for blueimp/jquery-file-upload

Objective: Execute Arbitrary Code on Server via File Upload

Attack Tree Visualization

Attack Goal: Execute Arbitrary Code on Server via File Upload

    OR

    [HIGH RISK PATH] 1. Exploit Server-Side Vulnerabilities in File Handling [CRITICAL NODE]
        AND
        [HIGH RISK PATH] 1.1. Bypass File Type Restrictions [CRITICAL NODE]
            OR
            [CRITICAL NODE] 1.1.1. Filename Extension Manipulation (e.g., rename malicious.txt.php to malicious.php)
            OR
            [CRITICAL NODE] 1.1.2. MIME Type Spoofing (e.g., change Content-Type header to image/jpeg for a PHP file)
            OR
            [CRITICAL NODE] 1.1.3. Double Extension Bypass (e.g., malicious.php.jpg if server only checks last extension)
        AND
        [HIGH RISK PATH] 1.2. Upload Malicious File Type [CRITICAL NODE]
            OR
            [CRITICAL NODE] 1.2.1. Upload Server-Side Script (e.g., PHP, JSP, ASPX, Python, etc.)
        AND
        [HIGH RISK PATH] 1.3. Server-Side Execution of Uploaded File [CRITICAL NODE]
            OR
            [CRITICAL NODE] 1.3.1. Upload directory is within web root and server is configured to execute scripts from it.
            OR
            [CRITICAL NODE] 1.3.2. Server-side processing logic (e.g., image processing, file conversion) has vulnerabilities that are triggered by malicious file content.

    OR

    [HIGH RISK PATH] 2. Exploit Client-Side Vulnerabilities (Less Direct for Server Code Execution, but can be chained)
        AND
        [HIGH RISK PATH] 2.1. Cross-Site Scripting (XSS) via Filename or File Content [CRITICAL NODE]
            OR
            [CRITICAL NODE] 2.1.1. Stored XSS via Filename: If filenames are displayed without proper encoding, malicious filenames can inject JavaScript.
            OR
            [CRITICAL NODE] 2.1.2. Stored XSS via File Content: If file content (e.g., HTML, SVG) is displayed without sanitization, malicious content can inject JavaScript.
  • Attack Vector: This is the overarching high-risk path. Attackers target weaknesses in how the server processes uploaded files to achieve code execution. This often involves bypassing client-side and potentially weak server-side file validation and then exploiting how the server handles the uploaded file.
  • Breakdown:
    • Attackers will attempt to upload files that, when processed by the server, will allow them to execute arbitrary commands.
    • This often involves uploading files of types that can be interpreted and executed by the server (e.g., PHP, JSP, ASPX scripts).
    • The success depends on weaknesses in file type validation, server configuration, and server-side processing logic.
  • Attack Vector: Attackers aim to circumvent file type checks implemented by the application or server. If successful, they can upload file types that are normally blocked, including malicious executable scripts.
  • Breakdown:
    • 1.1.1. Filename Extension Manipulation (e.g., rename malicious.txt.php to malicious.php) [CRITICAL NODE]:
      • Attackers rename malicious files to have seemingly harmless extensions (like .txt, .jpg) and then append a server-executable extension (like .php, .jsp).
      • If the server only checks the last extension or is misconfigured, it might execute the file as a script.
    • 1.1.2. MIME Type Spoofing (e.g., change Content-Type header to image/jpeg for a PHP file) [CRITICAL NODE]:
      • Attackers manipulate the Content-Type header in the HTTP request to falsely declare the file type (e.g., claiming a PHP script is an image).
      • If the server relies solely on the Content-Type header for validation, it can be tricked into accepting and processing malicious files.
    • 1.1.3. Double Extension Bypass (e.g., malicious.php.jpg if server only checks last extension) [CRITICAL NODE]:
      • Attackers use filenames with multiple extensions, where the last extension is benign (e.g., .jpg, .png) and the preceding extension is executable (e.g., .php).
      • If the server's validation logic only checks the very last extension, it might bypass the check, allowing the file to be uploaded and potentially executed.
  • 1.1.1. Filename Extension Manipulation (e.g., rename malicious.txt.php to malicious.php) [CRITICAL NODE]: * Attackers rename malicious files to have seemingly harmless extensions (like .txt, .jpg) and then append a server-executable extension (like .php, .jsp). * If the server only checks the last extension or is misconfigured, it might execute the file as a script.
  • 1.1.2. MIME Type Spoofing (e.g., change Content-Type header to image/jpeg for a PHP file) [CRITICAL NODE]: * Attackers manipulate the Content-Type header in the HTTP request to falsely declare the file type (e.g., claiming a PHP script is an image). * If the server relies solely on the Content-Type header for validation, it can be tricked into accepting and processing malicious files.
  • 1.1.3. Double Extension Bypass (e.g., malicious.php.jpg if server only checks last extension) [CRITICAL NODE]: * Attackers use filenames with multiple extensions, where the last extension is benign (e.g., .jpg, .png) and the preceding extension is executable (e.g., .php). * If the server's validation logic only checks the very last extension, it might bypass the check, allowing the file to be uploaded and potentially executed.
  • Attack Vector: Once file type restrictions are bypassed (or if they are weak to begin with), attackers upload files specifically designed to be malicious when processed by the server.
  • Breakdown:
    • 1.2.1. Upload Server-Side Script (e.g., PHP, JSP, ASPX, Python, etc.) [CRITICAL NODE]:
      • Attackers upload files containing server-side scripting code (e.g., PHP, JSP, ASPX, Python).
      • If the server executes these scripts, the attacker gains the ability to run arbitrary commands on the server, potentially leading to full system compromise.
  • 1.2.1. Upload Server-Side Script (e.g., PHP, JSP, ASPX, Python, etc.) [CRITICAL NODE]: * Attackers upload files containing server-side scripting code (e.g., PHP, JSP, ASPX, Python). * If the server executes these scripts, the attacker gains the ability to run arbitrary commands on the server, potentially leading to full system compromise.
  • Attack Vector: This focuses on the conditions that lead to the server actually executing the uploaded malicious file. Even if a malicious file is uploaded, it needs to be executed to cause harm.
  • Breakdown:
    • 1.3.1. Upload directory is within web root and server is configured to execute scripts from it. [CRITICAL NODE]:
      • If the directory where uploaded files are stored is within the web server's document root (accessible via web URLs) and the server is configured to execute scripts in that directory (e.g., PHP scripts), then accessing the uploaded malicious script via a web browser will trigger its execution.
      • This is a common misconfiguration and a critical vulnerability.
    • 1.3.2. Server-side processing logic (e.g., image processing, file conversion) has vulnerabilities that are triggered by malicious file content. [CRITICAL NODE]:
      • If the application performs server-side processing on uploaded files (e.g., resizing images, converting file formats), vulnerabilities in the libraries or code used for this processing can be exploited by crafting malicious file content.
      • For example, image processing libraries might have buffer overflow vulnerabilities that can be triggered by specially crafted image files, leading to code execution.
  • 1.3.1. Upload directory is within web root and server is configured to execute scripts from it. [CRITICAL NODE]: * If the directory where uploaded files are stored is within the web server's document root (accessible via web URLs) and the server is configured to execute scripts in that directory (e.g., PHP scripts), then accessing the uploaded malicious script via a web browser will trigger its execution. * This is a common misconfiguration and a critical vulnerability.
  • 1.3.2. Server-side processing logic (e.g., image processing, file conversion) has vulnerabilities that are triggered by malicious file content. [CRITICAL NODE]: * If the application performs server-side processing on uploaded files (e.g., resizing images, converting file formats), vulnerabilities in the libraries or code used for this processing can be exploited by crafting malicious file content. * For example, image processing libraries might have buffer overflow vulnerabilities that can be triggered by specially crafted image files, leading to code execution.
  • Attack Vector: While not directly leading to server-side code execution in the same way as Path 1, client-side vulnerabilities, specifically Cross-Site Scripting (XSS), can be exploited via file uploads. This can be a stepping stone to further attacks, including potentially targeting administrator accounts to pivot to server-side compromise.
  • Breakdown:
    • Attackers exploit vulnerabilities in how the application handles and displays filenames or file content, leading to XSS.
    • XSS can be used to steal user sessions, perform actions on behalf of users, deface the website, or redirect users to malicious sites.
    • If administrator accounts are targeted via XSS, it could potentially lead to server-side compromise if admin privileges are misused or if the admin account has access to sensitive server configurations.
  • Attack Vector: Attackers inject malicious JavaScript code into filenames or file content, which is then executed in the browsers of other users when the filename or content is displayed by the application.
  • Breakdown:
    • 2.1.1. Stored XSS via Filename: If filenames are displayed without proper encoding, malicious filenames can inject JavaScript. [CRITICAL NODE]:
      • Attackers craft filenames that contain JavaScript code.
      • If the application displays these filenames without proper output encoding (e.g., HTML encoding), the JavaScript code in the filename will be executed in the user's browser when the filename is displayed.
    • 2.1.2. Stored XSS via File Content: If file content (e.g., HTML, SVG) is displayed without sanitization, malicious content can inject JavaScript. [CRITICAL NODE]:
      • Attackers upload files containing malicious content, such as HTML or SVG files with embedded JavaScript.
      • If the application displays the content of these files directly without proper sanitization or encoding, the embedded JavaScript will be executed in the user's browser.
  • 2.1.1. Stored XSS via Filename: If filenames are displayed without proper encoding, malicious filenames can inject JavaScript. [CRITICAL NODE]: * Attackers craft filenames that contain JavaScript code. * If the application displays these filenames without proper output encoding (e.g., HTML encoding), the JavaScript code in the filename will be executed in the user's browser when the filename is displayed.
  • 2.1.2. Stored XSS via File Content: If file content (e.g., HTML, SVG) is displayed without sanitization, malicious content can inject JavaScript. [CRITICAL NODE]: * Attackers upload files containing malicious content, such as HTML or SVG files with embedded JavaScript. * If the application displays the content of these files directly without proper sanitization or encoding, the embedded JavaScript will be executed in the user's browser.