Stessa pentesting della politica di origine?

As we all know that what is the SOP? As its very popular. But my question arises when, pentesting this functionality.

AS SOP provide the website to call the resources only from its domain. Ex. http: //example.com/ have the SOP functionality then Only resources can call from this (example.com) domain.

Prima di andare avanti e provare a pentestare, hai bisogno di una comprensione più che vaga di come funziona. I webdoc MDN di Mozilla forniscono un ottimo punto di partenza .

How the attacker might get damage this? I think its very simple functionality. So i want to know about what vulnerabilities can arise here?.

La politica della stessa origine (SOP) è un controllo di sicurezza a livello di browser che stabilisce in che modo un documento o uno script appartenente a un'origine può interagire con una risorsa proveniente da un'altra origine. Fondamentalmente, SOP impedisce che gli script in esecuzione in un'unica origine provengano da dati di lettura di un'altra origine. In alcuni casi è necessario che un'app consenta altre origini per l'accesso alle risorse. Questo risultato si ottiene utilizzando Condivisione delle risorse di origine incrociata . Ci possono essere potenziali problemi di sicurezza dovuti a errate configurazioni CORS. Esistono fondamentalmente due modi in cui CORS consente le comunicazioni cross-source:

1. Intestazioni di controllo di accesso : per ogni richiesta su più domini, il server delle risorse emette le intestazioni di controllo dell'accesso in risposta che indicano se è possibile fornire l'accesso richiesto. Per comprendere appieno come e quando queste intestazioni vengono utilizzate e come vengono interpretate dai browser, rimando ai riferimenti MDN.

Recentemente i ragazzi di PortSwigger hanno trovato un post sul blog , evidenziando vulnerabilità derivanti da errate configurazioni CORS.

2. API postMessage HTML5 : il metodo Window.postMessage (), introdotto in HTML5, consente al codice JavaScript in esecuzione su origini diverse di comunicare tra loro in modo bidirezionale. per esempio. Questa API può essere utilizzata per la comunicazione tra un iframe e il suo documento principale.

Questo post sul blog mette in evidenza la potenziale sicurezza problemi nelle implementazioni dell'API postMessage.

Letture consigliate:

Perché la stessa politica di origine è così importante?

Come si correla CSRF con la stessa origine privacy

Per sfruttare i servizi Web con SOP abilitato, l'attenzione si sposta da XSS a lanci di dati utente anomali e sfruttando le vulnerabilità che forniscono all'aggressore un metodo per ospitare / manipolare i dati ospitati sul dominio stesso del server di origine.

Un approccio lato client sarebbe indirizzare le richieste DNS / proxy per example.com verso una destinazione canaglia / malevola, ma questo porta le cose al livello di rete e non è una vera e propria penetrazione del servizio web stesso. Ad esempio attacchi di rete man-in-the-middle o trick sul lato client usando qualcosa come un poisontap .

Spero che questo sia il tipo di informazioni che stavi cercando.