[
https://issues.apache.org/jira/browse/RAMPART-428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Lazarski resolved RAMPART-428.
-------------------------------------
Resolution: Fixed
Fixed in 2.0.0.
Root cause: PolicyBasedResultsValidator.validateSignedPartsHeaders verified
signed
parts by element name only. For the SOAP Body it checked that *some* element
named
{http://schemas.xmlsoap.org/soap/envelope/}Body had been signed
(actuallySigned.contains(...)); the signed-header branch did the same by
QName. A
name-based check is defeated by signature wrapping: an attacker relocates the
signed
Body into a wrapper element and inserts a different, unsigned Body in the Body
position. The signature still verifies against the relocated original, but the
application consumes the unsigned Body - exactly the scenario in this report.
Fix: the validator now collects the actual DOM elements covered by the
signature
(from the WSDataRef protected elements) and verifies, by node identity
(Element.isSameNode), that the element the application will consume is the
very
element that was signed:
- the SOAP Body is resolved with WSSecurityUtil.findBodyElement(document)
and must
be the signed element (not merely a same-named one);
- signed headers / signed elements are validated the same way.
A relocated copy is a different node, so wrapped messages are now rejected
with
"bodyNotSigned" (or the corresponding signed-part fault).
Added PolicyBasedResultsValidatorTest, which reproduces a signature-wrapping
payload
(signed Body relocated into a header wrapper, arbitrary Body in place) and
asserts it
is rejected, while confirming the legitimate case (the actual signed Body) is
accepted. Verified with a full clean 'mvn verify -Papache-release' across all
modules
- including the signed-Body and signed-header integration scenarios and the
nine
policy samples - on OpenJDK 17/21/25.
> rampart passes the soap body different from the one used in validating
> against soap signature
> ----------------------------------------------------------------------------------------------
>
> Key: RAMPART-428
> URL: https://issues.apache.org/jira/browse/RAMPART-428
> Project: Rampart
> Issue Type: Bug
> Affects Versions: 1.6.2
> Reporter: Daniel
> Priority: Major
> Fix For: 2.0.0
>
>
> our hacking scenario:
> 1. the hacker first acquires a valid soap signature, including soap header
> and body
> 2. the hacker attacks the service by replaying the acquired soap message as
> follows:
> <soap envelope>
> <(replayed valid) soap header>
> ...
> <wrapper>
> <(replayed valid) soap body>...</soap body>
> </wrapper>
> </soap header>
> <(new arbitrary) soap body>
> ...
> </soap body>
> </soap envelope>
> 3. the soap message in 2. will pass rampart's signature verification as it
> uses the valid (replayed) body to check against the valid (replayed)
> signature. However, the problem is that rampart passes to applications the
> new (arbitrary) soap body, which effectively bypasses the security mechanism
> of xml signature. To foil the hack, rampart can pass the (replayed) body it
> checks against the (replayed) signature instead of the new (arbitrary) one.
> 4. security policy that we use:
> <wsp:Policy wsu:Id="SigOnly"
>
> xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd";
> xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy";>
> <wsp:ExactlyOne>
> <wsp:All>
> <sp:AsymmetricBinding
>
> xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy";>
> <wsp:Policy>
> <sp:InitiatorToken>
> <wsp:Policy>
> <sp:X509Token
>
> sp:IncludeToken="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/Never";>
> <wsp:Policy>
>
> <sp:RequireThumbprintReference />
> <sp:WssX509V3Token10 />
> </wsp:Policy>
> </sp:X509Token>
> </wsp:Policy>
> </sp:InitiatorToken>
> <sp:RecipientToken>
> <wsp:Policy>
> <sp:X509Token
>
> sp:IncludeToken="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/Never";>
> <wsp:Policy>
>
> <sp:RequireThumbprintReference />
> <sp:WssX509V3Token10 />
> </wsp:Policy>
> </sp:X509Token>
> </wsp:Policy>
> </sp:RecipientToken>
> <sp:AlgorithmSuite>
> <wsp:Policy>
> <sp:TripleDesRsa15 />
> </wsp:Policy>
> </sp:AlgorithmSuite>
> <sp:Layout>
> <wsp:Policy>
> <sp:Strict />
> </wsp:Policy>
> </sp:Layout>
> </wsp:Policy>
> </sp:AsymmetricBinding>
> <sp:Wss10
> xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy";>
> <wsp:Policy>
> <sp:MustSupportRefKeyIdentifier />
> <sp:MustSupportRefIssuerSerial />
> </wsp:Policy>
> </sp:Wss10>
> <sp:SignedParts
> xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy";>
> <sp:Body />
> <sp:Header Name="Action"
> Namespace="http://www.w3.org/2005/08/addressing"; />
> <sp:Header Name="To"
> Namespace="http://www.w3.org/2005/08/addressing"; />
> </sp:SignedParts>
> </wsp:All>
> </wsp:ExactlyOne>
> </wsp:Policy>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
