Re: Cross Domain XMLHttpRequest

["Michal Majchrowicz" <m.majchrowicz () gmail com>]

Hi.
I think it is security matter. I don't think that whole
XMLHttpRequests should be cross domain. Just a small part of it...
Using my script you can create an evil javascript code that will
interact with user in real time. You can create (I already did it) a
script that will contact some kind of server application and "infect"
all vulnerable links on some site and "react" to the users behavior.
In other words you are able to create "interactive" codes. Depending
on the date/subpage/cookies/etc you are able to "download" dynamic JS
code. There many situations where Real Time is very important. For
instance: let's assume, that you sent an email to john () yahoo com and
john opened your mail. You exploited XSS vulnerability in Yahoo and
you "installed" your own JS code that every 10 seconds contacts you
and reports what is going on. After 2 hours (let's assume that john
didn't log out) he gets and important mail from his boss. You are
informed about it and can "download" the contents of this mail. You
read the mail and notice that john (in response to boss' mail) asked
him for the account number to pay for something (let's assume it is
related to his work). So you have everything you need to sent fake
mail and john will pay you :) This is only theoretical situation but
in fact (till now) there wasn't any (really useful) method to perform
(for instance) very complicated Social Engineering using only XSS
attacks.
Regards Michal.

On 4/15/07, Michal Zalewski <lcamtuf () dione ids pl> wrote:
> On Sun, 15 Apr 2007, Michal Majchrowicz wrote:
>
> > I wanted to show that it is posssible to perform some kind of Cross
> > Domain Requests.
>
> As much as I loathe the origin-based security model of modern web
> browsers, there are semi-valid reasons why XMLHttpRequest is restricted
> the way it is.
>
> A remote attacker can interact with much of the Internet on its own. Your
> browser is an asset for him for three primary reasons:
>
>   1) It might have access to a network that is not directly reachable
>      from the Internet, for example a corporate LAN,
>
>   2) It might be in possession of authentication tokens that enable it
>      to access resources the attacker has no access to (web cookies,
>      basic/NTLM credentials).
>
>   3) It might serve as a bounce host to hide the actual source of an
>      attack against a third-party site (or, say, even simply adding
>      spam to web forums).
>
> For these reasons, you do not want your browser to roam the Internet on
> its own, and all mechanisms that allow this should be restricted. This is
> already broken, of course - blind XSRF attacks are possible with plain
> HTML - but unrestricted XMLHttpRequest would be a powerful, non-blind, and
> fully interactive method that would be nearly impossible to stop.
>
> Your script does not invalidate the need for XMLHttpRequest restrictions -
> note that there is nothing for you to be gained from running it on your
> server: you won't see more network than you can see already, you will not
> receive cookies or other credentials that were not meant for you, and you
> won't be able to hide your identity while attacking others.
>
> Some web developers may benefit from such a bouncer, of course - but this
> is really not a security-related topic; and still, they should be
> cautious, because they might end up turning their system in a nifty zombie
> host.
>
> /mz

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/