vuln Intercambio de recursos de origen cruzado: origen arbitrario de confianza

Navega tus respuestas
1

Tengo algunos problemas para ejecutar CORS respons form burp  La aplicación permitió el acceso desde el origen solicitado enlace solicitud 

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

respuesta 

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

Me pregunto si es una vulnerabilidad o no, y cómo no puedo explotar

    
pregunta doglife 22.01.2017 - 12:15
fuente

2 respuestas

5

https://xrmtfgxgjkzw.com es solo un ejemplo generado por Burp. Lo que en realidad dice es que cualquier sitio web en Internet que el usuario esté visitando puede capturar contenido de su sitio (posiblemente privado para un usuario) si también está conectado a él.

El escenario es el siguiente:

  1. Bob inicia sesión en su sitio, example.com .
  2. Bob recibe un correo electrónico del atacante que dice que puede ver algunas fotos geniales de gatos en https://xrmtfgxgjkzw.com .
  3. Bob hace clic y ve las imágenes de dichos gatos.
  4. Mientras que el sitio del atacante muestra las imágenes a Bob, realiza algunas solicitudes AJAX en segundo plano a https://example.com/user/messages y lee la bandeja de entrada privada de Bob en su sitio.
  5. Debido a que los encabezados Access-Control-Allow-Origin y Access-Control-Allow-Credentials CORS están establecidos, la Política del mismo origen no es aplicado y permite a https://xrmtfgxgjkzw.com leer las respuestas.

Tenga en cuenta que lo anterior es solo una vulnerabilidad si los encabezados se imprimen en páginas confidenciales (es decir, aquellas que contienen datos privados del usuario) o páginas que emiten tokens secretos, incluidos tokens anti-CSRF.

Si no es necesario permitir orígenes arbitrarios, solo debe generar el encabezado Access-Control-Allow-Origin para los orígenes en los que confía su sitio. Si su sitio es autónomo, no es necesario permitir ningún origen.

WordPress contiene un controlador JSON en /wp-json/oembed/1.0/embed?url= que se usa cuando el usuario incrusta un enlace a un artículo de WordPress en un dominio de terceros (por ejemplo, en una publicación de Facebook). Esta es una funcionalidad estándar de WordPress y no permite el acceso a ningún dato confidencial, sin embargo, sería mejor si no generaran el encabezado Access-Control-Allow-Credentials si no fuera necesario en caso de que existan errores no descubiertos o no revelados en el controlador. Mi mejor conjetura es que esto es así para que el contenido autenticado se pueda incrustar en dominios de terceros. Como el enlace se considera secreto, esto evita que cualquier dominio aleatorio lo solicite. Algunos detalles aquí con respecto a oEmbed.

    
respondido por el SilverlightFox 22.01.2017 - 12:43
fuente
1

Me he topado con el mismo problema, y creo que Wordpress está permitiendo esto para que estas llamadas específicas permitan la incorporación de contenido en otros sitios.

Así que creo que esta es una funcionalidad pensada, y no un error de seguridad.

    
respondido por el Mark Koek 01.02.2017 - 14:44
fuente

Lea otras preguntas en las etiquetas

¿Cómo es mejor HMAC que MAC? [cerrado] HTTPS - Tener TLS configurado en el equilibrador de carga