[
Lists Home |
Date Index |
Thread Index
]
Sebastian Schnitzenbaumer:
>And I agree too, of course. But that wasn't the issue. I never
>asked about VBscript in my XSL in the first place. And I
>wasn't aware how harmful XSL can be. An XML stylesheet
>wasn't meant to be a security problem in the first place,
>and extending it for some 20% cases (allowing scripts) so it is
>treated as a security problem for the other 80% cases (just
>using XSL as it is) doesn't make sense to me
Well I'm afraid this really goes beyond Microsoft's implementation to
the XSL-T specification, since the specification gives you the ability
to define extension functions and these can be written in whatever
language the processor-implementor wants. Most processors have extension
functions written in Java, again a security hazard for cross-domain
XSL-T, although other processor-implementors can of course make their
own decisions a propos security. I don't really like comparing css and
xsl-t as the latter is a programming language, and as a small one has
been provided with a mechanism to extend it.
>Why
>can't just the stylesheets with scripts get the quarantine
>behaviour? Why must every cross-domain XSL be treated as if
>it would contain a malicious script, even though it doesn't use
>script at all?
This is one of those whys that I'm sure we all the know the reason for,
that Programmer X saw that there was a problem Y that he just didn't
have the time to give the best solution, so he just decided to restrict
it. Perhaps at some time in the future Programmer X will come back to
the problem and say "I'll fixe that now" but I really doubt it
especially as I have a hard time seeing the utility of cross-domain
calling of XSL-T, if I want to use one from another domain I'll copy it
and send the original author a nice email telling them I'm using their
XSL-T.
|
