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
