Muestra las diferencias entre dos versiones de la página.
Ambos lados, revisión anteriorRevisión previaPróxima revisión | Revisión previa | ||
app:inses [2024/10/17 15:59] – thejuanvisu | app:inses [2024/10/24 15:28] (actual) – thejuanvisu | ||
---|---|---|---|
Línea 31: | Línea 31: | ||
http:// | http:// | ||
</ | </ | ||
+ | ### | ||
Esto se considera una vulnerabilidad, | Esto se considera una vulnerabilidad, | ||
+ | ### | ||
+ | |||
===== Política de mismo origen ===== | ===== Política de mismo origen ===== | ||
- | (EXAMEN) Define una serie de reglas para restringir como un documento o sus scripts puede interactuar con los recursos localizados en dominios diferentes. Esta es implementada por el navegador web. 2 Webs tienen el mismo dominio si el protocolo, dominio y puerto son el mismo. Las escrituras entre dominios suelen estar permitidas (enlaces, redirecciones y envío de formularios de tipo XMLHttpRequiest y Fetch API). Los navegadores suelen bloquear las escrituras entre dominios por defecto (Peticiones Ajax por ejemplo). | + | ### |
+ | (EXAMEN) Define una serie de reglas para restringir como un documento o sus scripts puede interactuar con los recursos localizados en dominios diferentes. Esta es implementada por el navegador web. 2 Webs tienen el mismo dominio si el protocolo, dominio y puerto son el mismo. Las escrituras entre dominios suelen estar permitidas (enlaces, redirecciones y envío de formularios de tipo XMLHttpRequiest y Fetch API). Los navegadores suelen bloquear las escrituras entre dominios por defecto (Peticiones Ajax por ejemplo). | ||
+ | |||
+ | ### | ||
+ | |||
+ | ### | ||
+ | JSONP o JSON con Padding es una técnica de javascript para realizar llamadas asíncronas a dominios diferentes. Los script con atributo src tienen permitido apuntar a otro dominio dentro de la política de mismo origen. Si desde un script se accede a algo que devuelva JSON se producirá un error de sintaxis. Los servidores con JSONP permiten las peticiones que envíen un parámentro jsonp o callback. Cuando estos parámetros están presentes en la solicitud, la respuesta del servidor devuelve el contenido JSOn dentor de la función especificada como parámetro. De esta forma se consigue devolver un contenido JavaScript en vez de uno JSON. | ||
+ | |||
+ | ### | ||
+ | |||
+ | ===== Intercambio de recursos de orígenes cruzados (CORS) ===== | ||
+ | CORS es un mecanismo que permite al navegador web enviar peticiones AJAX a dominios diferentes. Se distinguen 2 tipos de peticiones: | ||
+ | ==== CORS en Peticiones Simples ==== | ||
+ | Peticiones HEAD, GET o POST. CORS tiene que estar habilitado en el sitio web. El navegador enviará la cabecera Origin en la petición. Se configura en el servidor web y lo implementa el navegador. En la resuesta el servidor envía varias cabeceras con el prefijo Access-Control-*: | ||
+ | * **Access-Control-Allow-Origin** (Obligatoria): | ||
+ | * **Access-Control-Expose-headers**: | ||
+ | * **Access-Control-Allow-Credentials**: | ||
+ | ==== CORS en peticiones Complejas ==== | ||
+ | Peticiones que NO sean HEAD, GET o POST, como por ejemplo, PUT o DELETE y aquellas peticiones que no utilizan cabeceras simples. En este caso el navegador va enviar una petición de preflight y recibirá las siguientes cabeceras: | ||
+ | * **Access-Control-request-Method**: | ||
+ | * **Access-Control-Request-Headers**: | ||
+ | |||
+ | En respuesta a la petición preflight el servidor puede responder con las siguientes cabeceras: | ||
+ | * **Access-Contol-Allow-Origin** (Obligatoria): | ||
+ | * **Access-Control-Allow-Methords**: | ||
+ | * **Access-Control-Allow-headers**: | ||
+ | |||
+ | ===== Cross-Site Request Forgery (CSRF o XSRF) ===== | ||
+ | |||
+ | Es una vulnerabilidad en la que el atacante usa el navegador de la víctima para ejecutar peticiones maliciosas en su nombre sobre una web vulnerable. El contenido malicios viene del servidor hacia el navegador, se explota la confianza del navegador en las peticiones autenticadas. Funciona de la siguiente forma: | ||
+ | - El usuario se autentica creando un identificador de sesión que se instala en su navegador | ||
+ | - El atacante envía un enlace al usuario que, usando la sesión del usuario, ejecuta una petición en su nombre. | ||
+ | |||
+ | Un requisito para este tipo de ataque es que el usuario debe estar logueado. Otro requisito es que el atacante debe ser capaz de enviar al usuario una petición maliciosa. Esta vulnerabilidad se aprovecha de que las peticiones HTTP sean repetibles ya que los parámetros que se envían son siempre los mismos, no hay componentes aleatorios que varíen cada vez. Para paliar esto se establece un campo aleatorio en los formularios. | ||
+ | |||
+ | Para prevenir estos ataques se debe comprobar que la cabecera HTTP tenga ciertas cabeceras y añadir un token en las peticiones (CSRF Token) que se debe regenerar cada sesión, de forma que no sea repetible y que el atacante no pueda reproducir el formulario de forma sencilla. | ||
+ | * Analizar cabeceras Origin, Refer y Host para determinar la procedencia. El navegador no permite modificar estas cabeceras con javascript. | ||
+ | * El CRFS Token debe tener las siguientes características: | ||
+ | * Único por sesión | ||
+ | * Valor aleatorio de tamaño largo | ||
+ | * Generado por un algoritmo criptográfico. | ||
+ | * En las aplicaciones con estado el token se puede almacenar en la sesión. | ||
+ | * Las peticiones deben incluir este token como parámetro o en alguna cabecera. | ||
+ | * El servidor compara el token de la petición y el de la sesión de forma que si estos no coinciden se descarta la petición | ||
+ | * El token NO debe ir en la URL | ||
+ | * En algunas ocasiones no es viable almacenar el token de sesión, por lo que se envía una cookie doble (Double Submit Cookie) | ||
+ | * Las cookies con el atributo SameSite permiten especificar que no se envíe la cookie si la petición viene de un servidor diferente. | ||
+ | * Otra medida de seguridad podría ser el uso de doble autenticación. | ||