Re: FAQ & Use Cases

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