Re: XmlHttpRequest
Hello!
Jim Ley wrote:[color=blue][color=green]
>>This "security risk" is not so different from embedding pages using
>>iframes. If example.com page outputs HTML (which is more prevalent than
>>XML/XSLT), everybody can embedd example.com on their own pages using
>>iframes.[/color]
>
> no, this is completely wrong, the security risk is much, much higher,
> these embedding or image src techniques are one way, you can't read
> what you get back. This severely limits what you can do.[/color]
I think, this is debatable. And before we continue to evaluate the level of
"security risk" one of these techniques generates, I suggest we should
clarify *what* the "bad guys" (got a better term for them?) want to do.
Example: If they succeed by just submitting information, then not being able
to read back doesn't help anything.
[color=blue][color=green]
>>I reckon, using a cunningly designed parent page you could add your own
>>submit buttons underneath the iframe and deceive the user to click them,
>>sending a request that's completely under the control of example.org.[/color]
>
> So it would submit, none of the fields would be sent from the field
> the user entered in the other form.[/color]
I just wanted to give an example how you could submit forged data *on
behalf* of the user without using XmlHttpRequest. You are right, this way
you don't get any information from the user. So my anwser fits better to
the posting from Matt Kruse and does not belong here.
In fact, Martin was talking about "page spoofing". And that would be
realized not using iframes but creating a copy of the original page and
storing it on example.org (bad server).
[color=blue]
> Yes, which is a completely different thing to xmlhttprequest. cross
> domain xmlhttprequest would make phishing a very diffent activity, you
> could just do live man in middle attacks from inside the users
> browser, not a good idea![/color]
Sounds interesting, an "intra-browser" attack. :-)
True, denying cross domain XmlHttpRequests raises the bar to gather user
information. But then, once you got the user on example.org or
http://www.ghoogle.com he is lost anyway.
Cheers
Daniel
Hello!
Jim Ley wrote:[color=blue][color=green]
>>This "security risk" is not so different from embedding pages using
>>iframes. If example.com page outputs HTML (which is more prevalent than
>>XML/XSLT), everybody can embedd example.com on their own pages using
>>iframes.[/color]
>
> no, this is completely wrong, the security risk is much, much higher,
> these embedding or image src techniques are one way, you can't read
> what you get back. This severely limits what you can do.[/color]
I think, this is debatable. And before we continue to evaluate the level of
"security risk" one of these techniques generates, I suggest we should
clarify *what* the "bad guys" (got a better term for them?) want to do.
Example: If they succeed by just submitting information, then not being able
to read back doesn't help anything.
[color=blue][color=green]
>>I reckon, using a cunningly designed parent page you could add your own
>>submit buttons underneath the iframe and deceive the user to click them,
>>sending a request that's completely under the control of example.org.[/color]
>
> So it would submit, none of the fields would be sent from the field
> the user entered in the other form.[/color]
I just wanted to give an example how you could submit forged data *on
behalf* of the user without using XmlHttpRequest. You are right, this way
you don't get any information from the user. So my anwser fits better to
the posting from Matt Kruse and does not belong here.
In fact, Martin was talking about "page spoofing". And that would be
realized not using iframes but creating a copy of the original page and
storing it on example.org (bad server).
[color=blue]
> Yes, which is a completely different thing to xmlhttprequest. cross
> domain xmlhttprequest would make phishing a very diffent activity, you
> could just do live man in middle attacks from inside the users
> browser, not a good idea![/color]
Sounds interesting, an "intra-browser" attack. :-)
True, denying cross domain XmlHttpRequests raises the bar to gather user
information. But then, once you got the user on example.org or
http://www.ghoogle.com he is lost anyway.
Cheers
Daniel
Comment