Skip to content

Latest commit

 

History

History
103 lines (78 loc) · 6.42 KB

mitigations.md

File metadata and controls

103 lines (78 loc) · 6.42 KB

Mitigation Strategies Analysis for wailsapp/wails

Mitigation Strategy: Strict Input Validation (Wails Bridge)

1. Strict Input Validation (Wails Bridge)

  • Description:

    1. Backend (Go):
      • Treat all data received from the frontend (via Wails bindings) as untrusted.
      • Implement rigorous validation in Go for every piece of data received. This is your primary defense.
      • Validate:
        • Type: Ensure data is the expected type (string, int, etc.) using Go's type system and strconv.
        • Length: Enforce maximum string lengths using len().
        • Format: Use regular expressions (regexp) for email, URLs, etc.
        • Range: Check numerical values for acceptable ranges.
        • Whitelist: Define allowed values and reject anything else. Never blacklist.
      • Return clear, non-revealing error messages to the frontend on failure.
      • Log validation failures.
    2. Frontend (JavaScript):
      • Use HTML5 form validation attributes (required, pattern, min, max, type).
      • Implement JavaScript validation before sending data. Use libraries or custom functions.
      • Provide immediate user feedback.
      • Never rely solely on frontend validation; it's a convenience, not a security measure.

  • Threats Mitigated:

    • Cross-Site Scripting (XSS) (Severity: High): Prevents malicious JavaScript injection via the Wails bridge.
    • SQL Injection (Severity: High): Prevents manipulation of database queries if data from the bridge is used in queries.
    • Command Injection (Severity: High): Prevents execution of arbitrary commands if data from the bridge is used in system calls.
    • Denial of Service (DoS) (Severity: Medium): Prevents large inputs from overwhelming the Go backend.
    • Data Corruption (Severity: Medium): Ensures data integrity.
    • Business Logic Errors (Severity: Variable): Prevents unexpected behavior.

  • Impact:

    • XSS, SQL Injection, Command Injection: Significantly reduces risk (backend validation is crucial).
    • DoS, Data Corruption: Reduces risk.

  • Currently Implemented:

    • Frontend: Basic HTML5 validation on some forms. JavaScript validation for email in userRegistration.js.
    • Backend: Type checking and length limits in CreateUser (user.go). Regex for email.

  • Missing Implementation:

    • Frontend: Comprehensive JavaScript validation is incomplete. Missing validation for phone/address.
    • Backend: Missing range checks (age, quantity). Missing whitelisting (user roles). No centralized validation; logic is scattered.

Mitigation Strategy: Minimize Exposed Functionality (Wails Bindings)

2. Minimize Exposed Functionality (Wails Bindings)

  • Description:

    1. Review Bindings: Carefully examine all Go functions exposed to the JavaScript frontend via Wails bindings.
    2. Identify Essentials: Determine which functions are absolutely necessary for frontend operation.
    3. Remove Unnecessary: Remove or comment out any non-essential bindings. Each exposed function is a potential attack vector.
    4. Refactor for Least Privilege: Split large functions into smaller, specific ones with minimal privileges.
    5. Document: Clearly document the purpose and behavior of each exposed function.

  • Threats Mitigated:

    • Arbitrary Code Execution (Severity: High): Reduces the attack surface by limiting entry points.
    • Information Disclosure (Severity: Medium): Reduces risk of exposing sensitive data via unintended calls.
    • Privilege Escalation (Severity: High): Reduces risk of unauthorized access to sensitive operations.

  • Impact:

    • All Threats: Reduces overall attack surface and likelihood of exploitation.

  • Currently Implemented:

    • Some effort to limit functions, but no comprehensive review.

  • Missing Implementation:

    • Thorough review of all Wails bindings needed. utils.go has exposed, seemingly unused functions.
    • No clear documentation of the exposed API.

Mitigation Strategy: Wails-Specific Configuration

3. Wails-Specific Configuration

  • Description:

    1. Review wails.json: Carefully examine all options in the wails.json configuration file.
    2. Review options Struct: Understand the security implications of each option in the options struct used when creating the Wails application.
    3. Disable Unneeded Features: Disable any Wails features you don't require.
    4. Disable Developer Tools (Production): Ensure developer tools (browser console) are disabled in production builds. Wails provides options for this.
    5. Hide Wails Version: Remove or obfuscate information revealing the Wails version.
    6. Frontend: Disable Node.js Integration (if not needed): If your frontend does not require Node.js integration, disable it explicitly in the Wails configuration. This reduces the attack surface significantly.

  • Threats Mitigated:

    • Information Disclosure (Severity: Medium): Prevents attackers from gaining information about the Wails version and configuration.
    • Arbitrary Code Execution (Severity: High): Disabling developer tools prevents attackers from using them to inject code. Disabling Node.js integration (if not used) removes a large attack surface.
    • Exploitation of Known Vulnerabilities (Severity: Variable): Hiding the Wails version makes it harder to target known vulnerabilities.

  • Impact:

    • Information Disclosure: Reduces risk.
    • Arbitrary Code Execution: Significantly reduces risk if developer tools are disabled and Node.js integration is not needed and disabled.
    • Exploitation of Known Vulnerabilities: Reduces risk.

  • Currently Implemented:

    • Developer tools are disabled in production builds.

  • Missing Implementation:

    • No explicit hiding of the Wails version.
    • Node.js integration is enabled, but the frontend doesn't actually use it. This should be disabled.
    • A full review of wails.json and the options struct for security implications hasn't been done.