AppSec

• Avoid Web Cache Poisoning

  • A cache poisoning attack uses an HTTP request to trick an origin web server into responding with a harmful resource that has the same cache key as a clean request. As a result, the poisoned resource gets cached and served to other users.
  • A Content Delivery Network (CDN) like Cloudflare relies on cache keys to compare new requests against cached resources. The CDN then determines whether the resource should be served from the cache or requested directly from the origin web server.

  
• Mitigating Web Cache Poisoning

  Only cache files that are truly static

  • Review the caching configuration for your origin web server and ensure you are caching files that are static and do not depend on user input in any way.

  Do not trust data in HTTP headers

  Client-side vulnerabilities are often exploited through HTTP headers, including cross-site scripting (XSS). In general, you should not trust the data in HTTP headers and as such:

  • Do not rely on values in HTTP headers if they are not part of your cache key.
  • Never return HTTP headers to users in cached content.
• Mitigating Web Cache Poisoning

  Do not trust GET request bodies

  • Cloudflare caches contents of GET request bodies, but they are not included in the cache key. GET request bodies should be considered untrusted and should not modify the contents of a response. If a GET body can change the contents of a response, consider bypassing cache or using a POST request.
• Mitigating Web Cache Poisoning

  Monitor web security advisories

  To keep informed about Internet security threats, Cloudflare recommends that you monitor web security advisories on a regular basis. Some of the more popular advisories include:

  • Drupal Security
  • Symfony Security
  • Laminas Security
• Mitigating Web Cache Poisoning

  • Validate and Sanitize User Inputs: Ensure that all user inputs are thoroughly validated and sanitized before being processed. This helps prevent attackers from injecting malicious data that could be cached.
  • Implement Cache Key Segmentation: Use separate cache keys for different user inputs and session data. This ensures that cached content is not inadvertently shared across different users or sessions.
• Mitigating Web Cache Poisoning

  • Use HTTPS and Secure Headers: Implement HTTPS to encrypt data in transit, and configure secure HTTP headers such as Cache-Control and Vary to control how and what gets cached. Avoid caching sensitive data like cookies or authentication tokens.
  • Set Appropriate Cache Expiry Times: Configure cache expiry times to ensure that stale or potentially malicious data does not persist for long periods. Regularly refresh cache content to keep it up to date.
• Mitigating Web Cache Poisoning

  • Implement Web Application Firewalls (WAFs): Deploy WAFs to inspect incoming requests for known attack patterns and anomalies that could be indicative of cache poisoning attempts.
  • Regularly Monitor and Audit Cache Behavior: Continuously monitor web server logs and cache behavior to detect unusual activities or patterns that may indicate an attempted cache poisoning attack.
• Web Cache Deception

  • Cache deception attacks exploit web caching mechanisms to expose sensitive data by tricking the cache into storing private or user-specific content
• Mitigating Web Cache Deception

  • Use Proper Cache-Control Headers: Configure your web server to set appropriate Cache-Control headers for each response. Ensure that user-specific and sensitive data are marked with no-cache, no-store, or private directives to prevent them from being cached.
  • Differentiate Between Static and Dynamic Content: Clearly distinguish between static and dynamic content on your site. Static content can be safely cached, whereas dynamic or user-specific content should be delivered with headers that prevent caching.
• Mitigating Web Cache Deception

  • Avoid Caching URLs with Query Parameters: Many caches are configured not to cache URLs with query parameters by default, as these often represent dynamic content. Ensure that your cache configuration adheres to this principle, or use URL rewriting techniques to ensure proper caching behavior.
  • Implement Strict URL Normalization: Normalize URLs to ensure that only the intended versions are cached. This involves removing unnecessary parameters and standardizing URL structures to prevent cache confusion.
• Mitigating Web Cache Deception

  • Monitor Cache Behavior: Regularly audit and monitor your caching infrastructure for anomalies or misconfigurations that could be exploited by cache deception attacks. Use logging to detect unusual patterns that may indicate an attempt to deceive the cache.
  • Limit Cacheable Methods: Restrict caching to safe HTTP methods like GET and ensure that methods like POST, which often involve sensitive data, are not cached.
• Clickjacking Mitigations

  Client-Side Defenses

  Scripts executed on the client side can perform actions to prevent Clickjacking:

  • Ensuring the application window is the main or top window.
  • Making all frames visible.
  • Preventing clicks on invisible frames.
  • Detecting and alerting users to potential Clickjacking attempts.
• Clickjacking Mitigations

  Client-Side Defenses

  However, these frame-busting scripts may be circumvented:

  • Browsers' Security Settings: Some browsers might block these scripts based on their security settings or lack of JavaScript support.
  • HTML5 iframe sandbox Attribute: An attacker can neutralize frame buster scripts by setting the sandbox attribute with allow-forms or allow-scripts values without allow-top-navigation. This prevents the iframe from verifying if it is the top window, e.g.,
• Clickjacking Mitigations

  Server-Side Defenses

  X-Frame-Options

  The X-Frame-Options HTTP response header informs browsers about the legitimacy of rendering a page in a <frame> or <iframe>, helping to prevent Clickjacking:

  • X-Frame-Options: deny - No domain can frame the content.
  • X-Frame-Options: sameorigin - Only the current site can frame the content.
  • X-Frame-Options: allow-from https://trusted.com - Only the specified 'uri' can frame the page.
  • Note the limitations: if the browser doesn't support this directive, it might not work. Some browsers prefer the CSP frame-ancestors directive.
• Frames

  • "Framing the page" in the context of X-Frame-Options refers to how a web page can be embedded within an HTML <iframe>. An iframe is used to embed another HTML document within the current document, effectively allowing one web page to display another web page inside it.
• Clickjacking Mitigations

  Content Security Policy (CSP) frame-ancestors directive

  frame-ancestors directive in CSP is the advised method for Clickjacking protection:

  • frame-ancestors 'none' - Similar to X-Frame-Options: deny.
  • frame-ancestors 'self' - Similar to X-Frame-Options: sameorigin.
  • frame-ancestors trusted.com - Similar to X-Frame-Options: allow-from.

  For instance, the following CSP only allows framing from the same domain:

  • Content-Security-Policy: frame-ancestors 'self';
• CSP: Frame-Ancestors

  • The frame-ancestors directive is part of the Content Security Policy (CSP) used to control which sources can embed a web page in an <iframe>, <frame>, <embed>, or <object>. This directive serves a similar purpose to the X-Frame-Options header but offers more flexibility and is part of the broader CSP mechanism.

  It can:

  • Allowing Specific Origins. Wildcard Support. Blocking All Framing and Allowing All Framing
• Clickjacking Mitigations:

  Content Security Policy (CSP) with child-src and frame-src

  Content Security Policy (CSP) is a security measure that helps in preventing Clickjacking and other code injection attacks by specifying which sources the browser should allow to load content.

  frame-src Directive

  • Defines valid sources for frames.
  • More specific than the default-src directive.

  This policy allows frames from the same origin (self) and https://trusted-website.com.

  
• Clickjacking Mitigations:

  CSP Usage Notes:

  • Deprecation: child-src is being phased out in favor of frame-src and worker-src.
  • Fallback Behavior: If frame-src is absent, child-src is used as a fallback for frames. If both are absent, default-src is used.
  • Strict Source Definition: Include only trusted sources in the directives to prevent exploitation.

  Employing Anti-CSRF Tokens

  • Token Validation: Use anti-CSRF tokens in web applications to ensure that state-changing requests are made intentionally by the user and not through a Clickjacked page.
• Client-Side Template Injection (CSTI) Mitigations

  • Input Validation and Sanitization: Rigorously validate and sanitize all user inputs before embedding them into client-side templates. Use libraries and frameworks that automatically handle input sanitization to prevent the inclusion of harmful scripts.
  • Use Secure Templating Engines: Choose client-side templating engines that are designed with security in mind. Prefer templating engines that automatically escape user inputs to prevent injection vulnerabilities, such as Handlebars or Mustache.
• Client-Side Template Injection (CSTI) Mitigations

  • Avoid Directly Embedding User Input: Avoid directly embedding user input into templates whenever possible. Instead, process the data server-side or in a controlled manner before rendering it in the client-side template.
  • Implement Content Security Policy (CSP): Use CSP to restrict the execution of unauthorized scripts and content. Define a strict policy that only allows scripts and resources from trusted sources, mitigating the impact of potential injection attacks.
• Client-Side Path Traversal

  • Client-side path traversal vulnerabilities occur when an attacker manipulates paths used in client-side code to access restricted resources or sensitive information. This can be particularly problematic in web applications that handle file paths or URLs in an insecure manner.
• Client-Side Path Traversal Mitigations

  • Input Validation and Sanitization: Ensure that all input, especially file paths or URL parameters, are thoroughly validated and sanitized. Use a whitelist approach to allow only expected and safe input patterns, rejecting any that do not conform.
  • Restrict Direct File Access: Avoid allowing client-side code to directly reference file paths. Use server-side code to control access to resources and serve files after validating user permissions and input.
• Client-Side Path Traversal Mitigations

  • Implement Access Controls: Use robust access control mechanisms to ensure that users can only access files or resources they are authorized to view. Verify permissions on the server side before granting access to any resource.
  • Normalize File Paths: Normalize file paths in server-side code to prevent directory traversal attacks. This ensures that file paths resolve to the intended directories and do not escape to unauthorized areas.
• Client-Side Path Traversal Mitigations

  • Use Environment Variables for Sensitive Paths: Store sensitive directory paths and configuration settings in environment variables on the server rather than exposing them in client-side code. This keeps critical paths hidden from users and attackers.
  • Regular Security Testing and Audits: Conduct regular security testing, such as penetration tests and code reviews, to identify and mitigate path traversal vulnerabilities. Ensure that security best practices are part of the development lifecycle.
• Command Injection Mitigations

  • Input Validation and Sanitization: Rigorously validate and sanitize all user inputs. Use a whitelist approach to accept only expected and safe input patterns. Reject or escape any characters that could be used to alter command execution, such as ;, &, |, and others.
  • Avoid Direct Command Execution: Avoid using user inputs directly in command executions. Instead, use safer alternatives such as parameterized queries or APIs that provide the desired functionality without directly executing shell commands.
• Command Injection Mitigations

  • Environment Isolation: Use containers or virtual machines to isolate applications and their execution environments. This adds an additional layer of protection, as the impact of a command injection can be confined to the isolated environment
  • Use Security Tools: Implement security tools such as Web Application Firewalls (WAFs) and Intrusion Detection Systems (IDS) to monitor and block potential command injection attempts.