vuln Condivisione delle risorse tra origini: origine arbitraria attendibile

2

Ho qualche problema a esaltare il modulo di risposta CORS  L'applicazione ha permesso l'accesso dal link all'origine richiesta richiesta

GET wp-json/oembed/1.0/embed?url=https%3A%2F%2Fwww.foo.com%2Fblog%2%2F HTTP/1.1
Host: www.foo.com
Accept: */*
Accept-Language: en
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Win64; x64; Trident/5.0)
Connection: close
Referer: https:foo.com
Cookie: TitleTrial=0; PitchTrial=0; __utma=223462276.2101520464.1484064735.1484839851.1485078453.10; __utmz=223462276.1485078453.10.4.utmcsr=fo|utmccn=(referral)|utmcmd=referral|utmcct=/fo; __distillery=8b8098c_148a7b11-3d02-465d-801a-c732e38c665f-14f1b05a3-cdd505b2b245-71f8; muxData=mux_viewer_id=2da4d2cf-1d56-4a49-9ee7-ff8da48f9416&msn=0.4423908694377975&sid=01c7e9f7-c253-4583-9e0c-89b4bbdc60b9&sst=1485078466920&sex=1485080221025; visitor_id77672=228495947; __atuvc=1%7C2%2C2%7C3; PHPSESSID=ke08cd41dm7p6dcfrfepnhat73; __utmc=223462276; __utmt=1; visitor_id77672-hash=__utmb=223462276.7.10.1485078453; pardot=had5nb89omptc2e886vpgqju83; wordpress_test_cookie=WP+Cookie+check; 
Origin: https://xrmtfgxgjkzw.com

risposta

HTTP/1.1 200 OK
Date: Sun, 22 Jan 2017 10:52:02 GMT
Server: Apache/2.2.15 (CentOS)
X-Powered-By: PHP/5.6.28
Set-Cookie: wordpressuser_7d2ee02a401bf41376509ec6471db505=+; expires=Sat, 23-Jan-2016 10:52:02 GMT; Max-Age=-31536000; path=/blog/
Set-Cookie: wordpresspass_7d2ee02a401bf41376509ec6471db505=+; expires=Sat, 23-Jan-2016 10:52:02 GMT; Max-Age=-31536000; path=/blog/
X-Content-Type-Options: nosniff
Access-Control-Expose-Headers: X-WP-Total, X-WP-TotalPages
Access-Control-Allow-Headers: Authorization
Allow: GET
Access-Control-Allow-Origin: https://xrmtfgxgjkzw.com
Access-Control-Allow-Methods: POST, GET, OPTIONS, PUT, DELETE
Access-Control-Allow-Credentials: true
Vary: Accept-Encoding,User-Agent
Content-Length: 2663
Connection: close
Content-Type: application/json; charset=UTF-8

Mi chiedo se sia un vuln o meno e come non posso sfruttare

    
posta doglife 22.01.2017 - 12:15
fonte

2 risposte

5

https://xrmtfgxgjkzw.com è solo un esempio generato da Burp. In realtà, quello che sta dicendo è che qualsiasi sito web su Internet che l'utente sta visitando può prelevare contenuti dal tuo sito (possibilmente privato per un utente) se sono anche registrati in esso.

Lo scenario è il seguente:

  1. Bob accede al tuo sito, example.com .
  2. Bob riceve un'email dall'attaccante che gli dice che può guardare alcune fantastiche immagini di gatti a https://xrmtfgxgjkzw.com .
  3. Mario fa clic e visualizza le immagini di gatto dette.
  4. Mentre il sito degli utenti malintenzionati visualizza le immagini su Bob, fa alcune richieste AJAX di sottofondo a https://example.com/user/messages e legge la posta in arrivo privata di Bob sul tuo sito.
  5. Poiché le intestazioni Access-Control-Allow-Origin e Access-Control-Allow-Credentials CORS sono impostate, la stessa politica di origine non è applicato e consente a https://xrmtfgxgjkzw.com di leggere le risposte.

Tieni presente che quanto sopra è solo una vulnerabilità se le intestazioni vengono pubblicate su pagine sensibili (ad esempio quelle che contengono dati utente privati) o pagine che generano token segreti, inclusi token anti-CSRF.

Se non è necessario consentire origini arbitrarie, devi solo generare l'intestazione Access-Control-Allow-Origin per le origini ritenute affidabili dal tuo sito. Se il tuo sito è autonomo, non è necessario consentire alcuna origine.

WordPress contiene un gestore JSON in /wp-json/oembed/1.0/embed?url= che viene utilizzato quando un collegamento a un articolo di WordPress è incorporato in un dominio di terze parti dall'utente (ad esempio in un post di Facebook). Questa è la funzionalità standard di WordPress e non consente l'accesso ad alcun dato confidenziale, tuttavia sarebbe meglio se non emettessero l'intestazione Access-Control-Allow-Credentials se non fosse necessario nel caso in cui vi fossero alcuni bug non scoperti o non rivelati nel gestore. La mia ipotesi migliore è che il contenuto autenticato possa essere incorporato in domini di terze parti. Poiché il collegamento è considerato segreto, impedisce a qualsiasi dominio casuale di richiederlo. Alcuni dettagli qui riguardo a oMed.

    
risposta data 22.01.2017 - 12:43
fonte
1

Ho incontrato lo stesso problema e penso che Wordpress stia consentendo a queste chiamate specifiche di consentire l'incorporamento di contenuti in altri siti.

Quindi penso che questa sia intesa funzionalità, e non un bug di sicurezza.

    
risposta data 01.02.2017 - 14:44
fonte

Leggi altre domande sui tag