Cross-Site XMLHttpRequest

[cvele]

Verovatno je vecina ovo vec videla, mada je meni promaklo
http://ejohn.org/blog/cross-site-xmlhttprequest/

Nesto se nadam da ce IE8 implementirati ovu ideju i kod sebe buduci da su oba browsera trenutno u beti, postoji prostor za implementaciju novih ideja. (mada... ie je to)

[ivanhoe]

meni i dalje nije jasno zasto je ovo uopste bilo zabranjeno, in the first place?
Mogu cross-domain slike, mogu skripte, mogu forme, a ajax su zabranili ?

[cvele]

Nemogu skripte, probaj recimo da pristupis iframe koji napravi adsense. Nije uopste fora u Ajax-u(koji inace nije nista drugo nego javascript ), vec JavaScript moze da radi samo u okviru jednog domena.

Inace, prvi (ili drugi) hit sa googleta kaze:

About Cross-Frame Scripting and Security

With Dynamic HTML (DHTML), content in different windows and frames can interact in powerful ways by scripting with the object model. However, since a browser can simultaneously display unrelated documents in its various windows and frames, certain rules must be enforced to protect data integrity and privacy of information.

This article describes how and why these restrictions apply in the DHTML Object Model. All rules about script interaction apply equally to windows, dialog boxes, frameSets, frames, and iframes.

For most content, only interactions with content from the same domain are allowed. For example, a typical page on www.microsoft.com can freely script content on any other page on www.microsoft.com, but cannot script to pages that are located on a different Web domain. The DHTML Object Model uses the document.domain property to enforce this restriction: only pages with identical domain properties are allowed free interaction. The protocol of the URL must also match. For instance, an HTTP page cannot access HTTPS content.

The range of permissible access for a page can be expanded when a script assigns the document.domain property to a suffix of the site name space, up to the second-level domain. For example, a page on www.microsoft.com can assign the document.domain property—initially www.microsoft.com—as microsoft.com to broaden access to include pages in home.microsoft.com or any other site, as long as the other pages also set the document.domain property to the identical value. Since only pages from a site whose name ends with microsoft.com will permit this domain to be set, it is assured that content from the same provider mutually agrees to interact and is free to do so. Domain suffixes shorter than the second-level domain (such as just "com") are not allowed, because they expose beyond a single provider. For international site names, such as www.microsoft.co.jp, the second-level domain for widest access would be "microsoft.co.jp" (not "co.jp").

Since it is important to be able to navigate windows or frames to any URL beyond the domain restriction, these types of accesses are always permitted. Only access that attempts to read out or modify content is restricted. For instance, the href property might be assigned to cause navigation to occur, but this property cannot be read if the URL is of a different domain. This would allow one page to learn where the user has been browsing, and to allow this is a breach of the user's privacy. Some restrictions that apply to pages of different domains include:
window.location.href Property can be set to navigate, but cannot be read.
Other window.location.href Functionality is blocked.
document.location.href Property can be set to navigate, but cannot be read.
Other document.location.href Functionality is blocked.
iframe.src Property can be set to navigate, but cannot be read.

Scripts that attempt to access parts of the object model to which they do not have access are blocked with a "permission denied" error.

While domain security can prevent certain types of content interaction, it is important to understand that this restriction is necessary to ensure security. For example, without domain security, a rogue page could "snoop" on another page or, using DHTML, manipulate its content.

[ivanhoe]

ne ne, sad mesas babe i zabe, ne govorim o cross-frame scriptingu, to treba za bude zabranjeno jer realno predstavlja pretnju po sigurnost, jasna stvar.

Pricam o ucitavanju sadrzaja sa drugog domena, jer mozes da ucitas javascript sa koje god zelis externe lokacije (stavis src="google.com/neki_skript.js" i to ce se ucitati), zasto onda ne moze XHR da radi isto to po defaultu? Citao sam dosta na tu temu, ali nisam nasao objasnjenje koji su konkretni napadi moguci ako se dozvoli cross-domain ajax ? Takodje zasto bi slanje zahteva kroz proxy bilo sigurnije od direktnog slanja zaheva na taj domen? Svi tekstovi na tu temu su ili genericki: "to je opasno, ako posumnjas u to goreces u paklu", ili su objasnjenja tipa: "mozda to uzme programer koji nema pojma, pa uradi nesto glupo sa tim (kao da to generalno ne vazi uvek)"

[cvele]

Kapiram odakle ti zabuna, ali pazi to su sustinski iste stvari... mislim na cross domain scripting i cross domain ajax. Isto kao sto mozes ucitati neku sliku sa drugog domena, mozes i javascript fajl, to nije zabranjeno. Ali nemozes, primera radi, upravljati DOMom drugog domena sa javascriptom sa svog domena, kao sto nemozes uraditi XMLHttpRequest koji je sustinski samo js objekat i nista drugo.

Cross domain ajax je ustvari fraza koja je evoluirala od cross domain scripting-a, zato sto za njime postoji legitimna potreba za razligu od parenta

[cvele]

sorry, zaboravih da dodam. cross frame je uzet kao primer jer se tako najlakse demonstrira sta se podrazumeva sa cross domain scriptingom.

kao primer uzmi sledece, ucitaj frame sa svog domena... i pristupices mu normalno ali ucitaj google u frame i neces moci da mu pristupas.

[akubra]

Originalno napisao ivanhoe

Pricam o ucitavanju sadrzaja sa drugog domena, jer mozes da ucitas javascript sa koje god zelis externe lokacije (stavis src="google.com/neki_skript.js" i to ce se ucitati), zasto onda ne moze XHR da radi isto to po defaultu? Citao sam dosta na tu temu, ali nisam nasao objasnjenje koji su konkretni napadi moguci ako se dozvoli cross-domain ajax ?

Jedan konkretan primer. Preko XMLHttpRequest-a, sa neke svoje strane, posaljes zahtev (obican HEAD je dovoljan) na neki drugi sajt, koji ima autentikaciju i za to koristi kukije, i onda sa getAllResponseHeaders() pokupis headere koje vraca taj server. Tu se nadje svasta zanimljivo, sesisije, korisnicka imena, lozinke.