Estrategia de token de CSRF

En el contexto de CSRF y XSS, el atacante está obligado por la Política del mismo origen . Se puede usar XSS para omitir la Política del mismo origen y realizar cualquier acción como usuario. Donde el objetivo de CSRF es realizar una acción específica, y esto está permitido porque esa acción carece de una prueba de trabajo. Si una solicitud carece de un token CSRF o prueba de trabajo, por lo tanto, es vulnerable a CSRF.

Además, el acceso a los datos por la ID del miembro, que se pasa como un parámetro GET, es mucho peor que CSRF y XSS. Esto se llama Referencia de objeto directo inseguro (IDOR). En pocas palabras, la aplicación permite a los usuarios modificar datos que no son de su propiedad. En este contexto, el atacante no está obligado por la Política del mismo origen, el atacante tiene permitido enviar solicitudes HTTP arbitrarias a su servidor para obtener lo que desean. Para proteger la identificación del miembro, debe ser una variable $_SESSION .

Este formulario propuesto es probablemente vulnerable tanto a IDOR como a CSRF.

Recomiendo leer todos los OWASP top 10 .

La falsificación de solicitudes de sitios cruzados (también conocida como ataques CSRF o XSRF) es un ataque que permite a los atacantes ejecutar acciones no deseadas en una aplicación web en la que un usuario está autenticado actualmente. El ataque es posible cuando la aplicación de destino no valida correctamente el origen de la solicitud y se basa únicamente en la existencia de una sesión válida entre el navegador de la víctima y el servidor de la aplicación.

En el escenario más común de un ataque CSRF, un usuario que haya iniciado sesión accederá a una página web adicional proporcionada por el atacante en otra pestaña del navegador. Esta página apuntará de inmediato a una función sensible dentro de la aplicación, que todavía está abierta en la otra pestaña, mediante el envío de una solicitud especialmente diseñada. Dado que la solicitud se envía desde el mismo navegador, la aplicación vulnerable aceptará la solicitud y ejecutará la acción.

LaprotecciónadecuadadeCSRFsebasaenevitarquelosatacantespuedancrearunasolicitudgranulardeaccionesenunsistema.Unasoluciónparaestetipodeataqueesimplementartokensaleatoriosúnicosparaformulariossensibles.Paracadaenvíodeformulario,eltokendebevalidarseenelladodelservidor.

Comonotaalmargen,estostokenssiempredebenenviarseutilizandoelmétodoPOST.Normalmentesesuministrancomouncampodeformulariooculto.

AquíhayunejemplodeimplementacióndeCSRFparaPHP:

1. GenerandountokenCSRFseguroenPHP

functiongenerateCSRFKey($key){$token=base64_encode(openssl_random_pseudo_bytes(16));$_SESSION['csrf_'.$key]=$token;return$token;}

¡Puedeestartentadoausarrand()ouniqid()peroambosafirmanespecíficamentequeestasfuncionesnodebenusarseparagenerartokensseguros!Además,base64_encode()soloseusaparaasegurarsedequeelvalornorompaningúncódigoHTML.

function checkCSRFKey($key, $value) {
    if (!isset($_SESSION['csrf_' . $key]))
        return false;
    if (!$value)
        return false;

    if ($_SESSION['csrf_' . $key] !== $value)
        return false;

    unset($_SESSION['csrf_' . $key]); 
    return true;
}

" name="token">

$token = $_POST['token'];
if (checkCSRFKey('settings', $token)) {
    // Handle error
}

En el contexto de su descripción hay un par de preocupaciones. Serán atados a CSRF más tarde. En primer lugar, el área de su miembro debe estar encriptada. Por ejemplo, enlace tiene información pública y está bien no estar cifrado. enlace * sería donde solo los usuarios autenticados puedan acceder a sus perfiles y hacer cualquier otra cosa que requiera un usuario autenticado. Cualquier persona que navegue a enlace * sin una sesión válida, será redirigido a la página de inicio de sesión. Allí introducirían su nombre de usuario y contraseña. Al autenticar el nombre de usuario y la contraseña, se establecerá una sesión SSL / TLS (idealmente TLS). El sessionID se almacenaría en una cookie con los indicadores HTTP y Secure establecidos. Esto garantiza la protección de cada sesión de usuario y, lo que es más importante, coloca el formulario de actualización de perfil detrás de una capa de cifrado.

Ese cifrado agrega una capa de protección para el formulario. Incluso si el formulario es vulnerable a CSRF, el servidor puede configurarse para permitir solo formularios de usuarios con una sesión válida, lo que requiere un usuario autenticado. O otro ataque para obtener una sesión válida, de cualquier manera es más trabajo explotar la vulnerabilidad CSRF. Hay un par de maneras diferentes de implementar Protecciones CSRF . Sin embargo, la versión rápida es que funciona como una sola vez, por solicitud. Cuando un usuario envía el formulario, el cliente calcula el teclado de una sola vez y lo agrega a la solicitud. El servidor verifica la sesión, luego el teclado de una sola vez antes de aceptar la solicitud.