- From: Jonas Sicking <jonas@sicking.cc>
- Date: Fri, 18 Jan 2008 13:41:59 -0800
- To: Jon Ferraiolo <jferrai@us.ibm.com>
- CC: Anne van Kesteren <annevk@opera.com>, "WAF WG (public)" <public-appformats@w3.org>, public-appformats-request@w3.org
Jon Ferraiolo wrote: > >Cookies and authentication information is already sent cross-site for the > >HTML <img>, <script>, and <form> elements so this does not introduce a new > >attack vector. It simply makes use of the Web. > > <img> and <script> only work with GET, so if a web server follows best > practices (i.e., only support POST when submitting data), then you > aren't subject to data submission attacks. There is no way to retrieve > data via <img>, so that doesn't allow data retrieval attacks. With > <script>, the only way to retrieve data is if the server supports > JSON-with-callback. Also, the last sentence here isn't true at all. There are lots of other ways script data could be readable. Take a random javascript file and you'll see that they usually set lots of variables and define many functions. An evil page can currently enumerate its global scope, source a javascript file from a third party server, and then enumerate the global scope again. This way the page can see all variables defined and their values, as well as all functions and their full code. If any variables or functions contain sensitive data then this data can be read by any site. This scares the crap out of me and I strongly suspect that the vast majority of people putting javascript on intranet sites or password protected sites do not think of this. Unfortunately any good fix to this that I can think of would break the web. In any case it is not a security model I want to encourage. / Jonas
Received on Friday, 18 January 2008 21:43:08 UTC