Skip to content

Latest commit

 

History

History
80 lines (67 loc) · 6.2 KB

threat-modeling.md

File metadata and controls

80 lines (67 loc) · 6.2 KB

Threat Model Analysis for ankane/searchkick

Threat: Index Manipulation via Unvalidated Input

  • Threat: Index Manipulation via Unvalidated Input

    • Description: An attacker submits crafted input containing Elasticsearch query DSL or special characters through a form field that is directly indexed by Searchkick without proper sanitization. The attacker could inject commands to alter the index structure, delete documents, or insert malicious data. This directly exploits Searchkick's indexing functionality.
    • Impact:
      • Data corruption or loss within the Elasticsearch index.
      • Exposure of unintended data.
      • Potential for denial of service if the index becomes corrupted or unusable.
      • Potential for code execution (if injected data is later interpreted).
    • Affected Component:
      • searchkick.reindex method (and any other methods that trigger indexing, like record.reindex).
      • Model's search_data method (if it doesn't properly sanitize data).
    • Risk Severity: Critical
    • Mitigation Strategies:
      • Strict Input Validation: Implement rigorous input validation before passing data to Searchkick. Use whitelists, not blacklists.
      • Data Sanitization: Sanitize all data before indexing, escaping or removing special characters. Use a dedicated Elasticsearch sanitization library if available.
      • Data Model Constraints: Enforce data integrity at the database level (defense in depth).

Threat: Sensitive Data Exposure via Search Results

  • Threat: Sensitive Data Exposure via Search Results

    • Description: An attacker crafts search queries that reveal sensitive data that should not be accessible. This happens because fields containing PII, internal IDs, or other confidential information are included in the search_data method without proper access controls, making them directly searchable via Searchkick.
    • Impact:
      • Exposure of Personally Identifiable Information (PII).
      • Leakage of internal system details.
      • Potential for further attacks.
      • Compliance violations.
    • Affected Component:
      • Model's search_data method (defines which fields are searchable).
      • Searchkick.search method (and any methods that perform searches).
      • Application logic that handles search results (must filter results based on user permissions).
    • Risk Severity: Critical
    • Mitigation Strategies:
      • Restrict search_data: Carefully define search_data to only include fields intended for search. Exclude sensitive fields.
      • Access Control Filtering: Implement robust access control within the application to filter search results based on user roles and permissions before returning them. Use Searchkick's where option securely, combined with application-level checks.
      • Query Sanitization: Sanitize user-provided search queries.
      • Field-Level Security (Elasticsearch): If possible, use Elasticsearch's field-level security.
      • Data Masking/Anonymization: Consider masking or anonymizing sensitive data within the index.

Threat: Sensitive Data Exposure via Suggestions

  • Threat: Sensitive Data Exposure via Suggestions

    • Description: An attacker uses the Searchkick suggestions feature to reveal sensitive data based on partial inputs. Suggestions, if not properly filtered, directly leak information through Searchkick's auto-complete functionality.
    • Impact:
      • Exposure of PII or other confidential information through auto-complete suggestions.
      • Inference of sensitive data based on suggestion patterns.
    • Affected Component:
      • Searchkick's suggestions feature (e.g., suggest: true option).
      • Application logic that handles suggestion requests.
    • Risk Severity: High
    • Mitigation Strategies:
      • Disable Suggestions (if not essential): Simplest mitigation.
      • Filtered Suggestions: If required, implement strict filtering based on user permissions and data sensitivity. Ensure suggestions never reveal unauthorized data. This filtering must happen before returning suggestions.
      • Context-Aware Suggestions: Use context-aware suggestions.
      • Rate Limiting: Implement rate limiting on suggestion requests.

Threat: Denial of Service via Resource Exhaustion (Direct Searchkick Usage)

  • Threat: Denial of Service via Resource Exhaustion (Direct Searchkick Usage)

    • Description: An attacker submits a large number of complex or resource-intensive search queries through Searchkick, overwhelming the Elasticsearch cluster. This directly leverages Searchkick's search interface to cause a DoS. While the cluster itself is affected, the attack vector is Searchkick.
    • Impact:
      • Degradation or complete unavailability of the search service.
      • Potential impact on other applications using the same cluster.
    • Affected Component:
      • Searchkick.search method (and any methods that perform searches).
    • Risk Severity: High
    • Mitigation Strategies:
      • Rate Limiting: Implement rate limiting on search requests at the application level, specifically targeting Searchkick usage (per user, per IP, etc.).
      • Query Optimization: Optimize search queries and index mappings. Avoid overly broad wildcard searches within the Searchkick configuration.
      • Elasticsearch Circuit Breakers: Configure Elasticsearch's circuit breakers.
      • Caching: Use a caching layer to reduce the load on Elasticsearch for frequent Searchkick queries.
      • Web Application Firewall (WAF): Use a WAF (although this is less directly related to Searchkick itself).
      • Elasticsearch Cluster Monitoring: Monitor cluster performance.