elhacker.net cabecera Bienvenido(a), Visitante. Por favor Ingresar o Registrarse
¿Perdiste tu email de activación?.

 

 


Tema destacado: Los 10 CVE más críticos (peligrosos) de 2020


+  Foro de elhacker.net
|-+  Programación
| |-+  Desarrollo Web (Moderador: #!drvy)
| | |-+  [Aporte] Validacion de token de forma Criptografica, evitar ataques CSRF
0 Usuarios y 1 Visitante están viendo este tema.
Páginas: [1] Ir Abajo Respuesta Imprimir
Autor Tema: [Aporte] Validacion de token de forma Criptografica, evitar ataques CSRF  (Leído 1,179 veces)
AlbertoBSD
Programador y
Moderador Global
***
Desconectado Desconectado

Mensajes: 3.605


🏴 Libertad!!!!!


Ver Perfil WWW
[Aporte] Validacion de token de forma Criptografica, evitar ataques CSRF
« en: 13 Diciembre 2019, 19:32 pm »

Entrada tambien en mi blog:
Validacion de token de forma Criptografica, evitar ataques CSRF


Bueno esto viene del tema que abrio el usuario MiguelCanellas    
[Aporte]: Sistema Anti ataques CSRF (Espero sugerencias)
.

La forma mas sencilla de genera un token sin incluir nada de criptografia  y que se envie al usuario para posteriormente ser validado es la siguiente:

Código
  1. $token = hash("sha256",random_bytes(32));

Esto nos produce una cadena hash sha256 apartir de 1Kilobyte de datos random.

La cosa seria sencilla guardarlo en la $_SESSION en el server y mandarlo al usuario, si lo devuelve comparamos que sean iguales y listo no hay mucho pierde.

Se necesita mas seguridad.... ?

El simple hecho que tengamos una cadena hash sha256 apartir de 1Kilobyte de datos random. hace casi imposible que alguien pueda generar el token por si solo y que coincida con el que generamos nosotros, podriamos incrementar la cantidad de bytes generados por la funcion openssl_random_pseudo_bytes simplemente incrementando su valor.

Ahora si realmente queremos proteger la informacion mediante criptografia tenemos que hacer las cosas bien.

Una implentacion rapida para ejemplificar este proceso es la siguiente:

Código
  1. <?php
  2. $cipher = 'AES-256-CBC'; //SUIT de cirado utilizada
  3. $strkey = "s3cr3tk3yh4x0r"; //Clave en el servidor, secreta, cambiar esta clave de ejemplo POR FAVOR de preferencia utilizar una clave generada de forma segura con openssl_random_pseudo_bytes o /dev/random
  4. $realkey = hash("sha256",$strkey,true); //Hash de la clave en formato Raw
  5. $ivlen = openssl_cipher_iv_length($cipher); // Obtenemos el tamaño del Vector Inicializado de acuardo a la Suit de cifrado que estemos utilizando
  6. $iv = openssl_random_pseudo_bytes($ivlen); // Obtenemos $ivlen bytes random no nos interesa saber su valor
  7. $token = hash("sha256",random_bytes(32)); //Token sin cifrar este valor nuca lo ve el UserAgent
  8. $token_cifrado = openssl_encrypt($token,$cipher,$realkey,OPENSSL_RAW_DATA,$iv);
  9. $salida = base64_encode($token_cifrado); //Este valor si lo ve el User Agent
  10. echo "token: ".$token."\n";
  11. echo "token cifrado, salida raw: ".$token_cifrado ."\n";
  12. echo "token cifrado, salida base64: ".$salida."\n";
  13. $entrada = base64_decode($salida);
  14. $token_decifrado = openssl_decrypt($entrada,$cipher,$realkey,OPENSSL_RAW_DATA,$iv);
  15. echo "token decifrado: ".$token_decifrado ."\n";
  16. if($token_decifrado == $token) {
  17. echo "token correcto\n";
  18. }
  19. else {
  20. echo "token Incorrecto\n";
  21. }
  22. ?>

Si vemos el codigo anterior el "token" que enviaremos al usuario es la salida en base64 del token previamente cifrado.

Acontinuacion una posible salida de las casi infinitas salidas....
Código:
token: 5ab8aac170554a2683e0cc0534a34e80d0f16031a13faa3c3a5ee44902b2c6a1
token cifrado, salida raw: CU?!,F8C4d 1su
        SN{|큮vDjUa=qQKKKȀE#(@/I
token cifrado, salida base64: AUO6plUB9j8h+IvsyixGOAfZQzRkCzG84XN1vN7X2Aq2CVNOont87YGudsJEq2q1VWE9vZhxqJWfUUviv0tL9ciA+kWTI74oGEAvl4sSSak=
token decifrado: 5ab8aac170554a2683e0cc0534a34e80d0f16031a13faa3c3a5ee44902b2c6a1
token correcto

La idea en este caso es enviar la informacion cifrada al usurio y cuando este la envie devuelta se descifra y se compara con la almacenada previamente en la $_SESSION del usuario.
Cosas que se pueden mejorar el valor de nuestra Key inicial podria ser un archivo random en nuestro servidor generado previamente, podriamos tener una llave distinta por usuario, etc etc etc...


« Última modificación: 14 Diciembre 2019, 03:13 am por AlbertoBSD » En línea

Donaciones
1Coffee1jV4gB5gaXfHgSHDz9xx9QSECVW
@XSStringManolo
<svg/onload=alert()>
Colaborador
***
Desconectado Desconectado

Mensajes: 2.279


Turn off the red ligth


Ver Perfil WWW
Re: [Aporte] Validacion de token de forma Criptografica, evitar ataques CSRF
« Respuesta #1 en: 13 Diciembre 2019, 23:07 pm »

Cuando empezó a comentar del tema hice yo un post enorme con toda la implementación hecha a mano, un csprng, un cifrado simétrico... Era muy largo y dije, paso de subir este tostón.


En línea

MinusFour
Moderador Global
***
Conectado Conectado

Mensajes: 5.165


I'm fourth.


Ver Perfil WWW
Re: [Aporte] Validacion de token de forma Criptografica, evitar ataques CSRF
« Respuesta #2 en: 13 Diciembre 2019, 23:19 pm »

Una semilla de 8192 bits...



Creo que incluso si la usas con /dev/urandom no tienes suficiente entropia para generar un solo token.

Yo creo que 128-256 bits es más que suficiente. No es necesario pasarlo por ninguna función de cifrado (en especial si útilizas random_bytes u openssl_random_pseudo_bytes). Técnicamente, estás abierto a un ataque de sincronización (que a estás alturas es más teórico que práctico) por usar == para comparar strings que hash_equals.
En línea

AlbertoBSD
Programador y
Moderador Global
***
Desconectado Desconectado

Mensajes: 3.605


🏴 Libertad!!!!!


Ver Perfil WWW
Re: [Aporte] Validacion de token de forma Criptografica, evitar ataques CSRF
« Respuesta #3 en: 13 Diciembre 2019, 23:51 pm »

Era muy largo y dije, paso de subir este tostón.

Por que no, siempre se puede aprender algo nuevo con los aportes de  las demas personas

Una semilla de 8192 bits...



Si se que es mucho, voy a editar el post para no drenar la entropia de aquellos con servidores compartidos y demas, me hizo mucha graciosa la imagen  :laugh: :laugh: :laugh:

Si bastaria solo con unos 32 o 16 Bytes.

Sobre la cantidad disponible de entropia no tengo ningun problema, la maquina donde estoy haciendo las pruebas tiene hardware RNG y la cantidad de entropia disponible siempre retorna mas de 3000

Código:
cat /proc/sys/kernel/random/entropy_avail

En línea

Donaciones
1Coffee1jV4gB5gaXfHgSHDz9xx9QSECVW
@XSStringManolo
<svg/onload=alert()>
Colaborador
***
Desconectado Desconectado

Mensajes: 2.279


Turn off the red ligth


Ver Perfil WWW
Re: [Aporte] Validacion de token de forma Criptografica, evitar ataques CSRF
« Respuesta #4 en: 14 Diciembre 2019, 00:26 am »

Es mejor usar simétrica para este tipo de tareas no hay nada mejor. Y a parte es super ligera.
En línea

MinusFour
Moderador Global
***
Conectado Conectado

Mensajes: 5.165


I'm fourth.


Ver Perfil WWW
Re: [Aporte] Validacion de token de forma Criptografica, evitar ataques CSRF
« Respuesta #5 en: 14 Diciembre 2019, 00:29 am »

Sobre la cantidad disponible de entropia no tengo ningun problema, la maquina donde estoy haciendo las pruebas tiene hardware RNG y la cantidad de entropia disponible siempre retorna mas de 3000

Código:
cat /proc/sys/kernel/random/entropy_avail



Asegurate que la función este usando un fuente cristalográfica fuerte. Para eso es el segundo argumento de la función. Realmente nunca me he tomado la molestia para revisar cuanto entropia tengo en los servidores que me ha tocado manejar pero al generar llaves para GPG (que son menos de 8192 bits) si me ha pedido esperar a que se genere suficiente entropia. Y el limite es realmente 4096 bits según la documentación... Así que no estoy completamente seguro como lo hace /dev/urandom (si es que acaso necesita esos bits exactamente para entropia o si genera en base a una entropia menor).

random_bytes es una mejor opción si se tiene acceso a la función, al menos te quitas la posibilidad de usar una fuente no suficientemente "fuerte".
En línea

AlbertoBSD
Programador y
Moderador Global
***
Desconectado Desconectado

Mensajes: 3.605


🏴 Libertad!!!!!


Ver Perfil WWW
Re: [Aporte] Validacion de token de forma Criptografica, evitar ataques CSRF
« Respuesta #6 en: 14 Diciembre 2019, 01:06 am »

Es mejor usar simétrica para este tipo de tareas no hay nada mejor. Y a parte es super ligera.

Si es mas rapida la simetrica y pues es la que ejemplifico en el codigo.

Asegurate que la función este usando un fuente cristalográfica fuerte. ... Así que no estoy completamente seguro como lo hace /dev/urandom (si es que acaso necesita esos bits exactamente para entropia o si genera en base a una entropia menor).

random_bytes es una mejor opción si se tiene acceso a la función, al menos te quitas la posibilidad de usar una fuente no suficientemente "fuerte".

Segun la documentacion de random_bytes

Código:
On Linux, the » getrandom(2) syscall will be used if available.
On other platforms, /dev/urandom will be used.

Si vemos en getrandom(2)
http://man7.org/linux/man-pages/man2/getrandom.2.html

Código:
By default, getrandom() draws entropy from the urandom source (i.e., the same source as the /dev/urandom device).  This behavior can be changed via the flags argument.

El unico parametro de random_bytes  es la cantidad de bytes y segun su documentacion

Código:
Return Values:
Returns a string containing the requested number of cryptographically secure random bytes.

En cambio openssl_random_pseudo_bytes

Si se puede espeficiar el flag de crypto_strong

Código:
If passed into the function, this will hold a boolean value that determines if the algorithm used was "cryptographically strong", e.g., safe for usage with GPG, passwords, etc. TRUE if it did, otherwise FALSE

En general para el ejemplo que postee es igual si el source es random o urandom. Ya si nos ponemos paranoicos podrias leer bytes directamente de /dev/random

En sistemas como FreeBSD a partir de su version 11 /dev/random y /dev/urandom son exactamente el mismo device y nunca se queda sin entropia.

En sistemas como Linux no me he puesto a ver el codigo del kernel, solo me he fijado si openssl tiene forma de utilizar por defecto el RNG que tiene el hardware de intel lo cual si esta activado por defecto y si esta:

Código:
openssl engine

Salida:

Código:
(rdrand) Intel RDRAND engine
(dynamic) Dynamic engine loading support

Y que tambien el Kernel lo tenga habilitado:

Código:
less /proc/cpuinfo

Citar
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm cpuid_fault epb invpcid_single pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid xsaveopt dtherm ida arat pln pts md_clear flush_l1d

Para el ejemplo didactico cualquiera de las 2 funciones que se use esta bien, openssl_random_pseudo_bytes o random_bytes. Ya si nos ponemos paranoicos es otra cosa.

Saludos!
« Última modificación: 14 Diciembre 2019, 01:13 am por AlbertoBSD » En línea

Donaciones
1Coffee1jV4gB5gaXfHgSHDz9xx9QSECVW
MinusFour
Moderador Global
***
Conectado Conectado

Mensajes: 5.165


I'm fourth.


Ver Perfil WWW
Re: [Aporte] Validacion de token de forma Criptografica, evitar ataques CSRF
« Respuesta #7 en: 14 Diciembre 2019, 02:24 am »

En cambio openssl_random_pseudo_bytes

Si se puede espeficiar el flag de crypto_strong

Código:
If passed into the function, this will hold a boolean value that determines if the algorithm used was "cryptographically strong", e.g., safe for usage with GPG, passwords, etc. TRUE if it did, otherwise FALSE

No lo digo exactamente por eso, en un pasado ya ha tenido bugs esa función:

https://bugs.php.net/bug.php?id=70014

El segundo parámetro no es exactamente un parámetro para forzar el uso de una fuente criptográfica segura sino para revisar si el resultado fue así. No dudo que no sea una función valida hoy en día, después de que se parcho correctamente... pero si hay sistemas que pueden acabar usando la forma insegura preferiría que se usara la otra función.
En línea

AlbertoBSD
Programador y
Moderador Global
***
Desconectado Desconectado

Mensajes: 3.605


🏴 Libertad!!!!!


Ver Perfil WWW
Re: [Aporte] Validacion de token de forma Criptografica, evitar ataques CSRF
« Respuesta #8 en: 14 Diciembre 2019, 03:05 am »

No lo digo exactamente por eso, en un pasado ya ha tenido bugs esa función:

https://bugs.php.net/bug.php?id=70014

El segundo parámetro no es exactamente un parámetro para forzar el uso de una fuente criptográfica segura sino para revisar si el resultado fue así. No dudo que no sea una función valida hoy en día, después de que se parcho correctamente... pero si hay sistemas que pueden acabar usando la forma insegura preferiría que se usara la otra función.

Tienes toda la razon hace unas cuantas versiones del PHP tenia bugs la funcion de openssl... pero ahora ya en las mas recientes no tiene, y efectivamente random_bytes tiene mejor source de random segun disponga el sistema operativo.  ;-) ;-) ;-)

Voy a actualizar el codigo de ejemplo.

Saludos!
En línea

Donaciones
1Coffee1jV4gB5gaXfHgSHDz9xx9QSECVW
Páginas: [1] Ir Arriba Respuesta Imprimir 

Ir a:  

Mensajes similares
Asunto Iniciado por Respuestas Vistas Último mensaje
token contra CSRF
Nivel Web
nØFi# 5 6,200 Último mensaje 13 Noviembre 2009, 10:28 am
por deibix
csrf token
Hacking
fokin 2 1,839 Último mensaje 21 Noviembre 2013, 17:27 pm
por fokin
El token de acceso de Facebook es vulnerable a ataques MITM « 1 2 »
Noticias
wolfbcn 12 4,133 Último mensaje 12 Marzo 2014, 23:29 pm
por Kami
[Pregunta]: Token CSRF
Desarrollo Web
Leguim 4 897 Último mensaje 4 Diciembre 2019, 05:17 am
por @XSStringManolo
[Aporte]: Sistema Anti ataques CSRF
Desarrollo Web
Leguim 4 1,048 Último mensaje 23 Diciembre 2019, 03:26 am
por AlbertoBSD
WAP2 - Aviso Legal - Powered by SMF 1.1.21 | SMF © 2006-2008, Simple Machines