README.txt).apache/ws-xmlschema.RELEASE-NOTE.txt: 2.3.0.SECURITY.md and the Apache Security Team disclosure channel (https://www.apache.org/security/); reports that fall under §3 (out of scope) or §9 (properties not provided) will be closed by XMLSchema triagers citing this document.XMLSchema is a Java library that parses, models, walks, and serializes W3C XML Schema documents (.xsd files). It is not a document validator at its core (despite the xmlschema-walker providing some validation helpers): the primary product is the in-memory object model of a schema, and the schema-imports / schema-includes resolver that lets a <xs:include> or <xs:import> pull in additional schemas from a URI. XMLSchema is consumed primarily by SOAP stacks (Apache CXF, Apache Axis) and other code-generation / data-binding tooling. It is bundled into runtimes that ingest WSDLs and policy documents.
README.txt).xmlschema-core (the object model + parser + serializer + URI resolver), xmlschema-walker (visitor-style schema walking + a XmlSchemaElementValidator used for tooling), and xmlschema-bundle-test (an OSGi bundle integration test). The w3c-testcases directory holds the W3C test suite for regression testing only.XMLSchema is an in-process Java library. There is no daemon, no network listener, no CLI. The threat model is therefore that of an XML-parsing library that performs caller-directed network or filesystem IO when it follows <xs:include> / <xs:import> / schemaLocation references (inferred — §14 Q2).
| Role | Trust level | Notes |
|---|---|---|
| Embedding Java application | trusted | Calls XmlSchemaCollection.read(...), decides whether the input stream came from disk, classpath, or wire; decides which URIResolver to plug in. |
URIResolver implementation | trusted | Either the bundled DefaultURIResolver (which constructs a URL from the parent schema's base URI + the schemaLocation and returns an InputSource pointing at it) or a caller-supplied resolver (documented: xmlschema-core/src/main/java/.../resolver/DefaultURIResolver.java). A hostile resolver is out of model. |
ExtensionRegistry implementation | trusted | Pluggable via system property org.apache.ws.commons.schema.extension_registry (documented: xmlschema-core/src/main/java/org/apache/ws/commons/schema/XmlSchemaCollection.java line 361). |
Producer of the schema bytes (Reader, InputStream, InputSource, Source, Document, Element) | variable — see §6 trust table | The only attacker-controllable input position; in many embeddings the schema bytes come from a WSDL fetched off the wire. |
Producer of imported / included schemas (resolved by the URIResolver) | variable — typically as untrusted as the parent schema, but can be a different origin if the parent's <xs:import schemaLocation="http://attacker/evil.xsd"> points elsewhere | Following an xs:import is a second, possibly cross-origin, fetch. This is the principal SSRF surface. |
JDK XML platform (DocumentBuilderFactory, TransformerFactory, SchemaFactory) | trusted upstream | XMLSchema sets FEATURE_SECURE_PROCESSING=true on the factories it constructs. Its internal schema parser also rejects DOCTYPE declarations by default and disables external DTD and external entity resolution; org.apache.ws.commons.schema.allowDTD=true accepts DOCTYPE-bearing schema documents while keeping external resolution disabled. |
| Family | Representative entry point | Touches outside the process? | In-model? |
|---|---|---|---|
xmlschema-core object model — XmlSchema* types, XmlSchemaCollection, SchemaBuilder | XmlSchemaCollection.read(InputSource, ...) and overloads | no for in-memory model; yes when the URI resolver follows xs:import/xs:include | yes |
xmlschema-core URI resolver — DefaultURIResolver, CollectionURIResolver, URIResolver | XmlSchemaCollection.setSchemaResolver() | yes — by design, fetches imported schemas | yes |
xmlschema-core serializer — XmlSchemaSerializer | XmlSchema.write(OutputStream) | no | yes |
xmlschema-core resource loader (internal) — hardened DocumentBuilderFactory and TransformerFactory instances | invoked by XmlSchemaCollection.read(InputSource, ...), recursive schema reparses, and XmlSchema.write(...) | no except where the URI resolver fetches imported schemas before parsing | yes |
xmlschema-walker visitor — XmlSchemaWalker, XmlSchemaVisitor, XmlSchemaScope | walked by a caller-supplied XmlSchemaVisitor | no | yes |
xmlschema-walker element validator — XmlSchemaElementValidator | walked at SAX-event time; consults the schema model | no (operates on caller-supplied SAX events) | yes |
xmlschema-walker document path finder — XmlSchemaPathFinder | walked at SAX-event time; matches events against the schema model | no (operates on caller-supplied SAX events) | yes |
xmlschema-walker DOM-from-SAX helper — DomBuilderFromSax | builds a DOM out of SAX events for validator inspection | no | yes |
xmlschema-bundle-test | OSGi packaging regression test | n/a | out of model (§3) |
w3c-testcases/ | W3C schema test data | n/a | out of model (§3) |
A finding is in-model only if it reaches a row marked yes.
xmlschema-walker‘s XmlSchemaElementValidator used in tooling contexts. Findings that depend on the JDK Validator / SchemaFactory behavior or on third-party validators built on XMLSchema’s model are out of model (inferred — §14 Q3). → OUT-OF-MODEL: out-of-layer.<schema> element of a WSDL, but the WSDL parser itself is upstream (e.g. Apache WSDL4J, Apache CXF). → OUT-OF-MODEL: out-of-layer.SchemaFactory of the JDK. XMLSchema does not wrap or replace the JDK's javax.xml.validation.SchemaFactory. The two are different abstractions (inferred — §14 Q3). → OUT-OF-MODEL: out-of-layer.xmlschema-bundle-test and w3c-testcases/. Integration test harness and W3C regression data. → OUT-OF-MODEL: unsupported-component.Document / Element. XmlSchemaCollection.read(Document) and .read(Element) accept a caller-parsed DOM; if the caller's DocumentBuilderFactory is not hardened, XMLSchema does not retroactively secure it (inferred — §14 Q4). → OUT-OF-MODEL: trusted-input.xs:include / xs:import. The URI is in the input schema; XMLSchema follows it. What the remote host returns is data XMLSchema then parses, but the integrity of the remote host is not WSS4J's concern (inferred — §14 Q5). → OUT-OF-MODEL: adversary-not-in-scope for malicious remote peer; VALID if XMLSchema is tricked into the fetch in the first place by a path the §7 model permits.URIResolver / ExtensionRegistry implementations. Caller-pluggable; a hostile resolver is out of model.w3c-testcases/, */src/test/, etc/, xmlschema-bundle-test/. Test data and supporting fixtures. → OUT-OF-MODEL: unsupported-component.| # | Transition | Authentication | Authorization |
|---|---|---|---|
| B1 | Caller → `XmlSchemaCollection.read(InputSource | Reader | Source |
| B2 | XmlSchemaCollection.read(InputSource, ...) → hardened JDK DocumentBuilder | none | DOCTYPE rejected by default; external DTD/entity resolution disabled |
| B3 | Schema parser → URIResolver.resolveEntity(namespace, schemaLocation, baseUri) | none | bundled DefaultURIResolver does no host filtering: it constructs new URL(new URL(baseUri), schemaLocation) and hands back an InputSource pointing at it |
| B4 | Resolved InputSource → XmlSchemaCollection.read(InputSource, ...) (recursive) | none | none |
| B5 | XmlSchema.write(...) → JDK TransformerFactory (with FEATURE_SECURE_PROCESSING=true and external DTD/stylesheet access disabled where supported) | none | none |
| B6 | XmlSchemaCollection ctor → System.getProperty("org.apache.ws.commons.schema.extension_registry") → Class.forName() | none | trusts system properties to be operator-controlled |
xmlschema-core parser (XmlSchemaCollection.read(InputSource), .read(Reader), .read(Source) for non-DOMSource sources): in-model when the bytes are attacker-controllable. XMLSchema sets FEATURE_SECURE_PROCESSING=true on its internal DocumentBuilderFactory, rejects DOCTYPE declarations by default, disables external general entities, external parameter entities, and external DTD loading, and installs a no-op SAX EntityResolver. Setting org.apache.ws.commons.schema.allowDTD=true accepts DOCTYPE-bearing schema documents but keeps external DTD and external entity resolution disabled.xmlschema-core URI resolver (DefaultURIResolver): in-model for SSRF / cross-origin fetch when the input schema is attacker- controlled and contains an xs:import schemaLocation="…". The bundled resolver constructs new URL(...) and returns an InputSource; the JDK then fetches it on parse().xmlschema-core parser fed a pre-parsed DOM (read(Document), read(Element)): out of model for XXE; the caller's DocumentBuilderFactory decided that. In-model for whatever the schema-model semantics imply about the DOM contents.xmlschema-walker: in-model when the visitor walks an attacker-controlled schema. The walker is purely in-memory. Before cycle detection, malformed but parseable schemas could create cycles in type derivation, substitution groups, model groups, or attribute groups and recurse until StackOverflowError. The walker now tracks these expansion paths and rejects cyclic re-entry with XmlSchemaException; recursion that crosses an element declaration remains supported.XmlSchemaPathFinder: in-model when caller-supplied SAX events are matched against an attacker-controlled schema. Its backtracking work is bounded per document by configurable decision-point and replay-event limits.XmlSchemaElementValidator / DomBuilderFromSax: in-model only insofar as they parse SAX events the caller hands in. DomBuilderFromSax sets FEATURE_SECURE_PROCESSING=true on its DocumentBuilderFactory (documented: xmlschema-walker/src/main/java/.../docpath/DomBuilderFromSax.java line 81).RELEASE-NOTE.txt).DocumentBuilderFactory, TransformerFactory, and SAX parser. XMLSchema applies explicit DTD and external access controls to its internal schema parser and transformer, while unsupported optional JAXP features are ignored so the remaining controls still apply.DefaultURIResolver will issue HTTP / HTTPS / file:// / jar: fetches via the JDK URL handlers when an xs:include / xs:import schemaLocation is followed. Whether the JVM has a proxy configured, a SecurityManager, or any URL-scheme restriction is out of XMLSchema's control (documented: DefaultURIResolver.java).schemaLocation values that begin with file:// (inferred — §14 Q7).README.txt).org.apache.ws.commons.schema.extension_registry is consulted at XmlSchemaCollection construction time, and the named class is loaded via Class.forName() (documented: XmlSchemaCollection.java line 361). This is a startup-time privilege escalation surface if the system property can be set by an untrusted actor (inferred — §14 Q9).AccessController.doPrivileged: XMLSchema brackets the schema parse and the system-property read in AccessController.doPrivileged to be JDK-SecurityManager-compatible on pre-17 JDKs (documented: XmlSchemaCollection.java lines 376, 745). On JDK 17+ the SecurityManager is deprecated.org.apache.ws.commons.schema.extension_registry for security-relevant decisions; does not consume LD_*-style envvars (inferred — §14 Q10).XmlSchemaSerializer writes to the OutputStream the caller hands in (inferred — §14 Q10).XMLSchema is a single Maven artifact set (xmlschema-core, xmlschema-walker, xmlschema-bundle-test). There are no compile-time feature toggles (inferred — §14 Q11). The runtime security envelope is shaped by a small set of runtime extension points:
| Knob | Default | Maintainer stance | Effect |
|---|---|---|---|
org.apache.ws.commons.schema.extension_registry system property | unset (documented: XmlSchemaCollection.java line 361) | dev-time customization; if set by an untrusted actor the named class is loaded into the JVM | extension-registry class is Class.forName-loaded at XmlSchemaCollection ctor time |
XmlSchemaCollection.setSchemaResolver(URIResolver) | DefaultURIResolver (documented: DefaultURIResolver.java) | maintainer ruling required — is the documented expectation that production deployments install a restricted resolver that refuses untrusted hosts (proposed: yes, §10), or is the default resolver supported as production-safe? (inferred — §14 Q12) | controls whether xs:include/xs:import may reach the network |
XmlSchemaCollection.setBaseUri(String) | unset (documented) | caller-supplied | base URI against which relative schemaLocation values resolve |
org.apache.ws.commons.schema.walker.maxDecisionPoints system property | 10000 (documented: XmlSchemaPathFinder.java) | operator-tunable per-process limit | maximum decision points created while matching one document |
org.apache.ws.commons.schema.walker.maxReplayedEvents system property | 1000000 (documented: XmlSchemaPathFinder.java) | operator-tunable per-process limit | maximum previously traversed events replayed while backtracking through one document |
org.apache.ws.commons.schema.maxImportDepth system property | 64 (documented: README.txt) | operator-tunable per-process limit | maximum import/include resolution depth for one schema read |
org.apache.ws.commons.schema.maxSchemaResolutions system property | 1000 (documented: README.txt) | operator-tunable per-process limit | maximum schema documents resolved during one top-level read |
org.apache.ws.commons.schema.maxNestingDepth system property | 512 (documented: README.txt) | operator-tunable per-process limit | maximum structural nesting depth while building the schema model, including nested include/import/redefine document resolutions |
org.apache.ws.commons.schema.allowDTD system property | false (documented: README.txt) | compatibility toggle for operator-controlled deployments | allows DOCTYPE declarations in schema documents; external DTD and external entity resolution remain disabled |
DocumentBuilderFactory provider | JDK default (typically Xerces fork) (inferred — §14 Q6) | depends on the JDK | shape of XML parsing for read(InputSource) / stream-shaped read(Source) paths |
The bundled DefaultURIResolver does follow remote URLs by default. The maintainer ruling captured in §14 Q12 will determine whether “a schema with <xs:import schemaLocation='http://attacker/'/> fetched the URL during parse” is a VALID report (production deployments should be protected by the default) or an OUT-OF-MODEL: non-default-build report (production deployments are documented as required to install a restricting resolver per §10).
XMLSchema's internal schema parser rejects DOCTYPE declarations by default and disables external DTD and external entity resolution. This applies both to top-level read(InputSource | Reader | Source) non-DOMSource paths parses and to recursive import/include/redefine reparses. Operators may set org.apache.ws.commons.schema.allowDTD=true to accept DOCTYPE-bearing schemas for compatibility; external DTD and external entity resolution remain disabled in that mode.
| Entry point | Parameter | Attacker-controllable? | Caller must enforce |
|---|---|---|---|
XmlSchemaCollection.read(InputSource is) | is bytes | yes | XMLSchema rejects DOCTYPE by default and disables external DTD/entity resolution; caller may need to install a restricting URIResolver if the source contains untrusted xs:include/xs:import |
XmlSchemaCollection.read(Reader r) | r characters | yes | same as above |
XmlSchemaCollection.read(Source src) | src | yes | SAXSource/StreamSource/other route through the internal hardened factory (same as read(InputSource)); a DOMSource routes to the pre-parsed read(Document)/read(Element) path, so the upstream parser's XXE/DTD posture applies |
XmlSchemaCollection.read(Document doc) | doc | yes if doc was parsed from untrusted bytes | caller's DocumentBuilderFactory is responsible for XXE / DTD posture; XMLSchema does not re-parse |
XmlSchemaCollection.read(Element el) | el | same as read(Document) | same as above |
XmlSchemaCollection.setSchemaResolver(URIResolver) | resolver | caller-supplied | replacing the default is the documented path for production hardening (inferred — §14 Q12) |
XmlSchemaCollection.setBaseUri(String) | baseUri | caller-supplied trusted string | not validated; if attacker can set this they can pivot the import-resolver origin |
XmlSchemaCollection.setExtReg(ExtensionRegistry) | registry | caller-supplied | caller's choice |
XmlSchema.write(OutputStream) / XmlSchema.write(Writer) | output sink | caller-supplied | caller's choice; FEATURE_SECURE_PROCESSING=true is set on the internal TransformerFactory, with external DTD/stylesheet access disabled where supported |
XmlSchemaWalker.walk(XmlSchemaElement) | walked schema | as untrusted as the schema | none — pure in-memory walking |
XmlSchemaPathFinder | SAX events + schema model | as untrusted as both | configure backtracking limits for the deployment; defaults bound decision points and replayed events per document |
XmlSchemaElementValidator (walker module) | SAX events + schema model | as untrusted as both | caller validates / sanitizes outside |
DomBuilderFromSax | SAX events | as untrusted as the source of the events | FEATURE_SECURE_PROCESSING=true is set (documented: DomBuilderFromSax.java line 81) |
System property org.apache.ws.commons.schema.extension_registry | class name | trusted by §3 item 7 | operator must lock down property setting in shared-JVM deployments |
README.txt).README.txt).xs:import (inferred — §14 Q12).XmlSchemaPathFinder bounds decision points and replayed events per document by default; these limits are configurable through the org.apache.ws.commons.schema.walker.maxDecisionPoints and org.apache.ws.commons.schema.walker.maxReplayedEvents system properties (documented: XmlSchemaPathFinder.java).| Actor | In scope? | Capabilities |
|---|---|---|
| Producer of the input schema bytes | yes | full byte control of the schema; can include <xs:import schemaLocation="…"/> pointing anywhere |
| Producer of an imported schema at a URL the parent schema references | yes | returns a malicious downstream .xsd after the parent triggers the fetch |
Network attacker on the path between XMLSchema and an HTTP schemaLocation | partial (inferred — §14 Q13) — TLS is the JDK URL handler's concern; XMLSchema does no certificate pinning; if the operator allowed plain http:// fetches a network attacker can substitute | |
| In-process callers (the embedding application) | out of scope | trivially full control |
| Owner of the host filesystem | out of scope | by construction |
Author of a hostile URIResolver / ExtensionRegistry | out of scope (§3 item 7) | |
| Author of system-property setting on JVM startup | out of scope if operator-controlled; in scope only when an untrusted actor can set org.apache.ws.commons.schema.extension_registry (inferred — §14 Q9) | |
| Co-tenant on the same JVM (multi-app servlet container) | out of scope (inferred — §14 Q14) | |
| Side-channel observer | out of scope (inferred — §14 Q14) | |
| Quantum adversary | out of scope |
read(...) paths; the JDK platform supplies a working DocumentBuilder; XMLSchema sets FEATURE_SECURE_PROCESSING=true on its factories..xsd causes XMLSchema's own code (not the JDK XML parser) to throw an unhandled exception that is not a XmlSchemaException / ParserConfigurationException / IOException / SAXException — i.e. crashes outside the documented failure mode. Memory corruption is JVM-level and not a Java-side defect.VALID-HARDENING if the symptom is an unhandled RuntimeException that the caller cannot catch through the documented surface (inferred — §14 Q15).read(InputSource | Reader | Source) non-DOMSource paths take the internal DocumentBuilderFactory.EntityResolver is installed as a fallback. If org.apache.ws.commons.schema.allowDTD=true is set, DOCTYPE declarations may be accepted but external DTD/entity resolution remains disabled.allowDTD is unset.TransformerFactory is configured with FEATURE_SECURE_PROCESSING=true.xmlschema-walker deterministic visit orderXmlSchemaWalker.walk(XmlSchemaElement).XmlSchemaException rather than recursing indefinitely. Legal recursive content that passes through an element declaration remains walkable.StackOverflowError or another resource-exhaustion failure.XmlSchemaCollection.read(...).XmlSchemaException instead of exhausting the Java thread stack.SchemaBuilder to recurse until StackOverflowError or another resource-exhaustion failure.State each plainly so a triager can route an inbound report to the matching disclaimer.
xs:import/xs:include schemaLocation URLs. The bundled DefaultURIResolver constructs a URL from the parent schema's base URI plus the schema-location value and returns an InputSource pointing at it. The JDK then fetches it on parse. XMLSchema applies no allowlist, no protocol restriction, and no host filtering of any kind. The caller is responsible for installing a restricting URIResolver if the input schema is attacker-controlled (documented: DefaultURIResolver.java).org.apache.ws.commons.schema.allowDTD=true is set. The compatibility mode still disables external DTD and external entity resolution.Document or Element. The hardening on the internal DocumentBuilderFactory is moot — the caller's parser produced the DOM (documented: XmlSchemaCollection.read(Document) / .read(Element)).README.txt).http://. The caller must use TLS-protected URLs or install a restricting resolver (documented: DefaultURIResolver.java).ExtensionRegistry being a malicious class. The named class is loaded into the running JVM and instantiated.XmlSchemaSerializer are plain XML on whatever sink the caller provided.org.apache.ws.commons.schema.allowDTD=true looks like it restores legacy XML parser behavior, but it does not restore external DTD or external entity fetching. The toggle accepts DOCTYPE declarations for compatibility only; external fetches remain disabled.DefaultURIResolver looks like a sandbox, but it isn't. It is the bundled resolver; its job is to resolve xs:include/xs:import, not to filter destinations.XmlSchemaCollection.setBaseUri(String) looks like a chroot for imports, but it isn't. If the importing schema sets an absolute URL in schemaLocation, the base URI is irrelevant — the absolute URL wins (inferred — §14 Q18).xmlschema-walker.XmlSchemaElementValidator looks like a document validator, but it is a tooling helper. It is not a drop-in replacement for javax.xml.validation.Validator and does not promise XSD-1.0 / 1.1 conformance (inferred — §14 Q3).read(Document) / read(Element). XMLSchema's internal parser path rejects DOCTYPE by default and disables external DTD/entity resolution.xs:import schemaLocation — see §9 first bullet.FEATURE_SECURE_PROCESSING=true, but not universally.baseUri + relative schemaLocation — the operator-supplied base URI is trusted.The embedding Java application must:
URIResolver via XmlSchemaCollection.setSchemaResolver(...) that refuses arbitrary http:// / https:// / file:// / jar: / ftp: URLs. The bundled DefaultURIResolver does not filter (documented: DefaultURIResolver.java).Document / Element into XmlSchemaCollection.read(...), use a DocumentBuilderFactory hardened against XXE — specifically with disallow-doctype-decl=true and external-entity processing disabled.org.apache.ws.commons.schema.allowDTD=true for attacker-controlled schema bytes unless compatibility requires it and the deployment accepts internal DTD subset processing. External DTD and external entity resolution remain disabled by XMLSchema in that mode.org.apache.ws.commons.schema.extension_registry only at JVM startup from a trusted source; do not allow untrusted actors to set it.XmlSchemaCollection.setBaseUri(...) from an operator-trusted string, not from anywhere an attacker can influence.RELEASE-NOTE.txt).The embedding Java application should additionally implement these defense-in-depth controls:
https:// to approved hosts; deny file://, jar:, loopback, link-local, and RFC1918/private address ranges.org.apache.ws.commons.schema.allowDTD unset unless a deployment has known DTD-bearing schema inputs and has tested the compatibility mode on its JDK XML provider..xsd to XmlSchemaCollection.read(InputSource) with the DefaultURIResolver in place. The schema's xs:include / xs:import are followed unrestricted, leading to SSRF / cross-origin fetch / file:// disclosure (documented: DefaultURIResolver.java). The fix is per §10 item 1.read(Document) / read(Element) to inherit XXE defenses from XMLSchema. XMLSchema does not re-parse; the caller's factory chose the posture.org.apache.ws.commons.schema.extension_registry from a servlet-context init parameter or a config file an end user can influence. The named class is loaded and instantiated at XmlSchemaCollection construction.XmlSchemaElementValidator (walker module) as a conformant XSD validator. It is a tooling helper; conformant document validation against an XSD requires the JDK javax.xml.validation.Validator (inferred — §14 Q3).XmlSchemaCollection instance across thread boundaries without external synchronization. XMLSchema does not document its threading model (inferred — §14 Q19).http:// from a remote registry. The operator should restrict to https:// or pin to a trusted mirror.xmlns:tns URL the attacker provided) and then walking the URI graph from that base.This section is the highest-leverage input for automated agentic security scans. Each entry: tool symptom, why it is safe under the model, the section that licenses the call.
new URL(baseUri, schemaLocation).openConnection() — SSRF risk in DefaultURIResolver.” Bundled behavior, explicitly documented as defaulted unrestricted; operator must install a restricting resolver per §10 item 1. → OUT-OF-MODEL: trusted-input (if the maintainer rules at Q12 that the default is dev/test), or VALID-HARDENING (if the maintainer rules the default is supported).DocumentBuilderFactory.newInstance() allows XXE in XmlSchemaCollection.” Current XMLSchema internal parsing rejects DOCTYPE by default and disables external DTD/entity resolution. A report must show a bypass of those controls to be VALID.Class.forName(System.getProperty(...)) is dynamic-class-loading.” Documented extension point; the system property is the trust gate (documented: XmlSchemaCollection.java line 361). → OUT-OF-MODEL: trusted-input.AccessController.doPrivileged deprecated in JDK 17.” JDK compatibility wrapper; deprecation is informational on JDK 17 and required on pre-17 JDKs. → KNOWN-NON-FINDING.w3c-testcases/ data, it is W3C conformance suite data (documented: top-level w3c-testcases/). → OUT-OF-MODEL: unsupported-component.XmlSchemaSerializer uses identity Transformer — could be exploited via XSLT injection.” Identity transform; no stylesheet reachable from input (documented: XmlSchema.java). → KNOWN-NON-FINDING.URLConnection.getInputStream() without timeout.” True; XMLSchema does no read-timeout on fetched imports (inferred — §14 Q12). → VALID-HARDENING if Q12 rules the default-resolver is production-safe; otherwise documented as a §10 responsibility.XmlSchemaCollection.setBaseUri().” Caller- supplied trusted string per §6. → OUT-OF-MODEL: trusted-input.w3c-testcases/ contain wide-open DTDs.” W3C conformance suite, used as input to unit tests (documented: top-level w3c-testcases/). → OUT-OF-MODEL: unsupported-component.ExtensionRegistry is Class.forName-loaded — RCE.” Trusted system property per §3 item 7. → OUT-OF-MODEL: trusted-input.XmlSchemaCollection.read(InputSource) with a file:// system ID follows it to read arbitrary local files.” (No read(URL) or read(InputStream) overload exists; earlier revisions of this table listed both in error.) Caller passed the URL; trusted entry point. → OUT-OF-MODEL: trusted-input.Revise this document when any of the following lands:
URIResolver behavior — e.g. adding host filtering, refusing non-HTTPS, or adding read/connect timeouts.org.apache.ws.commons.schema.allowDTD compatibility contract.XmlSchemaCollection that accepts new input shapes.xmlschema-walker's validator that turns it into a claimed-conformant document validator.ExtensionRegistry.A report against XMLSchema receives exactly one of the following:
| Disposition | Meaning | Licensed by |
|---|---|---|
VALID | Violates a §8 property via an in-scope §7 adversary using an in-scope §6 input. | §8, §6, §7 |
VALID-HARDENING | No §8 property violated, but a §11 misuse pattern can be made harder to fall into by code change. Typically no CVE. | §11 |
OUT-OF-MODEL: trusted-input | Requires attacker control of a §6 parameter the model marks trusted (caller-supplied Document / Element, caller-supplied baseUri, caller-supplied URIResolver, JVM system property, etc.). | §6 |
OUT-OF-MODEL: adversary-not-in-scope | Requires a §7 actor the model excludes (in-process caller, hostile URIResolver, operator). | §7 |
OUT-OF-MODEL: unsupported-component | Lands in w3c-testcases/, */src/test/, etc/, xmlschema-bundle-test/. | §3 items 4, 8 |
OUT-OF-MODEL: non-default-build | Only manifests under a §5a configuration the maintainer rules dev/test (e.g. an unsafe custom URIResolver). | §5a |
OUT-OF-MODEL: out-of-layer | Concerns a document validation step delegated to javax.xml.validation.Validator, or a WSDL parser upstream. | §3 items 1–3 |
BY-DESIGN: property-disclaimed | Concerns a §9 property the project explicitly does not provide (no SSRF defense, no guarantee of default DTD acceptance, no schema-size, imported-byte, or fetch-rate ceiling). | §9 |
KNOWN-NON-FINDING | Matches a §11a recurring false positive. | §11a |
MODEL-GAP | Cannot be cleanly routed to any of the above — triggers §12 model revision. | §12 |
Every (inferred) tag in the body maps to one of these. Proposed answers are inline; please confirm, correct, or strike.
Q1. XMLSchema does not currently ship an in-repo SECURITY.md. The de facto policy is “report via https://www.apache.org/security/”. Should the project (a) adopt a SECURITY.md that names a supported- branch matrix (proposed), (b) leave reporting to the foundation page only, or (c) defer to the Webservices PMC's umbrella policy? (meta)
Q2. Confirm that XMLSchema's threat model treats the project as a schema-modeling library that performs network IO when resolving imports, not a generic XML parser (proposed: yes). (maps to §2)
Q3. xmlschema-walker.XmlSchemaElementValidator — proposed position is “tooling helper, not a claimed-conformant document validator”. Confirm? (maps to §3 item 1, §9 false-friend, §11)
Q4. When read(Document) / read(Element) is the entry point, proposed position is “the caller's DOM was already parsed; XMLSchema makes no XXE claim about it” (OUT-OF-MODEL: trusted-input). Confirm? (maps to §3 item 5, §13)
Q5. When the URI resolver follows an xs:import schemaLocation, proposed position is “what the remote host returns is parsed by the internal XMLSchema parser path; the fetch itself is the attacker-influenced action and §9 disclaims SSRF defense” (§9). Confirm? (maps to §3 item 6, §9)
Q6. DTD compatibility posture. XMLSchema now rejects DOCTYPE declarations by default on the internal schema parser, disables external DTD/entity resolution, and offers org.apache.ws.commons.schema.allowDTD=true to accept DTD-bearing schema documents while keeping external resolution disabled. Confirm that this is the supported posture for untrusted schema bytes. (maps to §5a, §8 P2, §9, §10, §11a)
Q7. Confirm that XMLSchema does not sanitize schemaLocation when it begins with file://, jar:, etc. (proposed: no sanitization; operator's URIResolver is the gate). (maps to §5, §11a)
Q8. XMLSchema has no documented bound on schema-document size, imported bytes, or fetch rate. Import/include resolution does have configurable defaults of 64 levels and 1000 resolved schema documents per top-level read. The caller remains responsible for additional deployment- specific resource budgets. (maps to §5, §9, §10 item 4)
Q9. org.apache.ws.commons.schema.extension_registry system property: confirm that production deployments are expected to set it (if at all) at JVM startup from a trusted source — i.e. an untrusted-actor-set value is OUT-OF-MODEL: trusted-input (proposed). (maps to §5a, §11)
Q10. Negative-side inventory in §5: XMLSchema opens no sockets other than what the JDK URL handler does when following an import; spawns no processes; installs no signal handlers; reads only the documented system property; writes nothing of its own initiative. Confirm? (maps to §5)
Q11. Build-time variants: confirm there are no compile-time feature toggles; the security envelope is shaped only by runtime extension points (proposed). (maps to §5a)
Q12. The big URI-resolver question. The bundled DefaultURIResolver follows http:// / https:// / file:// / jar: URLs without filtering. Is this:
<xs:import schemaLocation='http://attacker/'/> triggered a fetch is VALID?OUT-OF-MODEL: non-default-build?Proposed: (b) with a clarification in README.txt and/or SECURITY.md that production deployments handling untrusted schema bytes must install a restricting URIResolver. (maps to §5a, §9, §10 item 1, §11a, §13)
Q13. Network attacker on http:// import fetches: proposed position is “operator is documented as required to use https:// or a restricting resolver; TLS validity is the JDK URL handler's concern”. Confirm? (maps to §7)
Q14. Co-tenant in shared JVM and side-channel observers: out of scope (proposed)? (maps to §7)
Q15. §8 P1 (memory safety on parse): proposed wording “any RuntimeException outside the documented XmlSchemaException/ ParserConfigurationException/IOException/SAXException family is VALID-HARDENING”. Confirm? (maps to §8 P1)
Q16. §8 P3 (round-trip parse → model → serialize consistency): do you claim this as a security property, or only as a correctness one? Proposed: correctness-only unless the divergence creates a security-meaningful downstream misinterpretation, in which case it is a VALID-HARDENING. (maps to §8 P3)
Q17. §8 P4 (walker deterministic visit order): is the visit order documented? Proposed: correctness-only. (maps to §8 P4)
Q18. setBaseUri(...) semantics: if an <xs:import schemaLocation='http://absolute/'/> is encountered, the base URI is ignored. Confirm? (maps to §9 false-friend)
Q19. Threading model: is XmlSchemaCollection documented as thread-safe? Proposed: not thread-safe; callers synchronize. (maps to §11)
Q20. This document should be hosted in-repo at docs/security/threat-model.md (proposed) or on ws.apache.org/xmlschema/? (meta)
Q21. §11a known-non-findings is thin (~11 patterns). Could the XMLSchema PMC populate from the JIRA “not a bug” / “wontfix” closures (XMLSCHEMA-* tickets)? Concrete asks: 3–5 patterns the PMC sees recur in inbound reports. (meta — §11a)
Q22. What kind of change to XMLSchema should trigger a revision (proposed list in §12 — confirm or correct)? (meta — §12)
Q23. xmlschema-walker cycle handling: should rejection of cyclic type derivation, substitution-group, model-group, and attribute-group expansions be treated as a claimed medium-severity availability property for attacker-controlled schemas? Proposed: yes; malformed but parseable cycles must terminate with XmlSchemaException, while legal recursive content through element declarations remains supported. (maps to §4, §6, §8 P5)
XMLSchema ships a SECURITY.md that points vulnerability reporters to the Apache Software Foundation security process. The threat-model sources are the in-repo README.txt, the RELEASE-NOTE.txt, SECURITY.md, and the JavaDoc / source comments. The project website is https://ws.apache.org/xmlschema/.
| Source | Claim | Lands in |
|---|---|---|
SECURITY.md | vulnerability reports go through the Apache Software Foundation security process and this threat model documents scope / triage | §1 |
README.txt | “lightweight schema object model that can be used to manipulate and generate XML schema representations” | §1, §2 intended use |
RELEASE-NOTE.txt (2.3.0) | Java 17 minimum, Java 7 dropped | §5 environment |
xmlschema-core/src/main/java/org/apache/ws/commons/schema/XmlSchemaCollection.java line 361 | org.apache.ws.commons.schema.extension_registry system property loaded via Class.forName | §5a, §6, §11 |
xmlschema-core/src/main/java/org/apache/ws/commons/schema/SchemaBuilder.java | org.apache.ws.commons.schema.maxNestingDepth structural descent limit | §5, §5a, §6, §8 P6 |
XmlSchemaCollection.java | internal parser sets FEATURE_SECURE_PROCESSING, rejects DOCTYPE by default, disables external DTD/entity resolution, and honors org.apache.ws.commons.schema.allowDTD for compatibility | §5a, §8 P2 |
XmlSchemaCollection.java line 745 | AccessController.doPrivileged wrapper for the SAX parse | §5 |
XmlSchema.java | serializer TransformerFactory sets FEATURE_SECURE_PROCESSING and disables external DTD/stylesheet access where supported | §5a, §8 P2 |
xmlschema-core/src/main/java/.../resolver/DefaultURIResolver.java | URL composed from baseUri + schemaLocation; no filtering | §3 item 7, §9 SSRF disclaim, §10 item 1, §11 first bullet |
xmlschema-core/src/main/java/.../resolver/URIResolver.java | Resolver interface — caller-pluggable | §2 caller-roles, §10 item 1 |
xmlschema-walker/src/main/java/.../docpath/DomBuilderFromSax.java line 81 | factory.setFeature(XMLConstants.FEATURE_SECURE_PROCESSING, TRUE) | §5a, §8 P2 |
xmlschema-walker/src/main/java/.../docpath/XmlSchemaPathFinder.java | Configurable per-document limits on decision points and replayed events | §4, §5a, §6, §12 |
xmlschema-walker/src/main/java/.../walker/XmlSchemaWalker.java and XmlSchemaScope.java | Active-path cycle detection for schema expansion | §4, §6, §8 P5 |