Verifica le impostazioni CORS non sicure con cURL

0

Sto provando a verificare le impostazioni CORS di un sito web usando cURL. Il seguente comando dovrebbe permettermi di verificare se le impostazioni CORS possono essere considerate sicure o se è possibile effettuare richieste tra le origini.

Sto eseguendo un controllo di preflight, ma lo stesso dovrebbe funzionare con la normale richiesta e l'intestazione di origine.

Verifica preliminare:

curl -H "Origin: https://example.local" \
  -H "Access-Control-Request-Method: POST" \
  -H "Access-Control-Request-Headers: X-Requested-With" \
  -X OPTIONS -D - -o /dev/null\
  -x http://127.0.0.1:8080/\
  https://example.com

Ottieni con origine:

  curl -H "Origin: https://example.local"\
  -D - -o /dev/null\
  https://example.com

Ora quello che non capisco è che l'applicazione di destinazione risponde semplicemente con il contenuto come al solito. Nessuna Access-Control-Allow-Origin , Access-Control-Allow-Methods e Access-Control-Allow-Headers intestazioni.

Quindi non sono in grado di decidere se le impostazioni CORS siano sicure o meno. Ho provato a proxyare le richieste tramite Burp (con i due metodi seguenti), ma c'è qualcosa di sbagliato lì e la richiesta non raggiunge mai Burp.

Metodo 1 cURL:

curl [...] -x http://127.0.0.1:8080/ [...]

Metodo 2 CLI:

export https_proxy='https://127.0.0.1:8080/'
export http_proxy='http://127.0.0.1:8080/'

curl [...]

export https_proxy=''
export http_proxy=''

Che cosa può causare lo strano comportamento dell'applicazione web con le mie richieste di pre-volo OPTIONS e la richiesta GET con l'intestazione di origine. Come posso eseguire correttamente il proxy della richiesta tramite Burp per verificare la richiesta stessa?

    
posta SaAtomic 15.11.2017 - 16:20
fonte

1 risposta

4

Devi solo specificare l'intestazione di origine nella tua richiesta. L'applicazione risponderà con le intestazioni Access-Control- *. Prova solo a specificare l'intestazione di origine e a vedere come si presenta il risultato.

Se le intestazioni non vengono restituite, il server Web non deve rispondere con una politica CORS. In caso contrario, il browser non consentirà le richieste di origine incrociata come al solito. CORS consente al server di abilitare richieste di origine incrociata in base a determinati criteri.

Il problema principale che riscontro quando eseguo il test dei problemi CORS è che l'intestazione Access-Control-Allow-Origin viene popolata da ciò che viene inviato tramite l'intestazione Origin nella richiesta. Ciò sconfigge l'intero scopo di CORS. Un utente malintenzionato non dovrebbe essere in grado di definire le origini consentite.

Ci sono diverse estensioni Burp che segnaleranno errori di configurazione e problemi di sicurezza correlati a CORS. C'è anche questo post sul blog di Portswigger che descrive alcune errate configurazioni comuni.

link

    
risposta data 15.11.2017 - 16:59
fonte

Leggi altre domande sui tag