Si nunca quiero que se acepten solicitudes de origen cruzado, ¿puedo ignorar CORS?

14

La especificación CORS indica que si un método de solicitud y encabezados no son simple luego se envía una solicitud de OPCIONES HTTP de verificación previa para ver si la solicitud está permitida por el servidor.

Mi servidor no responde con ningún encabezado específico de CORS, por lo que supongo que esto significa que la solicitud será denegada. Una firma de seguridad recientemente me dijo que esto significa que la solicitud siempre será aceptada si no la rechazo específicamente con los encabezados de CORS, pero me resulta difícil de creer.

Además, algunos navegadores más antiguos no implementan CORS en absoluto, así que me pregunto si hay un agujero de seguridad aquí en el que estos navegadores puedan omitir la comprobación de CORS. ¿O estos navegadores simplemente siempre niegan todo?

Resumen: nunca quiero que se acepten solicitudes de origen cruzado. ¿Hay un agujero de seguridad con solo pretender que CORS no existe?

    
pregunta Jarrod Everett 27.08.2012 - 20:43
fuente

3 respuestas

15

No. No hay ningún agujero de seguridad en pretender que CORS no existe. CORS es una política de opt-in. Siempre que su servidor nunca envíe encabezados CORS (nunca se inscriba), los navegadores continuarán utilizando la política estándar del mismo origen. Puedes pretender que CORS no existe, para que tu vida sea simple: esa es una estrategia perfectamente razonable.

CORS es opcional: puedes usarlo si quieres sus funciones adicionales, pero también es perfectamente correcto ignorarlo y nunca usarlo. Esto es por diseño. Cualquier otra cosa estaría loca. Hay millones de sitios web que se escribieron antes de CORS y que nunca se cambiarán. Diseñar un estándar que durante la noche hiciera que todos esos sitios web sería una locura. Los escritores de normas CORS no están locos. Ellos no hicieron eso. (De hecho, se tomaron grandes molestias no para hacer eso!)

Sospecho que ha habido algún malentendido o malentendido con su empresa de seguridad (o posiblemente su empresa de seguridad esté equivocada). Que yo sepa, está bien que una aplicación web nunca envíe ningún encabezado CORS.

Dicho esto, do necesita comprender CSRF. CSRF es una vulnerabilidad fundamental en la web (una que es anterior a CORS y es ortogonal a CORS). Por lo tanto, por favor lea sobre esto. Encontrará una gran cantidad de excelentes recursos en CSRF en las páginas web de OWASP y en este sitio. La defensa estándar contra CSRF es usar tokens de CSRF para todas las solicitudes HTTP que puedan tener algún efecto secundario.

    
respondido por el D.W. 28.08.2012 - 08:31
fuente
2

¿Estás tratando de asegurar el cliente o el servidor? Tengo entendido que CORS está destinado a proporcionar una forma para que las aplicaciones del lado del cliente (por ejemplo, scripts) accedan a recursos fuera de la "política del mismo origen". Los navegadores que cumplen con los estándares no deberían permitir que los scripts recuperen recursos fuera de sus dominios (por ejemplo, a través de una solicitud AJAX) en ausencia del encabezado HTTP Access-Control-Allow-Origin, así que creo que la respuesta a su pregunta es que no tiene preocuparse por eso Sin embargo, CORS / la política del mismo origen es impuesta por el cliente, por lo que no sé qué podría hacer en el lado del servidor para denegar las solicitudes de origen cruzado, excepto para no permitirlas explícitamente con ese encabezado.

    
respondido por el iX3 27.08.2012 - 22:31
fuente
2

Cuando su servidor web recibe una solicitud, solo ve lo que el cliente le envió. No tiene información de lo que está sucediendo en el navegador, incluso si hay un navegador (suponga que alguien usó curl o wget para realizar la solicitud). Por lo tanto, la responsabilidad de prevenir CSRF es principalmente del navegador, y si un navegador antiguo no hace nada para evitarlo, esas solicitudes serán respetadas.

Hay muchas técnicas para prevenir el CSRF que no tiene nada que ver con CORS. Uno de los AFAIK más efectivos es el uso de un token CRSF: envíe un token aleatorio al cliente (almacenándolo en la cookie del sitio) y espere que vuelva a aparecer en cada envío que necesite proteger. Suponiendo que está utilizando SSL, no hay forma de que un atacante (que no tiene acceso a la cookie) sepa qué es el token, por lo que no puede falsificar una solicitud válida.

    
respondido por el mgibsonbr 27.08.2012 - 22:37
fuente

Lea otras preguntas en las etiquetas