Aprendizaje y análisis de la vulnerabilidad CORS

Estrategia de homología

La misma política de código ( Same, Origin Policy ) es una convención, una medida de seguridad muy importante es la función de seguridad más básica que deshabilita la escritura de diferentes fuentes para leer o modificar la página actual, lo que limita entre dominios Acceda o incluso modifique recursos para evitar la ocurrencia de situaciones extremadamente malas en las que la página A puede cambiar libremente la información en la página B.

　　Lo mismo hicieron lo que la estrategia de código restricciones? ¿Cómo puede considerarse dominio cruzado, con diferentes fuentes?

Tome http://www.a.com como ejemplo:

*Condición normal*	*http://www.a.com*	*Permitir*
*Diferentes nombres de dominio*	*http://www.b.com*	*No permitido*
*Diferentes acuerdos*	*https://www.a.com*	*No permitido*
*Diferentes puertos*	*http://www.a.com:10*	*No permitido*
*Subdominios diferentes*	*http://bp.a.com*	*No permitido*

　　Valor digno de mención son: estrategia homóloga se implementa en el navegador para que no pueda detener el envío de solicitudes y respuestas, cuando las peticiones de varios dominios para iniciar, de hecho, ha recibido el recurso solicitado, si queremos responder a interceptar el paquete, se puede Se descubre que el recurso solicitado ya está incluido en el paquete de respuesta. El navegador encuentra dominios cruzados. De acuerdo con la política del mismo origen, el navegador no permite que se cargue el recurso solicitado.

　　hack.com solicitará datosde test.com

　　El pelo ahora impide cumplir con la directiva del navegador origen de la carga de los recursos a través de dominios de lectura, entonces estos recursos realmente quiere leer simplemente no es enviado o ha sido enviado a su navegador desde la carga de la misma?

　　Puede ser en un ver muy claramente que el recurso solicitado se ha recibido, sino porque se bloquea fuente de diferentes navegadores.

¿Qué es CORS?

　　Con el progreso del desarrollo de los tiempos, la tecnología, la nueva demanda produjo gradualmente. La gente comenzó a tener la necesidad de solicitar recursos entre dominios. La política del mismo origen que prohíbe todas las solicitudes entre dominios es obviamente inapropiada, pero es aún más imposible abandonar la política del mismo origen, ya que permitir que las páginas de diferentes fuentes interactúen es un desastre. Bajo tales demandas y contradicciones, CORS nació.

　　Cruzada distribución de los recursos de dominio ( de intercambio de recursos de origen cruzado ), se refirió CORS, por lo que algunas páginas de diferentes fuentes pueden ser solicita recursos entre dominios de una página en particular.

　　C ORS depende del navegador. Si el navegador no es compatible con CORS, no se puede usar, pero casi no hay navegadores que no sean compatibles con CORS.　　

　　Al emitir una solicitud de dominio cruzado, el navegador agregará el campo Origen: xxx en el encabezado de la solicitud para indicar el origen de la solicitud de dominio cruzado. Cuando el servidor en el otro extremo recibe la solicitud con Origen , enviará la solicitud El recurso se devuelve en el mensaje de respuesta, y algunos campos que comienzan con Access-Control- se agregan al encabezado de respuesta. Solo dos de ellos deben preocuparse:

Access-Control-Allow-Origin: su valor solo puede ser un URI de un dominio externo o * (solo un URI o * no se puede escribir como Access-Control-Allow-Origin: http: //a.com,http: //b.com como este, aunque es muy conveniente, pero no está permitido, solo se permite un URI después de este campo, el siguiente dirá un método para establecer múltiples dominios que permiten sitios cruzados) , este valor es permitir fuente de peticiones entre dominios, después de recibir una respuesta al navegador que en el campo no se inicia la petición URI de origen , si es * permitir que todas las solicitudes de nombres de dominio. Si los dos son iguales, se permite la solicitud de dominio cruzado y el recurso solicitado en la respuesta se cargará en el navegador.
Access-Control-Allow-Credentials: el valor de este campo solo puede ser verdadero, entonces los datos recibidos contienen cookies y, si este campo no está configurado, no se envían cookies.

　　Como esto, por CORS, se puede lograr entre el entre dominios acceso a varios dominios específicos.

Configuración de CORS:

　　Reparación cambiarlo anfitriones, simular dos sitios diferentes:

192.168.10.103 www.test.com 
192.168.10.103 www.hack.com

　　Prensa de acuerdo con su propia situación modificada ip,

Si la solicitud entre sitios es exitosa, se mostrará el éxito,

La URL solicitada, http://www.test.com/test/test.php

<? php 
echo 'éxito' ;
?>

URL para iniciar solicitud de dominio cruzado, http://www.hack.com/test/1.html

<! DOCTYPE > 
< html > 
< p > Hola < p > 
< script type = "text / javascript" > 
prueba de función () 
{ 
    var ajax =  new XMLHttpRequest (); 

    ajax.onreadystatechange = function () 
    { 
        if (ajax.readyState ==  4  && ajax.status ==  200 ) 
        { 
            var text = ajax.responseText; 
            document.write (text) 
        }
    } 
    ajax.open ( " GET " , " http://www.test.com/test/test.php " , " true " ) 
    ajax.send (); 
} 
prueba (); 
</ script > 
</ html >

Solicite recursos de test.com en la página hack.com:

Mostrar que las solicitudes de solicitud xmlhtt entre dominios están prohibidas

<? encabezado php
 ('Access-Control-Allow-Origin: http: //www.hack.com' );
echo 'éxito' ;
?>

Agregar el campo Access-Control-Allow-Origin permite que la fuente de hack.com solicite recursos en todos los sitios.

Acceso exitoso entre sitios.

　　Cuando cambiamos Access-Control-Allow-Origin a http://www.a.com :

Falló nuevamente.

Vulnerabilidad

　　Fuga causas del agujero producido se pueden dividir en dos, sus causas están en el Access-Control-Allow-Origen de , cuando se configuran como asteriscos * , la secuencia de comandos de cualquiera de un nombre de dominio puede solicitar toda la información en esta página , Lo que equivale a deshabilitar manualmente la política del mismo origen. La razón de esto es extremadamente improbable, porque a menos que sea una persona completamente inexperta, nadie lo establecerá en * . Otra razón es mucho mayor que la primera, porque el descuido o la negligencia del programador causaron la falta de correspondencia.

Partido incompleto :

　　Este tipo de problema se produce cuando ciertas reglas para confirmar si ha de iniciar peticiones entre dominios se les debe permitir el acceso a la fuente, las reglas de coincidencia tienen defectos, que sólo confirmó que una cierta parte del cumplimiento de las normas debe ser considerada como una fuente de confianza, tales como:

El http://www.test.com/test/test.php cambio

<?php
$origin = $_SERVER['HTTP_ORIGIN'];
$pattern = '#www.a.com#';
preg_match($pattern,$origin,$match);
if ($match)
{
    header('Access-Control-Allow-Origin:'.$origin);
}
echo 'success';
?>

　　这段代码中，只要匹配到www.hack.com，并没有确认其他部分的内容就简单的判断允许跨域请求，当攻击者使用 www.a.com.hack.com 时，很容易就骗过了规则，成功发起跨域请求并接收。

　　再举个例子，当匹配规则为确认 a.com 在Origin末尾时才允许访问，显然上面一个例子中的方法不再适用，这时仍可以构造 bbbbbbba.com 这样的域名来突破限制。

　　道高一尺魔高一丈，匹配规则有很多，突破方法有更多，这里就不一一列举了。

　没有转义：

　　当用正则表达式进行匹配时，URI中存在着许多点 . 像 bp.a.com , tieba.baidu.com , www.billbill.com 小数点.这个符号在正则表达式可以代替着任意一个字符，如果想让其仅仅代表.这个符号本身而不是匹配任何一个字符的话，应当使用转义符\. ,但很多人往往总会忘记转义，如在上述的代码中就没有进行转义：

http://www.test.com/test/test.php中注意：

$pattern = '#www.a.com#';

　　当我们使用 www.aacom.com , www.wwwaaacom.com , www.wwwaa.com 在 . 的位置随意写上一个字符就可以突破限制，正确写法应该是www\.a\.com

　　当头设置了Access-Control-Allow-Credentials:true时，恰巧产生了CORS漏洞，危害会大大增加，因为向其发起跨域请求时，它会将cookie一起发送，这是及其不希望看到的，也是非常危险的，读取了页面上的一些信息有时或许无伤大雅，但读取了cookie很多时候都是非常恐怖的。

漏洞检测与利用

　　CORS漏洞会加强xss的攻击力，哪怕是反射型的xss也增加了许多可能性。

　　检测CORS的方式可以通过不断修改Origin，检测响应中的Access-Control-Allow-Origin的值是否与Origin相同，如若相同，则存在CORS漏洞，github上有一个CORS漏洞的检测工具CORScanner，当检测到CORS时，可以这样利用：

<script>
var ajax = new XMLHttpRequest();
ajax.open('GET','http://xxx','true');
ajax.onload = main;
ajax.withCredentials = true;
ajax.send()

function main(){
xxx
}

　　其中，ajax.withCredentials = true;这一段代码的作用是将Access-Control-Allow-Credentials:true设置为true以允许读取cookie，提升危害，main中写入可以读取敏感数据birucookie并将其发送给攻击者的代码，诱使受害者执行这段代码，就可以达到获取重要信息的目的。

------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

　　总体来说，CORS漏洞现在看来危害并不是特别大，但是千里之堤溃于蚁穴，无论怎样的漏洞都要有足够的重视，既是对自己负责，也是对他人负责、

Aprendizaje y análisis de la vulnerabilidad CORS

Supongo que te gusta