An adversary corrupts or modifies the content of XML schema information passed between a client and server for the purpose of undermining the security of the target. XML Schemas provide the structure and content definitions for XML documents. Schema poisoning is the ability to manipulate a schema either by replacing or modifying it to compromise the programs that process documents that use this schema.

How does a XML Schema Poisoning attack work?

It typically unfolds over 3 phases. It begins with: [Determine if XML schema is local or remote] Because this attack differs slightly if the target uses remote XML schemas versus local schemas, the adversary first needs to determine which of the two are used.

How do you prevent CAPEC-146?

Design: Protect the schema against unauthorized modification.

What weaknesses does CAPEC-146 target?

CAPEC-146 exploits 2 CWE weaknesses, including CWE-15 (External Control of System or Configuration Setting), CWE-472 (External Control of Assumed-Immutable Web Parameter).

How severe is CAPEC-146?

MITRE rates CAPEC-146 as High severity with low likelihood of attack.

CAPEC-146: XML Schema Poisoning

How the attack works

The phases an attacker typically follows to carry out this attack.

Step 1
Explore
[Determine if XML schema is local or remote] Because this attack differs slightly if the target uses remote XML schemas versus local schemas, the adversary first needs to determine which of the two are used.
Step 2
Experiment
[Gain access to XML schema] The adversary gains access to the XML schema so that they can modify the contents.
- For a local scenario, the adversary needs access to the machine that the schema is located on and needs to gain permissions to alter the contents of the file.
- For a remote scenario, the adversary needs to be able to sniff HTTP traffic that contains an XML schema.
Step 3
Exploit
[Poison XML schema] Once the adversary gains access to the XML schema, they will alter it to achieve a desired effect. Locally, they can simply modify the file. For remote schemas, the adversary will alter the schema in transit by performing an adversary in the middle attack.
- Cause a denial of service by modifying the schema so that it does not contain required information for subsequent processing. For example, the unaltered schema may require a @name attribute in all submitted documents. If the adversary removes this attribute from the schema then documents created using the new grammar may lack this field, which may cause the processing application to enter an unexpected state or record incomplete data.
- Manipulation of the data types described in the schema may affect the results of calculations. For example, a float field could be changed to an int field.
- Change the encoding defined in the schema for certain fields allowing the contents to bypass filters that scan for dangerous strings. For example, the modified schema might use a URL encoding instead of ASCII, and a filter that catches a semicolon (;) might fail to detect its URL encoding (%3B).

How the attack works

CAPEC-146: XML Schema Poisoning

Overview

How the attack works

What the attacker needs

Prerequisites

Resources required

Consequences

How to mitigate it

Examples

Frequently asked questions

What is CAPEC-146?

How does a XML Schema Poisoning attack work?

How do you prevent CAPEC-146?

What weaknesses does CAPEC-146 target?

How severe is CAPEC-146?

References

Defend against CAPEC-146

How the attack works

Overview

How the attack works

What the attacker needs

Prerequisites

Resources required

Consequences

How to mitigate it

Examples

Related weaknesses

Related attack patterns

Parent

Frequently asked questions

What is CAPEC-146?

How does a XML Schema Poisoning attack work?

How do you prevent CAPEC-146?

What weaknesses does CAPEC-146 target?

How severe is CAPEC-146?

References

Defend against CAPEC-146