Ahora que sabemos cómo descubrir y explotar Sí nuestras vulnerabilidades.
Hablemos sobre cómo proteger los sitios web de ellos.
Entonces, si volvemos ahora a GVW 8 y decimos que la seguridad es demasiado alta, verá que tienen una forma muy simple de protegerse contra
ella, pero de esta manera realmente funciona.
Y lo que hacen es que te piden la contraseña actual.
Entonces, incluso si obtenemos este formulario y hacemos toda la falsificación y todas las cosas que estábamos haciendo y
luego se lo enviamos a la persona objetivo, en realidad no podemos ocultarlo y enviarlo automáticamente porque
no conocemos el actual contraseña.
Por lo tanto, solicita la contraseña actual y luego le permite agregar una nueva contraseña.
Así que esta es una muy buena solución para este caso.
Aunque porque qué pasa si el formulario en realidad no cambia su contraseña.
¿Qué pasa si solo vamos a enviar mensajes pretendiendo ser esa persona?
¿Qué pasa si vamos a publicar cosas en el muro de esa persona?
¿Qué pasa si vamos a publicar cosas en el blog de esa persona?
Entonces, como Aref puede ser explotado para hacer muchas cosas.
Como dije en videos anteriores y este método solo protegerá contra el cambio de contraseña.
Realmente no puede pedirle a la persona su contraseña cada vez que quiera publicar algo o hacer
algo con su perfil.
Ahora, las versiones más nuevas de DVD cuando lo necesites no vienen conmigo. Prueba el protocolo para tener una
opción más segura que implemente el método del que te hablaré.
Ahora en realidad se llama imposible en lugar de alto, pero no importa que no sea explotable de todos
modos, por lo que realmente no necesitamos tenerlo instalado.
Entonces, hablemos sobre cómo podría evitar que estas vulnerabilidades sucedan sin pedirle al usuario que
vuelva a ingresar la información o que vuelva a ingresar la contraseña.
Si lo piensa de la manera en que pudimos explotar esto, pudimos copiar el formulario que usa el
sitio web y enviarlo a la persona objetivo y hacer que esa persona lo ejecute o se ejecute automáticamente en la computadora
de la persona objetivo.
Entonces, una vez que la solicitud se envía al servidor o el servidor no estaba haciendo ningún tipo
de validación para garantizar que el usuario realmente quiera cambiar su contraseña.
Entonces, la mejor manera de prevenir s r f es asegurarse de que el usuario envíe datos a través de
una página que le fue entregada por la aplicación web y no por nadie más.
Una buena forma de implementar eso es usar tokens de sincronización.
Ahora sé que el nombre suena complicado, pero la idea es muy simple.
Básicamente queremos generar un token único y aleatorio en el lado del servidor.
Luego, cuando se carga la página cuando se carga el formulario Vamos a incrustar este token ya
generado en esa página como un formulario oculto.
Luego, cuando se envíe el formulario, nos aseguraremos de que se haya enviado con el token
que le enviamos a ese usuario específico.
Básicamente, le damos al usuario un token y luego esperamos a que envíe el formulario con el token que
le dimos.
De esa manera, la ficha que obtiene el hacker solo funcionará para él.
Entonces, incluso si genera una página y la envía al objetivo y el objetivo arroja la
página, el formulario se enviará pero el servidor lo rechazará porque no le dio ese token a ese
usuario, le dio ese token al pirata informático. por ejemplo, tenemos a este usuario aquí y aquí le cuesta a
Facebook la contraseña punto com BHB.
Va al servidor.
El servidor va a generar una respuesta para esa solicitud.
Por lo tanto, devolverá la página de correo electrónico que representa las contraseñas ph be en esa página.
Va a incluir una ficha única.
Entonces, cuando la página se carga en el lado del cliente, ya tendrá el formulario que
el usuario está buscando más un token único generado por el servidor.
Luego, cuando el usuario envíe lo que quiera enviar, el servidor solo aceptará el formulario y responderá
o responderá a lo que el usuario solicite.
Si el usuario devuelve el mismo token.
Ahora, si esto no se implementa correctamente, aún puede ser explotado.
Entonces, si el token era predecible o si se estaba usando el mismo token, entonces el pirata informático puede descubrir
qué token está incrustado en el código HDMI y enviárselo al usuario.
Por lo tanto, el token debe tener ciertas características para que sea seguro.
Básicamente, lo principal es que debes tener en cuenta que el token debe ser impredecible
y no se puede usar independientemente de la forma en que lo implementes.
Estas son las dos cosas principales que debes tener en cuenta porque si era predecible,
el hacker podrá crear sus propios tokens y luego incrustarlos en el código y ejecutar el ataque.
Se puede usar el mismo token.
Luego, los piratas informáticos pueden usar su ficha o la ficha de otra persona para apuntar a su objetivo.
Entonces, para que el token sea impredecible y para que pueda usarse, entonces el token debe tener
un gran valor para que el pirata informático no pueda hacer un ataque de fuerza bruta y descubrir qué es el token
que debe ser aleatorio para que el hacker no pueda crear sus propios tokens y debe ser único para
cada usuario porque si los usuarios obtienen el mismo token o tokens similares, entonces pueden pasarlos y luego
el token que funciona para el hacker funcionará para otra gente.
Entonces eso definirá todo el punto.
También puede aumentar la seguridad del token mediante la inclusión en otros factores y el algoritmo de generación
de tokens.
Por lo tanto, puede incluir, por ejemplo, la fecha y la hora.
Luego combínelo con un generador aleatorio seguro y luego encripte eso.
Obviamente, todo esto está sucediendo en el lado del servidor.
Por lo tanto, el hacker no podrá saber qué algoritmo está utilizando porque el código se ejecutará en
el lado del servidor.
No necesariamente tiene que hacer esto usando un número aleatorio grande y único seguro es suficiente.
Pero si desea aumentar la seguridad, puede agregar otros factores y cifrar el token antes de
enviarlo al usuario.
Esto se implementa realmente en el día de Matile.
Así que déjame mostrártelo en acción.
Así que voy a ir al día de Matile aquí.
Voy a ir a una avispa y luego sí o como complemento al blog.
Por lo tanto, esto le permite agregar una publicación de blog para que no le permita cambiar su contraseña ni nada
que realmente permita que personas anónimas también ingresen a nuestras publicaciones de blog.
Así que no puedes pedirle a la gente una contraseña.
De hecho, voy a alternar la seguridad para que sea la más alta porque está en cero en este momento.
Entonces ahora es el más seguro.
Y si hace clic derecho en este y continúa, inspeccione el elemento.
Ahora voy a desplazarme hacia arriba y, como pueden ver, tenemos el foro aquí y tenemos una entrada oculta con un
valor muy largo.
Y esta es la ficha.
Entonces, esto ya ha sido generado por el servidor y el servidor rechazará cualquier solicitud que
le enviemos a menos que tenga este token específico.
Y si uso este formulario y se lo envío a otra persona.
Por otra parte, las solicitudes que enviarán serán rechazadas porque obtendrán un token diferente, este token
se generó para mí y solo para mí.
Déjame mostrarte que si realmente actualizo ahora voy a obtener un token diferente.
Y nuevamente, si actualizo nuevamente, obtendré un token diferente si modifico esto.
Entonces, digamos que en lugar de la capital I al final voy a poner un pequeño I si presento esto
ahora me está dando un error.
Pero no me permitas cambiar esto, así que nuevamente obtuve un token diferente ahora y si solo lo envié de la
manera en que va a funcionar, ahora tenemos una entrada de blog llamada prueba.
Eso es todo.
En realidad es muy muy simple.
No quería entrar en demasiados detalles sobre cómo crear un token aleatorio y todo eso porque
eso dependerá específicamente del lenguaje de programación.
Esa es la aplicación web programada.
Pero yo solo quería mostrarle el concepto o la idea de cómo proteger las aplicaciones web contra
este tipo de vulnerabilidad.
La idea es que desea asegurarse de que el usuario envíe sus datos a través de una página que le sirva
y no por una página que le haya sido entregada por otra persona.
Entonces, para hacer eso, generamos un token en el lado del servidor, este token debe ser aleatorio y
único, enviar ese token con la página con el formulario e incrustado como un formulario oculto.
Y luego, cada vez que un usuario envíe la respuesta, asegúrese de enviar el mismo token que se
le dio.