La política de mismo origen (SOP) hace que los navegadores bloqueen las secuencias de comandos de un origen para confundirlas con otras, a menos que se le indique explícitamente que no lo haga. Sin embargo, los POST entre sitios aún están permitidos, lo que crea el vector para los ataques CSRF. La defensa es tokens anti-falsificación.
Pero, ¿por qué los desarrolladores de navegadores no siguen la misma filosofía de SOP cuando tratan con POST?
En teoría, su sugerencia es perfectamente razonable. Si los navegadores bloquean todas las solicitudes POST de origen cruzado de forma predeterminada, y se requiere una política CORS para desbloquearlas, muchas de las vulnerabilidades de CSRF desaparecerán mágicamente. Como desarrollador, solo debe asegurarse de no cambiar el estado del servidor en las solicitudes GET. No se necesitarían fichas. Eso sería bueno.
Pero no es así como se construyó Internet en el pasado, y no hay forma de cambiarlo ahora. Hay muchos usos legítimos de las solicitudes POST de origen cruzado. Si los navegadores cambiaran repentinamente las reglas a mitad del juego y lo prohibieran, los sitios que confían en las reglas antiguas dejarán de funcionar. Romper los sitios existentes de esa manera es algo que intentamos evitar en la mayor medida posible. Lamentablemente tenemos que vivir con nuestro pasado.
Entonces, ¿hay alguna forma en que podamos ajustar el sistema para que funcione mejor sin romper nada? Una forma sería introducir un nuevo verbo HTTP, llamémoslo PEST, que funciona como POST solo que todas las solicitudes PEST están marcadas previamente y sujetas a las políticas CORS. Esa es solo una tonta sugerencia que inventé, pero muestra cómo podemos desarrollar los estándares sin romperlos.
El problema no es el método de solicitud: CSRF también podría realizarse con una solicitud GET. El problema es que la información de autenticación como las cookies (de sesión) o el encabezado Authorization se incluyen automáticamente con la solicitud entre sitios, lo que hace posible el CSRF. Por lo tanto, la mitigación no sería prohibir que dichos métodos se usen dentro de solicitudes entre sitios, sino que no se envíe esta información de autenticación.
Con las cookies hay una propuesta para una marca de samesite que garantizaría que la cookie no se envíe dentro solicitudes a través del sitio. Desafortunadamente, la bandera actualmente solo está disponible en Chrome , pero estará disponible para Firefox con v60 en mayo de 2018 Además, habría sido mucho mejor si esta restricción estuviera habilitada de forma predeterminada y se necesitaría cambiar explícitamente para que sea menos segura (como en CORS) en lugar de ser insegura de forma predeterminada. Solo esto significaría un cambio serio en el comportamiento actual y probablemente rompería muchas aplicaciones existentes.
En parte no estoy de acuerdo con Anders en
Pero no es así como Internet se construyó en el pasado, y allí No hay forma de cambiarlo ahora.
Los desarrolladores de los principales navegadores tienen bastante poder para cambiar Internet y guiar a los desarrolladores web hacia la dirección que desean. Los datos obsoletos de POST en sitios cruzados serían posibles si se los considerara una amenaza importante. Hay ejemplos de dicho progreso en otras cosas, aunque no es repentino ni rápido:
Flash. Si bien antes se consideraba el futuro de la web, los principales navegadores han anunciado que no lo admitirán en el futuro y los desarrolladores web se están adaptando.
HTTPS ha sido forzado lentamente por los navegadores, con pequeños pasos para advertir que el HTTP simple es inseguro. Eventualmente, podemos ver un mundo donde el HTTP simple se asfixia lentamente hasta la muerte.
Me gustaría ver esto para desarrollar hacia la priorización de la seguridad sobre la compatibilidad más ampliamente. Naturalmente, un cambio tan grande no sería algo que se hiciera durante la noche, sino dar alternativas y desalentarlo primero. El camino para lograr esto podría ser así:
POST , que permite el consentimiento explícito. POST entre sitios sin el consentimiento. Desalentar POST en HTTP simple es bastante desalentador entre POST en el sitio, ambos en contra de los estándares. Esto es solo una pérdida consciente de compatibilidad con versiones anteriores, para aumentar la seguridad.
Lea otras preguntas en las etiquetas web-browser csrf same-origin-policy