In che modo i server Web applicano la politica della stessa origine?

La stessa politica di origine è una restrizione interamente basata su client ed è progettata principalmente per proteggere utenti , non servizi . Tutti o quasi tutti i browser includono un commutatore di linea di comando o un'opzione di configurazione per disattivarlo. Le SOP sono come le cinture di sicurezza di un'automobile: proteggono il pilota in auto, ma chiunque può liberamente scegliere di non usarle. Certamente non aspettarti che le cinture di sicurezza di una persona impediscano loro di scendere dalla loro auto e di attaccarti (o di accedere al tuo servizio Web).

Supponiamo che scriva un programma che accede al tuo servizio Web. È solo un programma che invia messaggi TCP che includono richieste HTTP. Stai chiedendo un meccanismo sul lato server per distinguere tra le richieste fatte dal mio programma (che può inviare qualcosa) e le richieste fatte da un browser che ha una pagina caricata da un'origine consentita. Semplicemente non può essere fatto; il mio programma può sempre inviare una richiesta identica a quella formata da una pagina Web.

La politica della stessa origine è stata inventata perché impedisce a un sito web di accedere a contenuto limitato dalle credenziali su un altro sito. Le richieste Ajax vengono inviate di default con qualsiasi cookie di autenticazione concesso dal sito di destinazione. Ad esempio, supponiamo di caricare accidentalmente http://evil.com/ , che invia una richiesta per http://mail.google.com/ . Se il SOP non era a posto, e io ero collegato a Gmail, lo script in evil.com poteva vedere la mia casella di posta. Se il sito in evil.com vuole caricare mail.google.com senza i miei cookie, può semplicemente utilizzare un server proxy; il contenuto pubblico di mail.google.com non è un segreto (ma il contenuto di mail.google.com quando si accede con i miei cookie è un segreto).

La politica della stessa origine viene applicata sul lato client. Se il browser supporta CORS , il server può inviare indietro le intestazioni che indicano al browser di fare eccezioni alla stessa origine politica. Ad esempio, l'invio dell'intestazione

 Access-Control-Allow-Origin: www.example.com

direbbe al browser di consentire le richieste di origine incrociata da www.example.com.

 Access-Control-Allow-Origin: *

indica al browser di consentire tutte le richieste di origine incrociata a quella risorsa.

I server Web in genere impediscono gli attacchi di questo tipo controllando la riga Referer (erroneamente errata) nell'intestazione HTTP, per garantire che una richiesta provenga da una pagina sul proprio sito. Non c'è un buon modo per proteggersi da un client malevolo, ma non è così che funzionano gli attacchi XSRF.

Il client non è dannoso; in genere si tratta di un utente ordinario che è stato indotto da una terza parte malintenzionata ad aprire un documento che esegue automaticamente una richiesta HTTP utilizzando i cookie memorizzati del client. Quindi, se il server può verificare tramite Referer che la richiesta HTTP proviene da gmail.com e non da MyAwesomeWebsite.com, può chiudere l'attacco verso il basso.

How do web servers enforce the same-origin policy?

In breve, non lo fanno, come sottolineato apsillers e Dirk .
Un motivo importante è che l'intestazione ACAO protegge i server stessi da DDOS rampanti, - Distributed Denial of Service- attacchi .

Chi:

L'ACAO come intestazione di risposta HTTP è inteso per il client web da interpretare, operando nel presupposto che la maggior parte degli utenti di internet umani naviga nel web attraverso i principali fornitori di browser che aderiscono e implementano il bozza consigliata W3C . Dovrebbero, dopo tutto, la maggior parte di loro beneficiare di un accesso veloce e accessibile.

Come:

Altrimenti chiunque potrebbe semplicemente copiare e incollare alcune righe di codice javascript in un sito Web malevolo che esegue un ciclo semplice, che rende una richiesta di GET o POST di Ajax a un dominio straniero. Senza interazione dell'utente e capacità di multithread.

Ecco perché devi attivare per accedere a un sito di origine incrociata, tramite l'intestazione HTTP ACAO . Tu, l'utente, puoi accedere a detto sito in qualsiasi momento attraverso un'interazione utente-consapevole, cioè un collegamento Internet. Proprio come te puoi copiare o incollare il contenuto da o verso gli appunti, ma non in altro modo - plug-in a parte.

Futuro:

A quel punto, osserva la direzione del produttore del browser web di:

• default rimozione del plugin , come passo verso un ambiente completamente in sandbox e
• rimozione dell'opzione utente per disattivare javascript

Le restrizioni di sicurezza possono essere decentemente stabilite utilizzando una combinazione di TSL 2/3, ID sessione strong, TAN, autenticazione a due fattori ecc.

'Google' ha questo per mostrare e dire su DDOS

Infine, chiunque è libero di delegare qualsiasi contenuto web e aggiungere un'intestazione ACAO desiderata per accedere al contenuto cross-site dei proxy. Allo stesso modo, questo proxy è quindi aperto a un attacco DDOS, come l'impostazione ACAO consente di essere. In realtà non conosco una singola offerta di servizio pubblico gratuita. Per favore correggimi se sbaglio.

Come altri hanno detto, dipende dal cliente. Ma il server potrebbe dover gestire XSS, che bypassa SOP.

Supopse your server consente agli utenti di caricare il contenuto, che viene visualizzato quando altri utenti navigano nel tuo sito. Questa pagina è un buon esempio: ho appena caricato i contenuti e ti viene mostrato.
Se il mio contenuto contiene il tag <script> e il server lo copia semplicemente nel codice HTML generato, verrà eseguito lo script che ho caricato.
Poiché lo script è stato trovato in HTML dal tuo file, ha tutte le autorizzazioni dello script del tuo sito. Ad esempio, può aumentare questa risposta. Ed è per questo che questa risposta ha così tanti voti positivi.

Un buon server web (come, ahimè, quello che usa StackExchange), non permetterà che questo accada. Può rimuovere il tag <script> o scappare, quindi verrà visto ma non eseguito (attenzione: questa risposta è lontana da una ricetta affidabile per prevenire XSS).

Quindi è il lato client che impone SOP, ma in alcuni casi il server dovrebbe funzionare per evitare di bypassarlo.