[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
Re: [xml-dev] Re: Javascript and plugging holes
- From: Kurt Cagle <kurt.cagle@gmail.com>
- To: Henri Sivonen <hsivonen@iki.fi>
- Date: Sun, 12 Dec 2010 22:02:44 -0500
Henri,
Sorry for the follow-up post here so soon after the other one, but I wanted to make a correction regarding cross domain XML.
The cross domain issues of XML come about once that XML is inserted into the active DOM of a given document - if I were to load XML that contained inline JavaScript, for instance, into the DOM such that it was evaluated, then such XML would obviously be a security hole. However, instantiating the XML as a stand-alone DOM instance (or better yet, extending Javascript to allow for a distinct XML type a la E4X), should not by itself result in any processing. In that sense, the declarative nature of XML is in fact more secure than Javascript over the wire, a point that Tim Berners Lee alluded to at the 2007 IWC in Japan that I attended. Similarly, the document() tag in XSLT or XLST2 does not evaluate JavaScript or invoke CSS - it simply creates a stand-alone DOM that can be traversed via the corresponding transformation. That's one of the arguments, in fact, for incorporating such tools at a more standard level within the browser, because so long as you are working with XML in its context AS XML, it is semantically neutral - there are no behaviors or bindings associated with it.
Where things can get interesting is when you take such XML and insert it into the DOM, at which point it DOES become semantically charged. I would contend, however, that the same solution applies here as would apply with Javascript - you mark the XML content as being potentially tainted if it falls outside of the security envelope unless it is specifically exempted by both the developer and the user, and you invoke a blocking dialog that will not permit the operation unless the user specifically allows the domain access. This would hold for document() or the XQuery doc() as well, which should be under the same constraint as the XMLHttpRequest object anyway.
Kurt Cagle
XML Architect
Lockheed / US National Archives ERA Project
On Sun, Dec 12, 2010 at 7:37 PM, Henri Sivonen
<hsivonen@iki.fi> wrote:
On Dec 10, 2010, at 09:36, Simon St.Laurent wrote:
> On 12/10/10 10:02 AM, Stephen Green wrote:
>>> At the same time, Mobile Device manufacturers are pushing for the opposite.
>>> They want JS to do MORE not LESS.
>>
>> The virus-script-kiddies haven't paid so much attention to smartphones
>> yet, I guess.
>
> There are lots of security holes in JavaScript and the Web environment, and many of them happen to work on phones too now.
I think saying that there is a lot of holes is a mischaracterization. Rather, there are a handful of fundamental big gotchas that require Web app developers to be careful in order to be able to write apps that don't have information leaks and don't enable unauthorized actions given the way the Web's security model is.
It's virtually impossible to fix the fundamental gotchas, because people really like to exploit them for convenience in non-malicious ways. Even in this thread, there's been the undertone that browsers are somehow being anti-XML when they enforce the Same Origin Policy for XHR. The restriction isn't there in order to be annoying. It's there for security. When a restriction is missing, people love to exploit the lack of restriction e.g. by including scripts and images cross-origin from CDNs or by POSTing forms cross-origin. If XHR hadn't been Same-Origin early on, people on this mailing list would have been using it cross-origin all over the place and it would be impossible to "fix" it without breaking too many sites.
Crockford makes what he says sound profound, but in that interview, he made two actual suggestions:
1) Stop and fix security first.
2) Use the security model of Google Caja.
I general, suggestions of the form "drop everything until you've addressed my concern" isn't really a realistic way to do things. It's pretty sad that people take Crockford seriously on that type of rhetoric.
As for "let's use this other security model instead", it's not really realistic to take a massively deployed system and swap out its fundamental security model. (It might be possible to let sites optionally relax the Same Origin Policy in Caja-esque ways and Content Security Policies may have success in optionally restricting things for defense-in-depth, but making security policies more "flexible"--i.e. complicated--means even more ways for Web app developers to shoot selves and their users in the feet.)
I expect you haven't seen this less polite take on Crockford's writing on the topic:
http://diveintomark.org/archives/2008/02/21/the-bolero-of-troll
--
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
