26 de noviembre de 2010

El entrenamiento en seguridad web y lo que puede hacer por su empresa.

Para los negocios en línea, la seguridad es una parte vital en lo referente a la eficiencia y retorno de inversión de los mismos. Las aplicaciones web son las herramientas principales para las transacciones en línea, promoción de productos y servicios además de ser también las principales en presentar inconvenientes de seguridad que pudieran perjudicar a usted y a sus clientes a través de su aplicación. La capacitación de personal en el área de seguridad de aplicaciones web es definitivamente un valioso activo para las empresas. Proporcionar conocimientos básicos esenciales y la comprensión de las cuestiones de seguridad relacionadas, así como la capacitación práctica necesaria a su personal es actualmente imperativo. Este tipo de capacitación también ayuda al personal a entender y reconocer las posibles fallas de seguridad en sus negocios en tiempo real y por ende a evitar perjucios derivados.

¡Hacer las cosas bien antes desde el principio significa ahorrar dinero! 

La magnitud del riesgo actual es sin exageraciones demasiado alta para obviarla. Según fuentes de la industria, las aplicaciones web representan el 80% de las vulnerabilidades en línea. Su aplicación en línea puede tener cientos de vulnerabilidades latentes y por tanto una evaluación de riesgos al momento de la instalación de la misma es vital para el futuro de sus negocios en línea.

Aquí es donde la seguridad siempre es más eficaz, en la prevención de problemas antes de que sucedan. Pruebas exhaustivas y la comprobación de cada parte de su sistema para detectar las posibles deficiencias es parte primordial de una política preventiva. Los ahorros de costos pueden ser enormes. Infracciones o malas prácticas de seguridad pueden resultar en ataques tanto a las empresas en línea como a sus clientes, incurriendo en pérdidas financieras a veces muy graves. Y para añadir a los gastos, lo que usted no haya resuelto antes deberá resolverlo después, por tanto una política de prevención en el 80% de los casos significa un ahorro sin discusión.

Los problemas de seguridad en sus aplicaciones web son totalmente evitables. La mejor práctica es la prueba rigurosa y sistemática de todas las aplicaciones web antes de salir a la luz o entrer en línea de forma definitiva.

Piense en su aplicación web como en un buen submarino recién terminado: ¿Usted lo sumergiría a 5000 metros de profundidad sin haber hecho anteriormente una serie de pruebas de capacidad? Francamente no lo creo.

Tipos de entrenamiento necesarios:
La seguridad de aplicaciones web puede ser mucho más compleja de lo que parece por tanto existen varios tipos de entrenamiento dependiendo de las áreas en las que se desenvuelva el personal:
  • Entrenamiento Básico:
    Es necesario para cualquier personal a cargo de las áreas de negocios en línea conocer los riesgos a los que están expuestos así como ciertos principios fundamentales en cuanto a seguridad de las aplicaciones en línea con las que tienen relación y con las que desempeñan su trabajo cotidiano. La idea es formar una cultura de seguridad en línea sólida que forme parte a su vez de la cultura empresarial.
  • Entrenamiento Medio:
    Este es el que se brinda específicamente a las personas involucradas en las tomas de decisiones y que inciden en el tipo de aproximación al cliente y por tanto en el formato de las áreas de las aplicaciones en línea. Es importante que este personal esté al tanto de todos tipos de ataques que existen y cómo sus decisiones pudieran influir en que de una u otra forma estos tipos de ataque pudieran ser efectuados. Este entrenamiento debe convertirlos en conocedores de las posibles vulnerabilidades y las consecuencias que estas pudieran tener aunque no sean los encargados de corregirlas.
  • Entrenamiento Avanzado:
    Definitivamente, es a la hora de producir código y diseñar los procesos de la aplicación cuando se comete la gran parte de los errores que dejan abiertas las puertas a futuras complicaciones. En este tipo de entrenamiento, que es el más largo y especializado el programador o desarrollador deberá reconocer las fallas a nivel de código, pero por supuesto además deberá entender cómo evitarlas. Este entrenamiento tiene dos fases: La primera se encarga de enseñar a detectar, evaluar y evitar las fallas en forma genérica, y la segunda se basa en aquellas fallas específicas que dependen de la plataforma en la cual han sido desarrolladas o se desarrollarán la aplicación o aplicaciones.
Es importante aclarar que todo el aprendizaje debe estar basado en estándares OWASP y WASC, para que de esta forma se le haga entrega al personal de las herramientas necesarias para a su vez transmitir a otros los conocimientos adquiridos y potenciar los conocimientos en seguridad web como parte del capital de conocimientos empresarial.

Hasta la próxima...

25 de noviembre de 2010

La importancia de reducir la superficie de ataque.

Los atacantes logran penetrar una aplicación web por los más insospechados lugares. A veces inclusive el ataque es llevado a cabo por vectores que están relacionados pero que nada tienen que ver directamente con la aplicación web. Es común oír hablar de sitios vulnerados a través de servicios como FTP o SMTP e inclusive POP3, NNTP y muchos otros, pero: ¿Cuál es la razón por la cual este tipo de ataques son frecuentes? Lo que sucede es que la superficie de ataque de dichas aplicaciones es a veces demasiado extensa.


Para entender el concepto de "superficie de ataque" solo necesitamos imaginarnos a un bombardero de la segunda guerra mundial B25 (el atacante) tratando de visualizar la posición del objetivo a ser bombardeado. En esa época no existían radares sofisticados, ni posicionamiento por GPS, por lo cual la visibilidad del objetivo era uno de los principales factores que influían en que este pudiera ser alcanzado de forma más o menos eficiente.

Un objetivo más visible, necesitaba una protección antiaérea mejor y hasta se recurría en algunas ocasiones al camuflaje. También hay que recordar que del lado de atacante existían y existen los conocidos espías, que podían desde el campo de batalla, enviar información precisa acerca de la superficie, forma e importancia del objetivo. También un objetivo a veces bien camuflado, podía ser identificado por instalaciones adyacentes al mismo que no concordaban con el camuflaje. Por ejemplo un aeropuerto y sus aviones podían ser camuflados, pero si se existían grandes depósitos de combustible, muchos "graneros"con forma de angar, o demasiada actividad de personal, se podía comprometer el camuflaje y dejar al descubierto la operación.

Regresando a nuestro campo de batalla real, la web, y analizando el símil con el ejemplo anterior es indudable que mientras más rutinas, páginas dinámicas y especialmente formularios tenga una aplicación, mayor será su superficie de ataque. La cantidad de los anteriores es lo que determina su tamaño y llamaremos "superficie neta o necesaria".

Podemos después de lo anterior deducir que la posibilidad de un ataque es directamente proporcional a la superficie de ataque total de la aplicación.

Sin embargo, los servicios adicionales que utiliza el programador o que han quedado instalados por defecto, comprometen también la seguridad de nuestra aplicación web, tal como lo hacían la actividad del personal y los depósitos de combustible en el caso de nuestro ejemplo. Estos generan una superficie de ataque adicional, superflua o innecesaria que aumenta el riesgo de ataques.

Uno de los casos más comunes de este tipo de servicios instalados en los servidores y que a veces están completamente a disposición del atacante proviene de la instalación por defecto de paquetes de servicios pre-configurados, como por ejemplo XAMPP, algunas versiones de WAMP o LAMP  entre otros. Este enlace les llevará a una tabla de comparación de los más conocidos. También proviene de instalaciones de paquetes de código abierto mal configurados como manejadores de contenido CMS y otras utilidades.

El programador o el administrador del servidor, instalan dichos paquetes pre-configurados sin entender o percatarse de que la configuración por defecto es básica y hasta se pudiera decir que algo inocente. No hace falta decir por ejemplo, que no tiene mucho sentido proteger el servicio de MySQL si se deja el acceso al PhpMyAdmin completamente libre. Y esta es solo una de las configuraciones por defecto en las que no se repara a la hora de instalar el software pre-configurado.

Hay veces en que un simple escaneo de puertos permite verificar que tipo de software pre-configurado se ha instalado en un servidor web, ya que desde afuera de la red local se puede acceder a puertos como 21, 25, 110, 443, 119 y otros todos instalados en el mismo servidor, y así entablar conversaciones Telnet o de otro tipo con los servicios activos en dichos puertos. Si el atacante logra vulnerar uno solo de estos servicios inocentemente configurados desde el punto de vista de la seguridad, tendrá el camino prácticamente abierto hacia nuestra aplicación, o también podrá simplemente utilizar los servicios para sus fines, como enviar SPAM por el SMTP server, ubicar un sitio de phishing en nuestro servidor o simplemente colocar grandes cantidades de software ilegal para distribuirlo desde nuestro servidor FTP.

¿Y los espías? Cuando me refería a los espías quise hacer una comparación a lo que comúnmente se conoce como "Google Hacking Database". No hay mejor conocedor de nuestra aplicación web que Google. Los atacantes lo saben y hacen que trabaje para ellos mediante una serie de técnicas y consultas que han desarrollado y que permiten buscar sitios con determinadas vulnerabilidades conocidas en base a su tipo de servidor y servicio. Es realmente impresionante la cantidad de sitios vulnerables que puede mostrase mediante el uso del GHDB. El equipo de Google trabaja permanentemente en la caza de este tipo de consultas para reducir los posibles perjuicios, pero ellos mismos son víctimas del enorme potencial de la herramienta y no puede controlar su potencia por lo que permanentemente se descubren nuevos trucos.

Es claro que luego de leer este artículo Usted deberá tener un concepto algo más claro de lo que se conoce como "superficie de ataque" y posiblemente se le hayan ocurrido algunas ideas para reducirla. En otros artículos hablaremos de las técnicas de reducción y camuflaje de dicha superficie.

Hasta la próxima...

23 de noviembre de 2010

La importancia de manejar los archivos de registro de sucesos HTTP

Una de las informaciones menos apreciadas de las que el desarrollador web tiene a la mano, son los archivos de registro de sucesos del servicio HTTP. Estos normalmente eran considerados la única fuente de información estadística a mano. En ellos los usuarios van dejando su huella cada vez que solicitan un recurso en nuestro servidor, bien sea Apache, IIS, WebSphere o cualquier otro.

La razón por la que han sido dejando algo de lado, es que si bien su información es valiosa, ya no son tan útiles para fines estadísticos debido al gran éxito de Google Analytics el cual permite hacer seguimiento de todos los movimientos de páginas en las que se haya agregado un pequeño "script" al final de las mismas, y para ser realmente honesto sus reportes y estadísticas son impresionantes.

Pero a nivel de seguridad Google Analytics nos sirve de poco o casi nada, ya que no lleva control más que de las páginas en las que se agrega el script y no así de los recursos como imágenes, archivos de flash y archivos de código Javascript. Además si la página en ejecución genera un error 500 de ejecución en el servidor y no se completa, tampoco será de utilidad ya que el servidor no habrá entregado la parte final de la página (desde el error en adelante) y el archivo de control de Google Analytics se encuentra siempre al final del código de la página. Tampoco detectará un escaneo de vulnerabilidades no autorizado, debido a que las maquinarias de escaneo no ejecutan los scripts de las páginas que escanean...

Sin embargo dejando esta maravillosa solución estadística para el equipo de mercadeo, por efectos de seguridad es necesario retomar el control de los archivos de sucesos del servidor HTTP. El mejor lugar para detectar un intento de escaneo de vulnerabilidades no autorizado es precisamente allí. Sin embargo, hallar la información en estos enormes archivos de texto, no es simple debido a que cada solicitud hecha al servidor HTTP generará una línea, y una página junto con sus diferentes componentes podría generar hasta 80 líneas diferentes por lo que si la página es solicitada 1000 veces, estaríamos hablando de 80.000 líneas o "hits". En un ataque de DoS (Denial of Service) comunmente podemos llegar a recibir esa cantidad de solicitudes por minuto, por lo que capturar las direcciones IP de los equipos atacantes puede ser un trabajo bastante duro.

Escarbar en un archivo de estas magnitudes sin una herramienta apropiada es difícil. Pero no hay que alarmarse, probablemente usted ya haya oido hablar de AWstats 6.95  en su última versión estable en el momento de escribir este artículo. AWstats es una solución Open Source, y por tanto la mayoría de los proveedores de alojamiento compartido la ofrecen en sus soluciones en sus paneles de control. Es 100% configurable al tipo de servidor HTTP que se esté manejando y permite obtener una serie de reportes muy importantes acerca de las peticiones recibidas.

Existen soluciones mucho más sofisticadas como Urchin 7.0. Esta solución es la matriz de código sobre la que se basa Google Analytics y al estar instalado en un servidor y analizar los archivos de registro de sucesos (a los que no puede acceder Analytics) podrá reportar muchos más detalles. En realidad es una herramienta impresionante, pero no es gratis.

Sin embargo, ni AWstats ni URCHIN 7 ni siquiera los archivos de registro HTTP pueden servirnos para rastrear los errores de ejecución en nuestra aplicación, ya que si bien los registros de sucesos HTTP pueden decirnos en qué página y que IP generó el error, no pueden darnos detalle del error en sí  y datos como el número de línea, descripción del error y otros detalles muy importantes para corregir el problema.

Para poder manejar este problema Apache tiene un registro independiente que se encuentra en /var/log/apache2/error_log (o error.log) en donde podremos detectar los errores que produce la aplicación sin necesidad de esperar a que algún usuario los reporte. En el caso de IIS también existe una solución, pero los errores 500 del servidor HTTP son considerados errores de sistema y es necesario recurrir al visor de sucesos (Herramientas Administrativas/Administración de Equipos/Visor de sucesos).

En IIS el manejo del error 500 depende de la capacidad de poder acceder a los archivos de registros de error, por lo que la mejor solución para evitar problemas especialmente en entornos de alojamiento compartido, es generar nuestra propia página de error 500, con la que primordialmente ocultaremos la información que no deseamos ofrecer al visitante, y la registraremos a gusto en un archivo de sucesos propio.

En este artículo muy interesante explica el tratamiento de los errores 500 de diferentes formas para aplicaciones en ASP.NET. Para aquellos que trabajen sobre Apache este otro artículo puede explicarles detalladamente el proceso de manejo de páginas de error personalizadas.

Por otro lado siempre es importante aclarar que el uso de páginas de error personalizadas es muy importante, inclusive para el manejo de otro tipo de errores. Por ejemplo: Los atacantes pueden obtener mucha información detectando errores 404 y 403, con la mezcla de los cuales y una buena dosis de ingenio acerca de los nombres comúnmente utilizados para nombrar directorios y páginas, logran obtener una visión bastante acertada del arbol de directorios de nuestra aplicación.

Hasta la próxima.

21 de noviembre de 2010

Cuando la "S" en HTTPS no es suficiente!

Un error común de los programadores es creer que el hecho de que se ofrezca un servicio SSL/TLS en un servidor web con un certificado válido es más que suficiente para garantizar que los datos no sean interceptados por los atacantes.

Si bien en teoría y en la realidad esto es cierto, el programador debe entender que los protocolos SSL/TLS protegen la comunicación entre el navegador y el servidor hasta cierto punto. Y es que no es el navegador el encargado de cifrar el contenido y establecer la comunicación cifrada con el servidor. Los protocolos SSL/TLS se encuentran entre la capa de aplicación (en donde se halla el HTTP, SMTP, FTP y otros protocolos) y la capa de transporte, justo encima del protocolo del protocolo de comunicación TCP.

Cuando usted indica al navegador que conecte con un servidor que usa SSL usted utiliza HTTPS, la última consonante (S) indica al navegador que conecte por HTTPS que en realidad es simple HTTP con la adición de el protocolo de seguridad SSL o TLS.

Por tanto, cualquier ataque que intercepte la comunicación a nivel de la capa de aplicación podrá extraer la información sin cifrar en texto plano. Lo anterior significa que cualquier BHO (Browser Helper Object) Plug-in de Firefox o Chrome, e incluso cualquier sniffer que intercepte la mensajería del navegador fuera de este hacia las librerías de comunicación del sistema operativo, está en posibilidad de obtener la información que en un principio creeríamos que estaría protegida por el protocolo de cifrado SSL/TLS.

Es muy simple de verificar. Si usted tiene Firefox instalado en su sistema solo necesita instalar un add-on llamado Httpfox que si bien es una aplicación muy buena, útil e interesante, además de inofensiva, le permitirá verificar lo que en estas líneas intento exponer.

Esta aplicación a parte de ser extremadamente útil para los webmasters y programadores web, le permite ver todo el flujo de datos que pasa a través del protocolo HTTP. En resumidas cuentas es lo que llamaríamos un "HTTP sniffer". Utilíce Httpfox para visualizar el flujo de un sitio web que se comunica por SSL/TSL (un sitio que conecte por HTTPS) y verifique como usted podrá perfectamente visualizar los contenidos introducidos en los formularios y hasta aquellos de los de los campos de tipo "password", mientra explora el contenido de las peticiones POST.

Es lógico entender a partir de este peueño experimento que si el Httpfox está en capacidad de mostrarle esta información de forma completamente transparente y legal, eso también significa que cualquier otro add-on creado con mala intención podría tomarla la misma y enviarla a los amigos de lo ajeno. ¿Interesante no?

En futuros artículos hblaremos acerca de como proteger al usuario de este tipo de amenazas, aunque ya he mencionado algo en un artículo posterior: Man in the Browser Attack

Hasta la próxima...
Mauro Maulini R.

19 de noviembre de 2010

Vulnerabilidad de desbordamiento de enteros y cómo prevenirla.

Anteriormente hemos mencionado la importancia de la desinfección de parámetros como herramienta fundamental en el combate de las vulnerabilidades de una aplicación web, sin embargo la mayoría de las veces estamos atribuyendo que el parámetro recibido puede contener una cadena de SQL injection o XSS, sin percatarnos que hay un tipo infección utilizada para vulnerar nuestro sitio que es diferente a las anteriores: Desbordamiento de enteros o "Integer Overflow"

En palabra simples, se trata de parámetros numéricos recibidos por manipulación del querystring que desbordan la capacidad de los contenedores que hemos preparados para ellos, o que aunque no la desborden son luego utilizados en operaciones aritméticas en donde pudieran exceder la capacidad del contenedor asignado al resultado.

Es simple: Usted siempre recibe del usuario cadenas de texto por los parámetros del querystring, y si no toma las precauciones necesarias antes de convertirlas a enteros, puede tener errores. La primordial precaución que por defecto tomamos los desarrolladores es la de verificar que dicha cadena en realidad represente un número entero, sin embargo somos pocos quienes verificamos que dicho número no exceda la capacidad para la cual fue creado:

Un ejemplo de la vulnerabilidad en asp clásico. Si usted recibe un parámetro por el URL de la siguiente forma:

checkHotel.asp?idHotel=34 

Usted no solo debe preocuparse de que la cadena que contiene el parámetro idHotel sea numérica y entera sino de que soporte un intento de desbordamiento como por ejemplo:

checkHotel.asp?idHotel=642366423426423466423464

Si usted esperaba que el parámetro no superara un entero simple, se llevará una sorpresa al tratar de llamar una función como "cInt" ya que al desbordarse la capacidad de un entero la función generará un error debido a que espera un parámetro que se pueda convertir a un entero simple de 16 bits.

Quizás esta es una de las razones para dejar de una vez por todas de programar en ASP clásico, debido a que VbScript no posee una serie de funciones que permitan verificar los parámetros numéricos de forma eficiente.

Este tipo de falla puede ser utilizada para generar DoS (Denial of Service) ya que si por ejemplo el error se genera luego de haber abierto conexiones a bases de datos o requerido recursos que debido al mismo error no son liberados a tiempo, el atacante podría llamar la rutina indefinidamente hasta dejar al servidor inutilizado por falta de recursos, o al menos inutilizar la aplicación web.

Visto lo visto, mejor mudarse a ASP.NET si aún no lo ha hecho, en donde los métodos de los tipos enteros TryParse son una solución muy eficiente para convertir parámetros sin tantos dolores de cabeza. Cada tipo de entero tiene su propio método TryParse, así por ejemplo int32.TryParse es el método necesario para convertir cadenas a números de 32 bits.

En otros lenguajes como y JSP/Java podemos usar el manejo de excepciones (que si es eficiente) para verificar la validez de las conversiones con el conocido try/catch.

    public static boolean validateNumber(String num) {
        try {
            Integer.parseInt(num);
            return true;
        catch (Exception e) {
            return false;
        }
    }


En PHP una de las soluciones posibles además del manejo de excepciones es usar la librería "GMP arbitrary lenght integers" para enteros de longitud arbitraria. Hay que agregar la extensión al archivo "php.ini" des-comentando la línea:
;extension=php_gmp.dll


Una vez iniciada la librería solo resta usar los enteros:
<?php
$a 
gmp_init(123456);

$b gmp_init("0xFFFFDEBACDFEDF7200");
$c gmp_init("7756466309883824442551");
?>

De esta forma podrá manejar enteros sin importar su longitud de una forma mucho más segura ya que esta librería presenta todas las funciones matemáticas necesarias.

Hasta la próxima...

18 de noviembre de 2010

¿Que son Los OTP? One Time Password Tokens

OTP es el acrónimo para One Time Password o dispositivos generadores de claves de acceso perecederas de un solo uso. La idea es simple, usted puede obtener una clave o "token" en tiempo real mediante un dispositivo independiente de la web o de su sistema de acceso, que está sincronizado con el sistema de validación y utiliza la misma semilla aleatoria que este: el tiempo.

Son dispositivos que se han hecho muy comunes y famosos en Europa y Estados Unidos, ya que en la banca en línea son utilizados para validar las transacciones electrónicas y han demostrado ser una solución muy eficiente para solventar el problema de usurpación de identidad, ya que si no se posee el OTP correcto la clave que se enviará no será válida.

Sin embargo a pesar de su eficiencia han demostrado tener algunos problemas:
  • Su costo no permite su masificación por lo que solo son utilizados en muchos casos por clientes VIP.
  • Son dispositivos de hardware y por tanto para ser sincronizados en caso de pérdida de sincronización es necesario recogerlos.
  • Son suceptibles de sufrir el denominado efecto Tamagoshi. Si usted o alguno de sus familiares ha tenido este tipo de mascota virtual, sabrá a qué nos referimos. Se trata de los problemas que suceden cuando se pierde o se olvida el dispositivo, se introduce en la lavadora o sucede algún otro accidente que haga que el mismo deje de funcionar.
  • G-OTP - One Time Password
    versión para PC
    Desarrollado por Mauro Maulini R.
  • Su margen de error está directamente relacionado con la eficiencia de sincronización de sus relojes con el del servidor principal.

Si bien han demostrado ser una solución muy efectiva, tecnológicamente aún están siguiendo un proceso evolutivo que permita que sean más exactos y más económicos.

Han surgido muchas variantes, los hay en forma de tarjeta de crédito, con teclado para agregar una clave de uso, con lectores de huellas digitales y por último hay soluciones de software que los emulan en forma de OTP virtual.

Son muchas las variantes pero quizás esta última sea a mi entender la más eficiente, ya que al tratarse de software que puede ser utilizado en nuestros teléfonos inteligentes o nuestras PCs, reduciendo sustancialmente su costo final. Claro está que en estos casos los procesos de "enlistado" o "enrollment" que son los que permiten asignar un determinado OTP a un usuario, deben ser manejados con mucho cuidado. A mi parecer ese problema está resuelto.

Personalmente no puedo ser imparcial ya que he desarrollado un OTP Virtual con bastante éxito, a mi parecer es muy interesante y además se comunica con el usuario en formato gráfico evitando transmitir número y letras. Su nombre es GOTP (Graphic OTP). En la actualidad estamos integrándolo a un sistema de validación de ingreso para diferentes tipos de control de acceso desde web hasta control de ingreso físico, y para ello también estamos elaborando las versiones correspondientes en iOS, Android y Windows Phone, además de la versión para PC bajo Windows que ya es conocida y popular.
Si desean má información  sobre esta solución pueden contactarme

Hasta la próxima...

15 de noviembre de 2010

Clasificación de Amenazas WASC 2.0

La Clasificación de Amenazas WASC es un esfuerzo de cooperación para aclarar y organizar las amenazas a la seguridad de sitios web. Los miembros del Web Application Security Consortium han creado este proyecto para desarrollar y promover estándares de la industria en lo referente a la terminología para describir estos temas. Los desarrolladores de aplicaciones, profesionales de la seguridad, proveedores de software, y auditores tendrán la posibilidad de acceder a un lenguaje común y coherente, así omo a las definiciones para los problemas de seguridad relacionados con la web.


Las amenazas  traducidas al castellano son las siguientes:
  1. Autenticación insuficiente
  2. Autorización insuficiente
  3. Desbordamientos de enteros.
  4. Insuficiente protección en la capa de transporte.
  5. Inclusión de archivos remotos.
  6. Formato de cadenas.
  7. Desbordamiento del búfer.
  8. Cross-Site Scripting.
  9. Cross-Site Request Forgery.
  10. Denegación de Servicio. DoS.
  11. Fuerza bruta.
  12. Spoofing de contenido.
  13. Fuga de información.
  14. Configuración errónea del servidor.
  15. Configuración errónea de la aplicación.
  16. Indexación incorrecta de directorios.
  17. Permisos indebidos al sistema de archivos.
  18. Predicción de credenciales y/o sesión.
  19. Inyección de SQL.
  20. Manejo inadecuado de entradas.
  21. Anti-automatización insuficiente.
  22. Manejo inadecuado de salidas.
  23. XML inyección.
  24. HTTP Request Splitting.
  25. HTTP Response Splitting.
  26. Contrabando de solicitud HTTP.
  27. Contrabando de respuesta HTTP.
  28. Inyección de Byte Nulo.
  29. Inyección LDAP.
  30. Inyección de comandos de mail.
  31. Ejecución de comandos de SO.
  32. Desvío de enrutamiento.
  33. Recorrido de rutas.
  34. Localización previsible de recursos.
  35. Abuso de Arreglos SOAP.
  36. Inyección SSI.
  37. Fijación de sesión.
  38. Abuso de redireccionamiento URL.
  39. Inyección XPath.
  40. Insuficiente validación de procesos.
  41. Sobrecarga de atributos XML.
  42. Abuso de funcionalidad.
  43. Entidades externas XML.
  44. Expansión de entidades XML.
  45. Fingerprinting.
  46. Inyección XQuery.
  47. Caducidad de sesión insuficiente.
  48. Indexación Insegura.
  49. Debilidad de recuperación de contraseña.
Para conocer más de cada una de ellas específicamente, puedes visitar directamente http://projects.webappsec.org/w/page/13246978/Threat-Classification

Hasta la próxima...

OWASP Code Crawler

¿Porqué tenemos que esperar a que se realice sobre nuestra aplicación web un test de penetración, un escaneo de vulnerabilidades o peor aún a que esta sea atacada por una vulnerabilidad no corregida a tiempo?

Lo primero es programar de forma segura, o por lo menos manteniendo una clara visión de las posibles fallas de seguridad que pudieran existir en nuestras aplicaciones. Y cómo ya hemos hablado del tema con anterioridad, así como hemos hablado de las guías de desarrollo OWASP, no voy a aburrirles con el tema.

Es cierto que en muchas ocasiones la revisión de vulnerabilidades en código ante los típicos "deadlines" improrrogables queda relegada a un último plano, sin embargo hoy vamos a hablar de una utilidad que puede ahorrarnos muchas horas en estos casos y por lo menos nos va a permitir ubicar las posibles fallas en nuestro código.


Estoy hablando del OWASP Code Crawler que es una herramienta de depuración de posibles vulnerabilidades en código fuente para código en .NET y J2EE/JAVA. Puedes descargarlo aquí.

Es una aplicación desarrollada en .Net 3.5, que se basa en una maquinaria muy afinada de control de Expresiones regulares, que nos permitirá encontrar errores tradicionales y nos permitirá utilizar herramientas como un calculador DREAD (calculador de riesgo de una condición o amenaza de seguridad).

Hasta la próxima...

10 de noviembre de 2010

¿Claves de acceso fáciles de recordar y muy fuertes? ¿Cómo lograrlo?

El problema que normalmente tienen todos los usuarios es que a medida que van haciendo caso a los consejos de seguridad acerca de como crear claves "seguras" sus claves de acceso se empiezan cada vez más a parecer a unos garabatos extraños que se usaban en los "comics" para simular que un personaje decía malas palabras.

Sin embargo hay detalles que casi nunca se le les explican por posible desconocimiento de los programadores que realizan la interfaz de acceso, y estos son los siguientes:

  • Una clave de acceso no necesariamente debe estar formada por una sola palabra.
  • El espacio en blanco es tan válido como cualquier otro caracter.
  • Los campos usados para el ingreso y creación de claves no debieran tener límites de caracteres.
  • Una frase es mucho más fácil de recordar y más difícil de reproducir.

Basados en lo anterior una clave como: "Mi 1ª clave es 99% más segura!" cumple con reglas muy importantes para la construcción de claves de acceso fuertes como las siguientes:

  • Su longitud es mayor que los eternos 8 caracteres mínimos.
  • Utiliza letras en mayúsculas y minúsculas combinadas.
  • Tiene caracteres especiales.
  • Utiliza caracteres numéricos.
  • Contiene espacios en blanco. 
Hay que aclarar que la frase que hemos propuesto es muy superior a las convencionales claves que cumplen con los anteriores requisitos en una sola palabra y un promedio de 8 a doce caracteres, ya que solo para empezar tiene 30 caracteres. Sin embargo a pesar de su longitud es mucho más fácil de recordar.

El problema de enseñar al usuario a construir claves como esta se basa en que las interfaces de creación de claves no soportan cantidades razonables de caracteres como para construir este tipo de clave. Esto viene por herencia de cuando las claves se almacenaban.

Sin embargo ya todos sabemos que almacenar claves de acceso es un riesgo muy alto que no debemos correr y que lo que en realidad se debe almacenar es un hash de dicha clave (MD5, SHA1, SHA256, Whirpool, etc.), y que dicho hash tiene una cantidad máxima de caracteres según el tipo. Unos de los más largos como el SHA256 por ejemplo, siempre tendrá 64 caracteres así la clave tiene el largo de todo un libro.

Quizás otra de las razones para limitar la cantidad de caracteres en los campos de ingreso y creación de claves ha sido que estos son los primeros en ser utilizados por los hackers para intentar ubicar vulnerabilidades de XSS, SQL injection y muchas más, pero hay que recordar a los programadores que el que coloquen un simple atributo "maxlength" a los campos de ingreso de un formulario no evita que los hachers forjen formularios independientes. Por otra parte una buena política de desinfección de parámetros de entrada no puede basarse en controlar el flujo de ingreso de esa simple forma.

Por tanto, se deduce de lo anterior que si en realidad se desea que los usuarios puedan utilizar claves de acceso fuertes, se deberá permitir lo siguiente:
  • Campos de ingreso de clave con capacidad muy superior de caracteres (60 es un buen número).
  • Capacidad de insertar cualquier tipo de caracter UTF-8.
Sin embargo por mucho que aumentemos la capacidad, es importante recordar que el usuario podría seguir introduciendo claves débiles si no las validamos, por lo que un componente de validación de la fuerza de la clave del lado cliente es imprescindible para garantizar que los usuarios aprendan a mejorar la calidad de sus claves de acceso.

Hasta la próxima.

Entradas populares