Need a way to reject execution of unsafe transforms

[GoogleCodeExporter]

What steps will reproduce the problem?
1. During signature verification, transforms are executed to obtain the 
Referenced data. Some transforms like XSLT allow the execution of user provided 
code. It easy to write an XSLT transform that takes a long time to execute or 
even enters an infinite loop. This can form the basis of a denial of service 
attack where the threads get consumed because they are busy executing the 
transform. One possible counter-measure is to agree to execute only the 
transforms that are deemed safe. What is considered safe should be left to the 
user judgement. In Santuario, this feature is not built-in, but is easy to 
implement. In Santuario, it is possible to parse the signature in a separate 
step before validation. The developer can easily add code to inspect the parsed 
signature. If the transforms are not acceptable, the validation is never 
called. This idiom does not work in XAdES4J because the signature parsing and 
validation is a single step. Maybe all that is required is a validation method 
that takes a parsed signature as argument plus a documented way to obtain that 
parsed signature.
2.
3.

What is the expected output? What do you see instead?
a means to execute user code between the signature parse and signature 
validation.

What version of the product are you using? On what operating system?
1.2.0
Windows 7

Please provide any additional information below.

Original issue reported on code.google.com by clementp...@gmail.com on 27 Oct 2011 at 2:09

[GoogleCodeExporter]

This document describes the Denial of Service attacks using transforms that I 
mentioned above: http://www.w3.org/TR/2011/WD-xmldsig-bestpractices-20110809/ 

Original comment by clementp...@gmail.com on 4 Nov 2011 at 2:20

[GoogleCodeExporter]

The Best Practice document above also mentions that we need to limit the 
maximum number of transforms that signature validation is willing to accept.

Original comment by clementp...@gmail.com on 4 Nov 2011 at 4:03

[GoogleCodeExporter]

Another possible solution is to have a custom validation provider that is 
passed the XMLSignature before the signature is actually validated. If this 
already exists in XAdES4J, then we need examples how to use it in the 
documentation.

Original comment by clementp...@gmail.com on 4 Nov 2011 at 4:06

[GoogleCodeExporter]

I think that an approach similar to CustomValidationProvider is the best option 
here, as you suggested. Something like a RawSignatureValidationProvider..

Original comment by luis.fgoncalv on 17 Nov 2011 at 9:27

• Changed state: Accepted

[GoogleCodeExporter]

This solution would work.

What do you have in mind for the types of arguments passed to the 
RawSignatureValidationProvider?

I'm asking because I'm wondering if you plan to pass the Santuario 
XMLSignature. This is acceptable, as long as you accept that XAdES4J will be 
tied to Santuario for ever (as opposed to being tied to JSR-105)

The same trade-off happened before in XAdESVerificationResult where the 
Santuario XMLSignature is already visible.

If you decide that XAdES4J does indeed expose Santuario underneath instead of 
completely hiding it, then I wonder why so few Santuario classes are reused. 
For example, why invent new Transform ParameterSpecs when Santuario already has 
them.

Either you embrace Santuario and expose it, or you abstract above it and 
completely hide it. Doing half-and-half like XAdES4J is doing now is strange.

Original comment by clementp...@gmail.com on 18 Nov 2011 at 5:46

[GoogleCodeExporter]

I had a problem with JSR105: the Reference's do not return dereferenced and 
transformed data prior to reference generation or validation 
(http://santuario.apache.org/Java/api/javax/xml/crypto/dsig/Reference.html#getDi
gestInputStream()). However, in XAdES there are some signed data object 
properties that need that data (prior to signature generation, of course). So I 
needed to switch to Santuario, that has that feature. The XMLSignature and 
Reference classes from Santuario  are exposed in other places, namely signature 
generation).

You're right, I should embrace it more, at least on the base XML-DSIG related 
actions. I'll review the recent transforms parameters upgrades.

As for the RawSignatureVerifier (or something like that) it will for sure 
receive XMLSignature, probably in a context class so that additional info can 
be added later. The purpose is to apply some verification rules at an early 
stage, after unmarshalling and before any kind of verification. The context 
could probably also include some raw qualifying properties data, but I'm not 
sure yet.

Original comment by luis.fgoncalv on 19 Nov 2011 at 8:31

[GoogleCodeExporter]

Original comment by luis.fgoncalv on 20 Nov 2011 at 4:21

• Changed state: Started

[GoogleCodeExporter]

Original comment by luis.fgoncalv on 20 Nov 2011 at 4:23

• Changed state: Fixed