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

Mi sto approfondendo nello sviluppo di API RESTful e finora ho lavorato con alcuni framework diversi per raggiungere questo obiettivo. Ovviamente mi sono imbattuto nella stessa politica di origine e ora mi chiedo come i server Web (anziché i browser Web) lo applichino. Da quello che ho capito, sembra che alla fine del browser appaiano alcuni controlli (ad es. Onorare un'intestazione Access-Control-Allow-Origin ricevuta da un server). Ma per quanto riguarda il server?

Ad esempio, supponiamo che un server Web stia ospitando un'app Web Javascript che accede a un'API, anch'essa ospitata su quel server. Suppongo che il server applichi la politica della stessa origine, in modo tale che solo il javascript ospitato su quel server possa accedere all'API. Ciò impedirebbe a qualcun altro di scrivere un client javascript per quell'API e ospitarlo su un altro sito, giusto? Quindi, come potrebbe un server Web essere in grado di fermare un client dannoso che proverebbe a inviare richieste AJAX ai suoi endpoint API sostenendo di eseguire javascript originato dallo stesso server Web? Qual è il modo in cui i server più popolari (Apache, nginx) proteggono da questo tipo di attacco? O la mia comprensione di questo in qualche modo è fuori dal comune?

Oppure la politica di origine incrociata viene applicata solo sul lato client?

La stessa politica di origine è una restrizione interamente basata sul cliente ed è principalmente progettata per proteggere gli utenti , non i servizi . Tutti o la maggior parte dei browser include un'opzione della riga di comando o un'opzione di configurazione per disattivarlo. La SOP è come le cinture di sicurezza in un'auto: proteggono il pilota in macchina, ma chiunque può scegliere liberamente di non usarle. Certamente non aspettarti che la cintura di sicurezza di una persona impedisca loro di uscire dalla propria auto e attaccarti (o accedere al tuo servizio Web).

Supponiamo che io scriva un programma che accede al tuo servizio Web. È solo un programma che invia messaggi TCP che includono richieste HTTP. Stai chiedendo un meccanismo lato server per distinguere tra le richieste fatte dal mio programma (che può inviare qualsiasi cosa) 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 stessa politica di origine è stata inventata perché impedisce al codice di un sito Web di accedere a contenuti con credenziali limitate 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 lo SOP non fosse stato installato e avessi eseguito l'accesso a Gmail, lo script su evil.compotrebbe vedere la mia casella di posta. Se il sito su evil.comvuole caricare mail.google.comsenza i miei cookie, può semplicemente usare un server proxy; i contenuti pubblici di mail.google.comnon sono un segreto (ma i contenuti di mail.google.comquando si accede con i miei cookie sono segreti).

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 politica della stessa origine. Ad esempio, l'invio dell'intestazione

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

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

 Access-Control-Allow-Origin: *

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

I server Web generalmente impediscono attacchi di questo tipo controllando la Refererriga (notoriamente errata) nell'intestazione HTTP, per garantire che una richiesta provenga da una pagina sul proprio sito. Non esiste un buon modo per proteggersi da un client dannoso, ma non è così che funzionano gli attacchi XSRF.

Il client non è dannoso; è generalmente un utente ordinario che è stato indotto da una terza parte maliziosa ad aprire un documento che fa silenziosamente una richiesta HTTP utilizzando i cookie memorizzati del client. Quindi, se il server può verificare tramite la Refererrichiesta HTTP proveniente da gmail.com e non da MyAwesomeWebsite.com, può chiudere l'attacco.

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

In breve, non lo fanno, come hanno sottolineato apsiller e Dirk .
Un motivo importante è che l'intestazione ACAO protegge i server stessi dagli attacchi DDOS dilaganti, - Distributed Denial of Service - Attacchi .

Chi:

L'ACAO come intestazione di risposta HTTP è intesa per l'interpretazione del client Web, operando nel presupposto che la maggior parte degli utenti Internet umani stia navigando sul Web attraverso i principali fornitori di browser che aderiscono e implementano la bozza raccomandata dal W3C . Dopo tutto, dovrebbero beneficiare di una rete Internet veloce e accessibile.

Come:

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

Ecco perché devi optare per accedere a un sito di origine incrociata, tramite l'intestazione HTTP ACAO . L'utente può accedere a detto sito in qualsiasi momento attraverso un'interazione consapevole dell'utente, ad esempio un collegamento Internet. Proprio come è possibile copiare o incollare il contenuto dagli o negli appunti, ma non in altro modo, a parte i plug-in.

Futuro:

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

• rimozione del plugin predefinita , come passo verso un ambiente completamente sandbox
• rimuovendo l'opzione utente per disattivare javascript

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

"Google" ha questo da mostrare e dire su DDOS

Infine, chiunque è libero di delegare qualsiasi contenuto Web e aggiungere un'intestazione ACAO desiderata per accedere al contenuto proxy su più siti. Allo stesso modo, questo proxy è quindi aperto ad un attacco DDOS, come l'impostazione ACAO gli permette di essere. In realtà non conosco un'unica offerta di servizio pubblico gratuita. Perfavore, correggimi se sbaglio.

Come altri hanno detto, dipende dal cliente. Ma potrebbe essere necessario che il server abbia a che fare con XSS, che ignora SOP.

Supopse il tuo server consente agli utenti di caricare contenuti, che vengono visualizzati quando altri utenti navigano nel tuo sito. Questa pagina è un buon esempio: ho appena caricato il contenuto e ti viene mostrato.
Se il mio contenuto contiene il <script>tag e il server lo copia nel codice HTML che genera, 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. Può, ad esempio, votare questa risposta. Ed è per questo che questa risposta ha tanti voti positivi.

Un buon server web (come, ahimè, quello che StackExchange usa), non permetterà che ciò accada. Può rimuovere il <script>tag o sfuggirlo, quindi verrà visualizzato ma non eseguito (avviso: questa risposta è lungi dall'essere una ricetta affidabile per impedire XSS).

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