T09 · Insecure Skill Coding Practices
Warning
- Location
- scripts/schema_loader.py:52
- Finding
- Unknown Child Fields Are Incorrectly Accepted as Valid## Vulnerability Details **File Location**: `scripts/schema_loader.py`, lines 52–63 **Vulnerability Type**: Improper schema validation / fail-open validation **Risk Level**: Medium ### Vulnerable Code ```python def get_field_info(field_path: str, fields: Dict[str, Any]) -> Optional[Dict[str, Any]]: """Get information about a specific field.""" # Try exact match first if field_path in fields: return fields[field_path] # Try matching parent paths parts = field_path.split('.') for i in range(len(parts) - 1, 0, -1): parent_path = '.'.join(parts[:i]) if parent_path in fields: parent_info = fields[parent_path] # Check if parent is an object that could contain this field if parent_info.get('type') == 'object': # Field might be valid but not documented individually return { "type": "unknown (child of object)", "optional": True, "parent": parent_path, } return None ``` ### Technical Analysis `get_field_info()` first checks for an exact schema match, but then falls back to accepting any unknown descendant of a field whose type is `object`. The function returns a non-null synthetic field description, which callers interpret as proof that the field is valid. In `scripts/validate_field.py`, any non-null result becomes `"valid": True`. Likewise, `scripts/validate_config.py` adds such paths to `valid_fields`. Consequently, a path such as `tools.exec.securitty` is accepted because `tools.exec` is a known object, even though the misspelled child is absent from the bundled schema. This behavior contradicts the Skill’s stated purpose of checking whether configuration fields exist and are schema-compliant. It is particularly concerning for security-sensitive settings, including execution policy, filesystem restrictions, sandbox controls, allow/deny lists, and credential co ...[truncated 1719 chars]
- Remediation
- ## Remediation Suggestions 1. Require an exact schema-field match by default. Remove the generic fallback that treats every child of an object as valid. 2. If some objects intentionally allow arbitrary keys, represent that property explicitly in the schema, such as with an `additionalProperties` or `open_map` marker. 3. Return a distinct `unverified` result for descendants of explicitly extensible objects rather than reporting them as valid. 4. Ensure `validate_field.py` and `validate_config.py` distinguish among exact matches, permitted dynamic keys, unverified fields, and invalid fields. 5. Fail closed for security-sensitive objects such as `tools.exec`, `tools.fs`, `agents.defaults.sandbox`, and allow/deny policy structures. 6. Add regression tests covering: - Misspelled security fields such as `tools.exec.securitty`. - Invented descendants beneath ordinary objects. - Valid exact child fields. - Legitimate dynamic-map keys, if supported. - Unknown fields nested in arrays of objects. 7. Consider validating values and required fields in addition to field-path existence so the implementation more closely matches its schema-compliance claims.