Skip to content

Latest commit

 

History

History
103 lines (74 loc) · 9 KB

mitigations.md

File metadata and controls

103 lines (74 loc) · 9 KB

Mitigation Strategies Analysis for mrdoob/three.js

Mitigation Strategy: Disable Debugging Tools in Production (Three.js Specific Aspects)

Mitigation Strategy: Ensure the Three.js Inspector and any Three.js-specific debugging helpers are disabled.

Description:

  1. Three.js Inspector: The Three.js Inspector is a powerful tool for debugging scenes, but it exposes the entire scene graph and allows modification. It must be disabled in production. This is typically done by not including the Inspector's JavaScript file in your production build.
  2. Conditional Logic: Use JavaScript's conditional logic (e.g., if (process.env.NODE_ENV !== 'production') { ... }) to ensure that any code that initializes or uses the Three.js Inspector, or any other Three.js debugging utilities, is only executed in development environments.
  3. Renderer Settings: Check for any renderer settings that might expose debugging information (e.g., overly verbose logging). Set these to appropriate production levels.

Threats Mitigated:

  • Debugging Tools Left Enabled (Severity: High): Specifically targets the Three.js Inspector, preventing attackers from inspecting and manipulating the scene.
  • Information Disclosure (Severity: Medium): Prevents exposure of scene data and internal structure through the Inspector.

Impact:

  • Debugging Tools Left Enabled: Risk reduced completely (100%) for the Three.js Inspector.
  • Information Disclosure: Risk reduced significantly (70-80%) related to Three.js-specific debugging features.

Currently Implemented:

  • The Three.js Inspector is conditionally disabled based on process.env.NODE_ENV.

Missing Implementation:

  • None, assuming all Three.js-specific debugging helpers are also handled conditionally.

Mitigation Strategy: Optimize Model Complexity and Scene Limits (Three.js Specific Aspects)

Mitigation Strategy: Utilize Three.js features like LOD, instancing, and geometry merging to optimize rendering performance.

Description:

  1. Level of Detail (LOD): Use the THREE.LOD object. Create multiple versions of your models with decreasing polygon counts. Add these to the LOD object, and Three.js will automatically switch between them based on distance from the camera. This is a core Three.js feature.
  2. Instanced Geometry: If you have many identical objects, use THREE.InstancedMesh. This allows you to render multiple instances of the same geometry with a single draw call, significantly improving performance. This is crucial for scenes with many repeated elements.
  3. Geometry Merging (BufferGeometryUtils): If you have multiple static objects that don't need to be individually manipulated, use BufferGeometryUtils.mergeBufferGeometries to combine their geometries into a single BufferGeometry. This reduces the number of draw calls.
  4. Texture Optimization (Three.js Loaders): Use Three.js loaders that support optimized texture formats (e.g., KTX2Loader for KTX2 compressed textures, DDSLoader for DDS). These formats reduce GPU memory usage and improve loading times.
  5. Frustum Culling: Ensure that frustum culling is enabled (it is by default in Three.js). This prevents the renderer from drawing objects that are outside the camera's view frustum.
  6. Occlusion Culling (if applicable): For very complex scenes, consider implementing occlusion culling (this is not built-in to Three.js and requires custom implementation or a third-party library). This technique avoids drawing objects that are hidden behind other objects.

Threats Mitigated:

  • Complex Models (Severity: Medium to High): Directly addresses performance issues caused by complex models using Three.js's optimization features.
  • High Polygon Counts (Severity: Medium to High): Reduces the rendering burden of high-polygon scenes.
  • Denial of Service (DoS) (Severity: Medium): Makes it harder for attackers to cause performance degradation through complex scenes (though server-side limits are still important).

Impact:

  • Complex Models/High Polygon Counts: Risk reduced significantly (60-80%) through Three.js-specific optimizations.
  • Denial of Service (DoS): Risk reduced moderately (30-50%) by making the client-side rendering more resilient.

Currently Implemented:

  • LOD is used for a few key models.
  • KTX2Loader is used for some textures.

Missing Implementation:

  • LOD is not consistently used across all models.
  • Instanced geometry is not used. This is a major area for potential improvement.
  • Geometry merging is not used.
  • Occlusion culling is not implemented.

Mitigation Strategy: Avoid Dynamic Shader Compilation from User Input (Three.js Specific Aspects)

Mitigation Strategy: Do not use user input to construct THREE.ShaderMaterial code directly.

Description:

  1. Predefined Materials: Instead of allowing users to provide GLSL code, create a set of predefined THREE.ShaderMaterial instances with different parameters. Users can choose from these predefined materials or adjust a limited set of parameters.
  2. onBeforeCompile: If you need to modify shader code dynamically, use the onBeforeCompile callback of THREE.Material. This allows you to modify the shader code before it is compiled, but you should still avoid directly incorporating user input into the shader code. Use it for controlled modifications based on predefined parameters.
  3. Uniforms: Use uniforms to pass data to shaders. Uniforms are variables that can be set from JavaScript and used in the shader code. Validate and sanitize any user input that is used to set uniform values. Do not construct the uniform names or types from user input.
  4. Shader Chunks: Use Three.js's built-in shader chunks (THREE.ShaderChunk) for common shader code snippets. This promotes code reuse and reduces the risk of errors.

Threats Mitigated:

  • Shader Injection (Severity: High): Prevents attackers from injecting malicious GLSL code into your shaders. This is the primary threat this strategy addresses.

Impact:

  • Shader Injection: Risk reduced completely (100%) if user-provided shader code is completely disallowed and other recommendations are followed.

Currently Implemented:

  • Users cannot directly provide shader code. A limited set of material options is provided, using predefined THREE.ShaderMaterial instances.

Missing Implementation:

  • None. This mitigation strategy is fully implemented, as described.

Mitigation Strategy: Sanitize and Validate User Input for Geometry (Three.js Specific Aspects)

Mitigation Strategy: Validate user-provided data before using it to create or modify Three.js BufferGeometry attributes.

Description:

  1. Attribute Types: When creating a THREE.BufferGeometry, you define attributes (e.g., position, normal, uv). Ensure that user-provided data is of the correct type and size for each attribute. For example, position attributes typically use Float32Array.
  2. Attribute Lengths: Verify that the length of the user-provided data matches the expected number of vertices or elements for the geometry.
  3. Range Checks (Positions, Normals): If user input defines vertex positions, normals, or other numerical attributes, perform range checks to ensure the values are within reasonable bounds. This prevents excessively large or small values that could cause rendering issues or crashes.
  4. BufferAttribute Validation: Use the needsUpdate flag of THREE.BufferAttribute appropriately. After modifying the data in a BufferAttribute, set needsUpdate = true to signal to Three.js that the data needs to be uploaded to the GPU.
  5. Avoid eval() and String Concatenation for Geometry Data: Do not use eval() or string concatenation to construct geometry data from user input. This is a major security risk.

Threats Mitigated:

  • Geometry Injection (Severity: Medium to High): Prevents attackers from manipulating geometry data to create invalid or excessively complex geometry.
  • Denial of Service (DoS) (Severity: Medium): Helps prevent DoS attacks that rely on manipulating geometry data.

Impact:

  • Geometry Injection: Risk reduced significantly (70-80%) with thorough validation of BufferGeometry data.
  • Denial of Service (DoS): Risk reduced moderately (40-50%) as part of a broader DoS mitigation strategy.

Currently Implemented:

  • Basic type checking is performed on user input before creating BufferGeometry attributes.

Missing Implementation:

  • More comprehensive range checks and validation of attribute lengths are not consistently implemented. This is a key area for improvement.