I don't want this to sound like a throw-away line, because I sincerely mean
it:
Flexibility is the natural enemy of security.
Bells and whistles have a nasty habit of turning into doors and windows. As
Microsoft has experienced time and time again, the more accommodating you
make a piece of code, the harder it is to say what it cannot be made to do.
As the number of variables grow, the complexity of making it robust to
attacks goes up rather quickly. Heck even XMLSec learned this (look at the
papers that tell you to turn off half of the features of XMLSec. The fact
that you actually can do this to the Apache library is one of my favorite
features, btw).
There is of course a slippery slope in the other direction. No features
means you've become the charicature of the grumpy security 'expert' who
never lets anybody do anything at all. The right answer, to me, is to agree
to support (almost) as many features as you believe you can handle properly,
know your own strength, and know that there are always a lot more features
requested in version 2.
I use the Sun URL/URI processing code because I remember when it wasn't
secure, and why they secured it. In order to make the applet sandbox
actually work, and WebApp security to work, you have to parse URLs properly
and consistently. If you get it wrong, like IIS did, Very Bad Things happen
(eg, the Code Red Virus). I know that Sun has done far more to harden its
URL processing than I ever could, and I've been dealing URLs almost as long
as anybody. I have bigger problems to worry about, like getting the PKI
right and whether some jerk can send XSLT bombs to my most resource
constrained machine.
-Jason
PS:
At any rate, that doesn't explain not using URI in the JDK 1.6 library.
On Tue, Nov 11, 2008 at 6:10 AM, Sean Mullan <[EMAIL PROTECTED]> wrote:
> Laugh all you want :), but an API dependency on java.net.URI would have
> ruled out support for JDK 1.2/1.3, which was important at the time (but
> maybe not so much anymore).
>
> Just escape the space and it should work:
>
> factory.newReference("My%20document/test.txt", ...);
>
> --Sean
>
> jason marshall wrote:
>
>> Did you URL encode before passing the String form of the URI in to the
>> Reference? I pass my URIs as URI objects until the last moment, so that I
>> don't have to chase down encoded/unencoded data paths through the code.
>> Saves me a lot of headaches and some potential security holes.
>>
>> -Jason
>>
>> (I will never understand why both xmlsec and the Java dsig API have so
>> many method arguments called "String uri". You are all certainly welcome to
>> try to explain, but I will simply laugh at you if you do. I may point at
>> the same time.)
>>
>>
>>
>> On Tue, Nov 11, 2008 at 12:13 AM, Ling Xiaohan <[EMAIL PROTECTED]<mailto:
>> [EMAIL PROTECTED]>> wrote:
>>
>> Hi,
>>
>> URI attribute of <Reference> tag can be set to a relative path in
>> local file
>> system, but when the path contains blank space, it seems this
>> <Reference>
>> tag coulde not be created by XMLSignatureFactory.newReference method.
>>
>> Ex.,
>> <Reference URI="My document/test.txt">
>> where there is a space in "My document".
>>
>> Is this a limit?
>>
>> Thanks.
>>
>> ----------------------------------------------------------------------------
>>
>>
>>
>>
>>
>> --
>> - Jason
>>
>
>
--
- Jason
