¿Cuál es el soporte actual de HTML5 en los navegadores web?

Una duda muy importante a la hora de adoptar un estándar es que tan soportado es el mismo por los navegadores más populares usados por el común de los usuarios.

HTML5 es una nueva propuesta que está siendo adoptada por todos en mayor o menor grado y aunque significa un gran salto en referencia a anteriores propuestas, quizás por esta razón no es adoptada al 100%  y cada navegador la ha adoptado según sus posibilidades o según las exigencias de los usuarios.

Para saber qué tan compatible es tu navegador con el nuevo e increíble HTML5 solo necesitas navegar al siguiente enlace desde el mismo http://HTML5test.com, sin embargo, como no siempre tenemos a mano todos los navegadores populares en nuestros equipos, les presento una lista de algunos de ellos instalados bajo sistema operativo Windows 7. Los resultados pueden extrapolarse perfectamente a otros sistemas operativos ya que lo que se mide en ellos es la tolerancia y compatibilidad del intérprete de HTML5 que suele ser prácticamente igual un el mismo navegador instalado en otros sistemas operativos.

Lo que he podido comprobar al visitar esta página con diferentes versiones de navegadores, es que ninguno de ellos ha adoptado la totalidad del estándar, siendo el mejor evaluado Chrome (versión 19.0.1084.52m) con 402 puntos de 500 posibles, seguido de cerca por Opera (11.62) con 338 puntos, para continuar la lista con por Firefox (11.0) con 330 puntos, Safari (5.1) con 277 puntos, y finalizar con Internet Explorer (9.0.8) con solo 138 puntos.

Estos resultados fueron obtenidos para la última actualización de este artículo (01 de junio 2012) con las últimas versiones conocidas de los navegadores, y demuestran varias cosas:

• El supuesto soporte de HTML5 en la versión 9.0.8 de IE ha sido implementado de forma realmente tímida y al parecer Microsoft ha puesto su esfuerzo en el próximo IE10 porque no se ve ninguna mejora a lo largo de todo un año.
• Chrome sigue a la vanguardia en lo referente a HTML5 y supera a algunos competidores con amplio margen. Sin embargo es seguido bastante de cerca por Opera.
• Safari y Firefox si bien muestran un soporte decente del nuevo estándar, han mostrado un ligero avance al respecto en sus últimas versiones desde nuestra última toma de datos en diciembre 2011.

A continuación las capturas de pantalla que demuestran lo anterior:

Chrome 19.0.1084.52m

Opera 11.62

Safari 5.1.2

Firefox 12.0

IE 9.0.8.112

Para cualquier otra prueba simplemente visita este enlace: http://htmltest.com

Allí podrás obtener además de la puntuación de cualquier versión de navegador la relación de soporte de cada uno los tags, items y nuevos parámetros del estándar propuesto para verificar las posibilidades actuales de desarrollar tus sitios con cada uno de estos nuevos elementos.

Hasta la próxima...

Samurai: Entorno de Testeo de Aplicaciones Web

He recibido varios correos solicitándome consejos acerca de cuál pudiera ser la mejor herramienta para diferentes trabajos relacionados con "pen-testing" de aplicaciones web. No es fácil tener siempre a mano la respuesta ya que es muy vasta la cantidad de herramientas y estas son en muchos casos bastante específicas en lo referente a su alcance. Por esta razón siempre es útil poder disponer de varias de ellas y tener a mano un compendio de las mismas en nuestro equipo para resolver apropiadamente las necesidades para cada área específica del "pen-testing" de aplicaciones web.

Samurai es precisamente eso, un compendio de aplicaciones que incluye lo que en la mayoría de los casos necesitamos, un entorno de pruebas para aplicaciones web es un marco de trabajo en GNU/Linux/Ubuntu que se distribuye en formato de Live CD y contiene las mejores aplicaciones de código abierto y gratis que se enfocan en testear y atacar sitios web. En el desarrollo de este entorno, fueron seleccionadas las herramientas que los profesionales de seguridad de aplicaciones web comunmente usan en sus prácticas de seguridad. En el mismo fueron incluidas herramientas de cada uno de los cuatro pasos del proceso de un test de penetración web.

La ventaja es que podemos ejecutarlo desde un DVD, o instalarlo para luego modificarlo a discreción según nuestras necesidades específicas.

Empezando con el proceso de "reconocimiento o footprinting", se incluyeron herramientas como Fierce domain scanner y Maltego. Para el "mapeo o mapping" fueron incluidas herramientas como WebScarab y Ratproxy. También se incluyeron herramientas de "discovery o descubrimiento" como W3af y Burp. Para la fase final de "explotación o exploitation" se dispuso de BeEF, AJAXShell y varias más.

El CD de Samurai, también incluye una "wiki" preconfigurada para ser el almacen central de información a medida que las vulnerabilidades y debilidades vayan siendo descubiertas.

Otro de los detalles interesantes, es que el navegador web (Firefox) viene pre-configurado con una serie de extensiones muy utilizadas en labores de pen-testing como por ejemplo Firebug, Hackbar y varias más.

Esta invaluable herramienta de seguridad para aplicaciones web en su versión 0.9.9 liberada el 13 de agosto de 2011 (al momento de escribir esto), puede ser descargada en formato ISO desde SourceForge en este enlace:

http://sourceforge.net/projects/samurai/files/ 

Hasta la próxima...

DoS producido por fallas de la Aplicación (Application Failure DoS)

Uno de los métodos más eficientes de bloquear o conseguir que una aplicación quede fuera de servicio, consiste en ubicar fallas comunes de aplicación que ejecutadas repetitivamente dejen a la aplicación y/o al servidor de la misma sin los suficientes recursos como para seguir prestando el servicio a sus usuarios.

A continuación enumeraremos y daremos una breve explicaciçon de las variantes de este tipo de ataque y la falla de programación en la que se basan para causar el daño perseguido por el atacante.

SQL wildcard attack:
Se basan en consultas que consumen gran cantidad de recursos del servidor SQL del que se alimenta la aplicaión, creando consultas con "wilcards" disponibles en las sentencias LIKE. Unos de los servidores más vulnerables a este tipo de ataque es el MSSQL debido a que posee unos tipos de caracteres wildcard muy potentes (%,[],[^],_).

Una consulta como:

SELECT * FROM Article WHERE Content LIKE '%foo%'

puede ser resuelta en una tabla con unos 10000 registros en menos de un segundo, mientras que la siguiente consulta puede amarrar al CPU hasta por 6 segundos en una tabla de apenas 2500 registros:

SELECT TOP 10 * FROM Article
WHERE Content LIKE
'%_[^!_%/%a?F%_D)_(F%)_%([)({}%){()}£$&N%_)$*£()$*R"_)][%](%[x])%a][$*"£$-9]_%'

DoS Locking Customer Accounts (DoS mediante bloqueo de cuentas de usuario):
Muchas aplicaciones bloquean al usuario si este o un atacante que se trate de hacer pasar por él cometen errores en la validación por más de un número determinado de veces. Este tipo de ataques convierte este mecanismo en un arma de negación de servicio creando intentos de ingreso con identificadores de usuarios conocidos.

DoS Buffer Overflow (DoS mediante desbordamiento del buffer):
Intentan generar errores de Buffer Overflow en las rutinas que solicitan datos, convirtiéndose en un arma que no permita que dichas rutinas completen su ciclo y liberen los recursos solicitados antes de que dicho error aparezca. El Buffer Overflow se genera cuando el atacante logra introducir datos en campos no suficientemente bien validados, que superan la capacidad del contenedor o variable creada para contenerlos. Por ejemplo si una variable se declara como entero simple de 16 bits, no podrá soportar que el atacante introduzca en un campo sin validar un número de 7 cifras.

DoS User Specified Object Allocation (DoS mediante creación de recursos específicos por el usuario):
Sucede cuando un usuario puede solicitar múltiples copias de un determinado objeto sin límite superior, lo que es utilizado para consumir toda la memoria asignada a la aplicación. Por ejemplo, si un usuario solicita un acceso a un determinado recurso que se guarda temporalmnete en una variable de sesión sin que exista un límite para la cantidad de veces que pueda hacerlo.

User Input as a Loop Counter (Utilizar el input de usuario como contador de bucles):
Se produce al forzar a la aplicación a entrar de forma repetitiva en un bucle de código que consuma gran cantidad de recursos. Se genera cuando se utiliza un parámetro que provee el usuario, como contador de un bucle y este es forjado por el atacante para aumentar radicalmente el numero de interacciones del bucle de código. Un ejemplo práctico puede ser un parámetro utilizado como contador de un sistema de paginación que se reciba por el URL. Si el atacante lo modifica podría lograr que en vez de mostrar una cantidad limitada de datos se muestre el contenido completo de una determinada consulta. Este ataque puede ser utilizado en conjunto con el SQL wildcard Attack.

Writing User Provided Data to Disk (Escribir datos que provee el usuario a disco):
Este tipo de ataque obliga al servidor a quedar sin suficiente espacio en disco, escribiendo datos provistos por el usuario, o llenado los archivos de logs.
Por ejemplo, uno de los problemas de un ataque por fuerza bruta que guarda los intentos fallidos en un archivo de registro, es que aunque no logre dar con la clave de acceso de un determinado sistema, puede dejar sin espacio en disco al servidor, debido a que el archivo de registro puede alcanzar un tamaño insospechado. Los formularios públicos que guardan datos en disco, deben ser controlados para que no puedan ser llenados por BOTs (sistemas de llenado automáticos) ya que pudieran agregar millones de datos basura al disco.

DoS Failure to Release Resources (DoS por fallas al liberar recursos):
Se debe a fallas del programador o del entorno en liberar eficientemente los recursos utilizados por la aplicación. Suele suceder con frecuencia al no liberar conexiones y sets de registros de bases de datos. Esta falla es muy simple de descubrir aunque no lo parezca, a veces el hacker todo lo que necesita es utilizar una herramienta de escaneo de vulnerabilidades para darse cuenta que los requerimientos excesivos de un recurso o página determinada al servidor lo hacen cada vez más lentos.

Storing too Much Data in Session (Guardar demasiados datos en sesión):
Sucede cuando se guardan demasiados datos en la sesión del usuario, específicamente si el usuario no es un usuario autentificado, por lo cual el atacante no necesita de mucho esfuerzo para dejar a la aplicación sin recursos en el pool de memoria.

OWASP Appsec Serie de Tutoriales - Episodio 3: Cross Site Scripting (XSS)

Ya acaba de ser publicado el tercer episodio de OWASP Appsec Tutorial Series que trata específicamente acerca de XSS o mejor conocido como Cross Site Scripting. No dejes de verlo es muy interesante y sencillo de entender.



Hasta la próxima...

¿Por qué el "login" o identificador de usuario es usado como un campo clave?

Hace unos tres años tuve una pequeña controversia con un ingeniero de una empresa a la que prestabamos nuestros servicios, simplemente porque él consideró un exabrupto el hecho de que yo le propusiera que usara un campo clave diferente al identificador de usuario convencionalmente conocido como "login" en la tabla de los usuarios de su aplicación web. No fué ese el único caso en el que sentí que las personas a quienes proporcioné dicho consejo lo tomaron como una locura por no decir algo peor.

Pero póngamonos a reflexionar un instante: En la actualidad todos los sistemas de manejo de bases de datos relacionales (MySQL, PostgreSQL, MSSQL, PL-SQL y otros) manejan tipos de campos de identificación de registros que se generan automáticamente de forma más que eficiente y que en muchos casos suelen ser utilizados como los connocidos IDs (Id_user por ejemplo). Estos pueden contener hashes únicos, ser campos autonuméricos secuenciales o simplemente identificadores aleatorios a gusto del programador.

El campo comunmente conocido como "login" si bien tiene que ser demostradamente único para un determinado usuario no necesita ser utilizado para identificar un determinado registro de usuario en un grupo de tablas relacionadas. Existen muchos otros identificadores más sólidos y fiables como por ejemplo el número del documento de identidad del usuario o simplemente un campo clave autogenerado.

Aclaremos, no hablo de eliminar el identificador de usuario de los procesos de validación de ingreso, lo que estoy proponiendo es que este campo no sea utilizado como campo clave del registro ya que esto último es una limitación seria de seguridad en la mayoría de los casos, ya que al ser un campo clave relacionado con otras tablas y procesos, no podremos cambiar su contenido.

Todos aquellos que hemos hecho alguna vez un sistema de control de acceso, sabemos que ciertas rutinas como aquellas de recuperación y cambio de clave de acceso son ciertamente parte obligada de dichos sistemas, debido a que bajo un concepto de seguridad obsoleto, el campo correspondiente a la clave de acceso soporta todo el peso de la seguridad del proceso de validación de ingreso. Esto puede variar, si permitimos que también pueda ser cambiado el campo correspondiente al identificador del usuario.

Imaginemos el ejemplo típico en que una persona en una empresa detecta el "login" del administrador o gerente de la misma en una interfaz de acceso de un programa o aplicación de banca en línea. Para poder penetrar en la aplicación solo necesita conocer el password. Imaginemos también que este segundo dato es obtenido mediante cualquier proceso de hacking o ingeniería social de los tantos existentes y que el gerente de la empresa se percata o sospecha que alguien ha utilizado sus datos de acceso. El paso siguiente será cambiar la clave para tratar de que el atacante no pueda ingresar nuevamente. Sin embargo si no conoce el proceso por el cuál su clave ha sido vulnerada (vector de ataque) lo más probable es que en poco tiempo el atacante pueda nuevamente conocer dicha clave y entrar nuevamente en la aplicación.

Sin embargo otra cosa sería que el atacante tenga nuevamente que descubrir dos campos, ya que en nuestra aplicación hemos permitido (verificando que no puedan existir duplicados) que el usuario pueda cambiar no solo la clave de acceso sino también el identificador de usuario. Haciendo esto reducimos la presión sobre el campo de la clave de acceso y repartimos algo mejor la responsabilidad de ingreso en ambos campos. También aumentamos radicalmente el tiempo necesario para adivinar los datos por fuerza bruta. No tendremos que controlar demasiado la longitud de dicho campo ya que no se repetirá su contenido en otras tablas, pudiendo permitir inclusive logins en forma de frases. Identificadores de acceso como "El mejor usuario que ha tenido este banco" no deberían extrañarnos y serían mucho más difíciles de adivinar.

Los hackers me han enseñado que si uno quiere saber el login o identificador de un usuario, en el 50% de las veces basta con saber la parte anterior al arroba (@) en su dirección de e-mail principal. Permitiendo o exigiendo cambiar el identificador en un caso de sospecha de intrusión la seguridad del sistema de ingreso aumentará radicalmente y esta premisa dejaría de ser cierta.

De todas  formas aclaro que tampoco es muy sano tener solamente dos factores de autentificación en un sistema de acceso, pero mucho menos lo es que uno de esos dos factores sea prácticamente público y permanente. Actualmente los factores de autentificación solicitados por empresas de certificación y de regulación están en el orden de cuatro o cinco incluyendo un factor externo a la aplicación. Sin embargo eso es tema para otro artículo.

Hasta la próxima!

Curso de Seguridad de Aplicaciones Web en Quito y Guayaquil

Un gran éxito (debo confesar aunque a mi no me toca decirlo), han sido los cursos de "Seguridad de Aplicaciones Web" dictados en Guayaquil y Quito, a los que asistieron buena parte de los programadores, desarrolladores y expertos en seguridad de sistemas del área bancaria del hermano país de Ecuador.

Promocionado por Banred y E-Securing C.A. en el curso se trató principalmente cada uno de los puntos del OWASP Top 10 con ejemplos y descripciones de cada uno de los puntos del conocido documento. Sin embargo la temática a diferencia de otros cursos de seguridad para aplicaciones web se basó esta vez en técnicas pro defensa del usuario. Consejos importantes acerca de como combatir el phishing, pharming, tab-nabbing, clickjacking y otras técnicas que no dependen directamente de las vulnerabilidades de las aplicaciones web, fueron parte importante de la segunda fase del curso y captaron fuertemente el interés de la audiencia, que por demás está aclarar fue una de las mejores que he tenido el honor de tutelar en este tipo de eventos.

En realidad fue un placer dictar los cuatro cursos (2 en cada ciudad) para un grupo de profesionales que además de captar en gran medida mi exposición, hicieron del curso una plataforma de discusión muy interesante aportando sus experiencias y dudas.

Debo agradecer ante todo a la gente de Banred, que fueron quienes coordinaron todo lo referente a la logística y en especial a Lizzie Noblecilla (Lider de Proceso Revisión y Control de Banred) y al Lic. Pablo Narvaez (Gerente General de Banred) sin cuya ayuda seguramente los cursos no hubieran sido posibles.

Ya estamos pensando en preparar una serie de talleres de seguridad de aplicaciones web, en los que les prometo que hablaré mucho menos... :D

Muchas gracias nuevamente a todos los asistentes, organizadores y en especial a la gente de las hermosas ciudades de Guayaquil y Quito, ah sin olvidar a la gente que asistió al evento por vídeo conferencia desde Loja.

Hasta la próxima...

Porqué utilizar números pseudo-aleatorios criptográficamente seguros.

Uno de los procedimientos más comunes en el área de desarrollo web es la generación de "Tokens" o cadenas de caracteres no repetibles y aleatorios que de forma única puedan diferenciar a una entidad de otra sin duda alguna. Estos tokens son usados por ejemplo para generación identificadores de sesiones o de usuarios, identificadores de formularios y muchos otros usos en los que se requiera de una identificación segura de la entidad que representen.

En la gran mayoría de los casos los programadores basamos nuestras rutinas de generación de tokens en la generación de números pseudo-aletorios. Estos son producidos por rutinas denominadas PRGN (Peudo Random Number Generators).

La calidad de los números producidos por los PRNG se basa en la impredictibilidad de los mismos, y una rutina de generación de números pseudo-aleatorios es más fuerte de forma inversamente proporcional a la posibilidad de predicción de sus resultados.

Como es bien sabido, hoy en día un lenguaje de programación que no posea una rutina, clase o función que permita generar este tipo de números es algo bastante raro. El típico método "Random()" o "Randomize()" está presente en casi todos ellos.Sin embargo estas rutinas nativas de los lenguajes de desarrollo, no han sido creadas pensando en la entropía o impredictibilidad de sus resultados sino en la velocidad de obtención de los mismos, por lo que la predictibilidad es relativamente bastante alta en comparación con rutinas avanzadas o especializadas creadas para dicho fin.

Lo que llamamos predictibilidad es en términos criptográficos conocido como "entalpía" u orden, o lo exactamente contrario a "entropía"o desorden. Mientras más entropía posean nuestros resultados, menos predecibles serán.

Si nuestra aplicación requiere de "tokens" en los que se basan procesos de seguridad de cierto riesgo (como por ejemplo en la producción de una matriz de coordenadas únicas o tarjeta matricial) entonces nuestras rutinas PRNG deberían ser criptográficamente seguras. 

Si bien el mayor defecto de las rutinas criptográficamente seguras de PRNG es que son más lentas que las que producen las rutinas por defecto de los diferentes lenguajes de programación, la garantía es que producen series de números pseudo-aleatorios mejor distribuidos y por ende con mayor entropía.

Para utilizar rutinas PRNG criptográficamente seguras en .NET podremos usar la clase RNGCryptoServiceProvider , bajo la interfaz System.Security.Cryptography, mientras que en Java podemos utilizar la clase java.security.SecureRandom y sus respectivos métodos. Seguramente los números pseudo-aletorios generados con los métodos de estas clases serán mucho menos predecibles y por tanto los tokens y las funciones que dependan de ellos aumentarán la seguridad de los procesos en los que se utilicen.

Hasta la próxima...

Más acerca de cómo prevenir el Cross Site Request Forgery (XSRF)

Una de las amenazas a las que hace pocos años no se les hizo mucho caso fue el Cross Site Request Forgery conocido por las siglas XSRF o CSRF. Ya hemos hablado de esta amenaza con anterioridad y si quieres conocer en detalle de qué se trata puedes acceder a este enlace.

Para resumirlo el CSRF utiliza la confianza que un sitio deposita en un usuario que ha validado correctamente su sesión, y mediante técnicas de engaño hace que el usuario sin saberlo trabaje en favor del atacante introduciendo  en el sitio transacciones que redunden en beneficio de este último.

Todas las medidas de autentificación de usuarios a este punto ya han validado al usuario por lo que no sirven ya de nada para evitar el ataque. Un ejemplo podría darse en un sistema de banca en línea en el que el usuario ha accedido y mientras aún su sesión sigue activa el atacante logra mediante alguna treta que el usuario pulse por ejemplo un enlace como este:

https://mibanco.com/transferir.php?cuenta=NroCuentaDelAtacante&monto=1000

Algunas personas tienen la creencia de que este tipo de ataques solo puede ser ejecutado mediante el método GET, y siento decirles que por el método POST son inclusive mucho más efectivos. El ejemplo fue realizado con un enlace (GET) solo por fines didácticos.

Si bien el usuario ha validado su sesión, todos sus datos de verificación como por ejemplo su "cookie" de sesión serán enviados por el navegador a la aplicación del banco ya que este mantiene una sesión abierta con dicho sitio y esos datos son válidos. Esto sucede aunque el usuario haya pulsado el enlace desde otra página en el mismo navegador.

Es siempre importante educar al usuario acerca del hecho de que no debe desviar su atención y mantener la sesión con el sitio de su banco abierta mientras hace otras cosas. Sin embargo sabemos bien que cuando se trata de una cantidad grande de usuarios esto puede llegar a ser un trabajo enorme.

¿Cómo evitar entonces este problema a nivel de desarrollo?

Existen varias formas:

Doble-posted cookie (envío doble de cookie):
Esta técnica se basa en que si bien el navegador envía toda la información relacionada a la sesión, si agregamos un campo oculto a cada formulario con el valor del identificador de sesión, podremos evitar el ataque, ya que el atacante debe conocer este valor para incluirlo en el enlace o el formulario oculto en su página. El navegador no se lo proporcionará por las políticas de seguridad de dominios cruzados. Sin embargo aunque de forma más compleja el atacante podría robar el cookie de sesión mediante otras técnicas, por lo que este método no es el más confiable.

Unique form nonce (formulario único para cada solicitud):
Se trata de generar un formulario con un campo oculto dinámico que es generado por cada solicitud. El contenido del campo debe ser generado aletoriamente utilizando un buen sistema de PRNG (Pseudo Random Number Generator) para que no pueda ser adivinado mediante técnicas estadísticas avanzadas. Este campo se guardará en el servidor y será eliminado apenas el formulario sea utilizado ya que una nueva solicitud del formulario deberá ser acompañada por un nuevo contenido en el campo. Si se recibe un formulario con un contenido no válido, simplemente se rechaza la solicitud.  Hay quienes han perfeccionado la técnica también asignando un nombre aleatorio al campo mediante el mismo concepto. Esta técnica es muy interesante ya que no solo elimina el  XSRF sino evita que un usuario introduzca dos veces la misma transacción (lo que puede suceder facilmente si el usuario presiona el botón de enviar dos veces porque la conexión es lenta y no ha recibido la respuesta esperada). Además este sistema evita también que el formulario sea escaneado en busca de vulnerabilidades, ya que la gran mayoría de los "scanners" de vulnerabilidades, cargarán el formulario una sola vez para luego proceder a "jugar" con el contenido de los diferentes campos.

Requerir credenciales de autentificación nuevamente:
Es una interesante técnica que se basa en requerir nuevamente los datos de ingreso del usuario al momento de generar una transacción. Algunos sitios han inclusive generado lo que denominan "clave para transacciones" que no es más que un factor adicional de validación solicitado solamente en caso de generar un procedimiento que involucra movimiento de capital. La desventaja de este método es lo fastidioso que puede llegar a ser si se hacen muchas transacciones, o el problema que puede significar para el usuario recordar una nueva clave.

One time Passwords:
Un OTP o dispositivo que genera claves de acceso de un solo uso es una solución definitiva ante el XSRF y muchos otros problemas, sin embargo su costo es el principal factor a tomar en cuenta en estos casos. Este tipo de solución podría ser sobre-dimensionada dependiendo del tipo de aplicación y la cantidad de usuarios de la misma. Si necesitas saber algo más acerca de este tipo de componentes puedes visitar el artículo que trata acerca de este tema.

Espero que estas técnicas puedan ser tan útiles para ustedes como lo han sido para mí.

Hasta la próxima!

Protegiendo los formularios de autentificación e ingreso.

Los formularios de autentificación de usuarios son unas de las rutinas más atacadas de las aplicaciones web, debido a que ellos son los que separan a los atacantes de los que podríamos definir como el cofre al final del arcoiris. En los sitios web que utilizan formularios de autentificación basados en consultas SQL, varios tipos simples de "SQL injectión" pueden ser utilizados para eludir la validación del usuario. Por ejemplo, una consulta SQL típica para verificar dicha validación podría ser la siguiente:

SELECT * FROM users WHERE username = 'nombreUsuario' AND password = 'claveUsuario'

En esta consulta se reemplazarían a nivel de aplicación "nombreUsuario" y "claveUsuario" por los contenidos introducidos por el usuario en el formulario de validación y si una validación correcta de los parámetros ingresado no es efectuada, un atacante podría introducir en el primer campo la secuencia de caracteres "admin' --" (las comillas dobles son para efectos de redacción de este artículo, no las tome en cuenta). Lo anterior significaría que al reemplazar los valores la consulta resultante sería:

SELECT * FROM users WHERE username = 'admin' --AND password = 'cualquier cosa' 

La consulta resultante sería realmente:

SELECT * FROM users WHERE username = 'admin'

Todo lo que se encontrara después de los dos guiones pasarían a ser simples partes de un comentario, por tanto la consulta devolvería los datos del usuario "admin" sin siquiera haber verificado la clave del mismo. Como se podrá observar esta es una consulta demasiado simple para necesitar herramientas automatizadas de pen-testing, y su principal error además de la falta de desinfección de parámetros es el uso común de un nombre de usuario como "admin" que de seguro se encuentra en absolutamente todas las listas de las herramientas de intrusión existentes.

Otro método un poco más elaborado se basa en introducir un condicional en el campo de la clave, en este caso introduciremos el código inyectado  "' OR 1=1 --" (nuevamente no tome las comillas dobles en cuenta).

La consulta resultante esta vez sería:
SELECT * FROM users WHERE username = 'admin' AND password = 'cualquierCosa' OR 1=1 --'

La segunda parte de esta consulta preguntará a la maquinaria SQL si el password del usuario es correcto o si uno es igual a uno, y como basta que una de las dos sea cierta la sentencia devolverá nuevamente TRUE por lo que el resultado traerá nuevamente los datos del usuario sin verificar la clave.

Lo que importa realmente entender de los anteriores ejemplos son dos detalles importantes:

1. Todos lo campos deben ser desinfectados. Existe la absurda creencia de que el único campo vulnerable es el que contiene la clave del usuario, y como se ha podido observar se puede iniciar la inyección de código desde el primer campo de una forma ridículamente simple.
   
2. No solo es necesario proteger la clave de los usuarios, el hecho de que el identificador comúnmente conocido como nombre o "login" pueda ser obtenido, es una vulnerabilidad en si misma. Esto sucede principalmente por devolver respuestas inadecuadas a la hora de un ingreso erróneo en el formulario de acceso. 

El atacante utiliza nuestras respuestas de error para obtener usuarios válidos. Basado en nombres compuestos con números, es posible obtener la gran mayoría de los nombres de usuarios de una muestra. Las respuestas que ayudan a validar si estos existen son:

• "Error de ingreso: la clave proporcionada no es correcta", en este caso si la clave no es correcta entonces debe ser que el usuario si lo es.
• "Error de ingreso: El nombre de usuario proporcionado no existe!", y en este otro caso se despeja la duda, este usuario en realidad no existe.

Estas son la forma más eficiente para que el atacante intente obtener nombres de usuarios validos. La respuesta correcta debería ser:

• "Error de ingreso: La combinación de usuario y clave proporcionados no es válida" o algo parecido que no indique a ciencia cierta cual de los dos campos es el incorrecto o si ambos lo son.

Este  punto de la obtención de usuarios válidos no solo refiere a intentos de ataque cuando se trata de inyecciones SQL. Es importante entender que los sistemas de intrusión por fuerza bruta utilizan dos tipos de ataques: Ataques de profundidad y ataques de amplitud.

Los ataques de profundidad son aquellos que se realizan intentando ingresar con un mismo "login" o nombre de usuario y miles de diferentes posibles claves de acceso. Solo cuando se termina de comprobar la lista de claves de acceso se pasa entonces a otro nombre de usuario. Sin embargo los ataques de amplitud son aquellos en los que se utiliza una misma clave o password, para una lista de posibles usuario.

En base a lo anterior, un ataque de amplitud sería mucho más útil si ya conocemos una cantidad determinada de nombres de usuario, debido a que el atacante sabe sin duda alguna que estos no pueden repetirse bajo ningún concepto, sin embargo las claves de acceso si pueden ser iguales para usuarios diferentes, no existe ninguna regla que lo prohiba.

También hay formularios no validan contra una maquinaria SQL sino por ejemplo contra un servicio LDAP o archivos estaticos XML. En estos casos la diferencia no es tan notable, en vez de usar técnicas de "SQL injection" se utilizarán "LDAP injection" o "XPath injection", y aunque la sintaxis de la injección sea diferente los principios de defensa son exactamente los mismos. A saber:

• Desinfectar los datos recibidos por parte del usuario.
• Proteger los "logins" o nombres de usuario, mediante respuestas de error que no aseguren nada. Este punto es válido también para los sistemas derecuperación de clave, que suelen ser uno de los primeros agujeros por donde obtener usuarios válidos.
• Utilizar sistemas de bloqueo de acceso con máximo de intentos. Estos deben ser procedimientos del lado del servidor. El bloqueo mediante "cookies" no es útil cuando los formularios son forjados o el ataque proviene de una herramienta de ingreso por fuerza bruta.

Esperando que estos consejos le sean útiles me despido hasta la próxima...

Mejorando la seguridad del Internet Information Server (IIS).

Consejos para mejorar la seguridad del Internet Information Service (IIS)

Una programación segura es muy importante, pero no podemos olvidar la plataforma del servidor en la que la aplicación reside, empezando por el sistema operativo y llegando hasta el software encargado de prestar el servicio HTTP, por lo que ciertos consejos de seguridad en lo referente a este último nunca deben despreciarse. Sin embargo debido a los diferentes tipos de servidores web y sistemas operativos, estos consejos pueden variar sustancialmente aunque los principios de protección sean los mismos.

En este artículo especialmente vamos a centrar nuestra atención en el Internet Information Service conocido comúnmente como IIS, que es la plataforma que ofrece Microsoft para sus servidores Windows 2000, 2003 y 2008.

IIS es una plataforma mixta de servicios web (HTTP/HTTPS, FTP, SMTP y NNTP) y las versiones con las que  comunmente podemos conseguirnos son la 5, 6, 7 y 7.5. Sin embargo si usted actualmente tiene algún tipo de servicio en la primera de estas (versión 5) o anteriores, el mejor consejo que podría darle es que trate de mudar sus aplicaciones a cualquiera de las versiones superiores.

Entrando en materia a continuación mostraremos una lista de acciones o consejos que aumentarán la seguridad de este tipo de plataformas:

Reduzca la superficie de ataque apagando o eliminando los servicios que no necesita.
Ya que el IIS es una plataforma de servicios múltiples lo primero que debe hacer es reducir radicalmente la superficie de ataque apagando o eliminando los servicios de dicha plataforma que no se utilizan. Es muy sabido que un servidor SMTP mal configurado puede dedicar la mayor parte de los servicios de su sistema operativo a enviar SPAM. Tener un servicio FTP activo permanentemente es una brecha por la cual el atacante podría introducir sus scripts malignos en nuestra web. Y ni hablar del NNTP!

Desactive la opción de mensajes de error detallados.
Si bien en el ambiente de desarrollo esta opción es de gran ayuda, mantenerla activa solo sirve para que un atacante intente generar errores que le entreguen información adicional y le descubran algún dato que abra la brecha de seguridad esperada. Para información acerca de cómo desactivar esta opción en ASP.NET puede visitar este enlace. También puede manejar sus errores de forma dinámica, es decir haciendo que la página de especial de error que usted cree sea también una página dinámica que reporte el error a una base de datos o un archivo de registros personal, así como que envíe un e-mail dependiendo del tipo de error. Algunos ejemplos puede encontrarlos aquí.

Instale sus directorios de aplicación web en una unidad diferente a la unidad que aloja el sistema operativo. 
En caso de que un atacante pudiera obtener acceso a la unidad en la que usted aloja su aplicación, usted agradecerá sobremanera que este no tenga a mano utilidades importantes del sistema operativo como cmd.exe y otros igualmente poderosos.

Remueva el mapeo de extensiones no utilizadas.
Su servidor probablemente pueda y esté listo para resolver el mapeo de extensiones asp, php, cgi y otras dependiendo de los diferentes módulos CGI o librerías ISAPI instaladas. Nuevamente, si usted no necesita ejecutar ASP clásico o PHP simplemente deshabilite este tipo de extensiones.

Use URLScan.
URLscan es un módulo que permite filtrar direcciones URL con determinadas características que pudieran considerarse como intentos de ataque. Inclusive actúa como una especie de firewall de aplicación que puede evitar una gran parte de los problemas. Sin embargo recuerde: la mejor manera de eliminar una brecha de seguridad en su aplicación es corregirla en el código en la que se origina. Descargue el URLscan aquí

Siempre utilice el sistema de archivos NTFS para las unidades en las que debe alojar sus aplicaciones.
El problema con los sistemas de archivo FAT y FAT32 es que no utilizan un sistema de control de acceso lo suficientemente cerrado como para alojar aplicaciones web en las que los recursos deban restringirse de forma eficiente o variadas. El sistema ACL de NTFS es muy superior y por tanto mucho más seguro.

Mantenga los archivos de registro de sus servicios web fuera del directorio de su aplicación. 
Por defecto los archivos de registro se encuentran en el directorio "c:\windows\system32\logs" lo cual es perfecto, pero algunos administradores los ubican en otros directorios para evitar que los programadores u otros usuarios que los necesiten tengan acceso a un directorio tan crítico como este. La idea no es mala, pero tampoco se deben ubicar bajo el directorio web de nuestra aplicación. Los archivos de registros de IIS como en cualquier otro sistema, tienen un formato de nombre preestablecido, por lo que son muy fáciles de ubicar una vez conseguido un directorio "logs", "weblogs" o algo parecido mediante el uso de un scanner de rutas y archivos como por ejemplo OWASP Dirbuster. Usted no querrá que el atacante pueda obtener información detallada de la ubicación de los recursos simplemente bajando a su equipo uno de estos archivos.

Renombre, borre o restrinja el acceso a cualquier utilidad potencialmente peligrosa.
Quizás por esto es que principalmente hay que colocar la aplicación en una unidad diferente a la del sistema operativo. Sin embargo si en la unidad en la que está ubicada la aplicación usted encuentra alguna aplicación potencialmente peligrosa trate de eliminarla, restringir el acceso a la misma o renombrarla.

Desative el usuario "guest" y elimine el acceso de usuarios del grupo "guests" a áreas fuera de su directorio principal de IIS (webroot).
Usuarios como IUSR_machinename e IWAM_machinename pertenecientes al grupo "guests" no deben tener acceso a ninguna otra parte que no sea el directorio de la aplicación web. Tampoco deben tener atributos de escritura o ejecución en ninguna carpeta de sus aplicación. Utilidades para subir archivos necesitan a veces atributos de escritura en algún directorio, y si no puede evitar usar este tipo de componentes arcaicos, pues almenos en las propiedades del directorio seleccionado elimine todo tipo de permisos de ejecución de secuencias de comandos y archivos ejecutables.

Utilice si es posible los módulos de Restricción dinámica de IPs.
Este módulo relativamente nuevo, le permitira defenderse de ataques de DoS limitando las solicitudes múltiples de ciertas características que las pudieran identificar como intentos de DoS. Lo único malo de este módulo es que solo está disponible para IIS 7.0 y 7.5 - http://www.iis.net/download/dynamiciprestrictions.

Hasta la próxima...

SHODAN - Buscador de servicios y servidores

Hoy estaba revisando literatura vieja y me encontré con un enlace muy interesante que quise comprobar si aún estaba activo, y mi sorpresa fue mayúscula al ver cómo esa aplicación o mejor dicho herramienta web ha progresado desde que dejé de usarla.

Como debiéramos saber, una de las primeras cosas que necesita saber el atacante de nuestra aplicación son:

• La plataforma y versión de nuestro sistema operativo.
• Tipo de servidor web.
• Plataforma de desarrollo.

Conocer esta información a veces suele ser muy fácil debido a que una buena parte se puede deducir por el contenido de los headers HTTP que recibimos del servidor cuando solicitamos una página o recurso al mismo.

Por cierto, algo de esa información se puede eliminar para hacerle el trabajo más difícil al atacante. Por ejemplo en el IIS el "header" incluye siempre por defecto "X-Powered-by: ASP.NET" o algo parecido dependiendo de la versión, pero eso podemos eliminarlo simplemente modificando en la opción de encabezados HTTP del sitio web. Podemos cambiarlo a gusto, ya que no es para nada relevante en cuanto al funcionamiento del sitio.

Volviendo al tema: ¿Pero y si lo que queremos es encontrar servidores dentro de un rango específico que muestren una característica dada? pues entonces aparece la utilidad de la que les venía hablando: SHODAN

No solo busca servidores por características sino por regiones geográficas y tipo de puerto. En fin que SHODAN es algo así como un "escanner" de puertos a nivel mundial. 

Aquí les dejo un pantallazo para que se den una idea:

Por ejemplo se puede hacer una búsqueda de todos los servidores Apache bajo Ubuntu en Suiza. ¿Interesante? Es una herramienta muy potente y tiene muchos otros plugins y ventajas para algunas de las cuales necesitarás comprar créditos. Sin embargo las consultas básicas son gratis.

Los reportes son muy completos e interesantes, ya que incluyen la respuesta de los encabezados comunes de los servidores que cumplen con la consulta. ¡Disfrútenlo!

Hasta la próxima...

Razones por las que no se eliminan las vulnerabilidades en las aplicaciones web.

El reciente estudio publicado por WhiteHat Security denominado Winter 2011, 11th Edition, nos ofrece entre muchos otros datos interesantes tomados de un estudio estadístico tomado de 3,000 websites a través de 400 organizaciones, el resultado de las razones por las cuales las vulnerabilidades de los sitios de dicho estudio no fueron corregidas a tiempo.

A continuación me permito traducirlas para ustedes para que puedan comentarlas y estudiarlas:

Factores que inhiben a las organizaciones a remediar las vulnerabilidades de sus aplicaciones web:

• Nadie en la organización entiende o es responsable de mantener el código.
• Nadie en la organización conoce o entiende los aspectos de la vulnerabilidad.
• Mejoras en las características de la aplicación se priorizan por delante de los parches de seguridad.
• Falta de presupuesto para solucionar los problemas.
• El código afectado es propiedad de un tercero que no responde.
• Sitio web será dado de baja o sustituido "pronto ". Es necesario acotar, que algunos de los sitos que  presentaron esta razón se mantuvieron en línea por más de dos años.
• El riesgo de la explotación de la vulnerabilidad es aceptado.
• Solución de la vulnerabilidad entra en conflicto con negocios en proceso.
• El cumplimiento de las normas vigentes no requiere la eliminación de la vulnerabilidad.

Es muy probable que ustedes hayan usado o escuchado estas razones en más de una ocasión. Lo que definitivamente es cierto es que el estudio también refleja en una de sus lecciones lo siguiente:

La explotación de una sola vulnerabilidad en una aplicación web es suficiente para perturbar de manera significativa la línea de negocios, causar la pérdida de datos, sacudir la confianza del cliente, y mucho más. Por lo tanto, las vulnerabilidades mientras antes se identifiquen y más rápido que se eliminen más corta será la ventana de oportunidad para que un atacante malicioso pueda explotarlas.

Hasta la próxima...

¿Porqué atacan a las aplicaciones web?

Las motivaciones para el hacking de aplicaciones web son numerosas y se han discutido en profundidad durante muchos años en una variedad de foros. No vamos hacer un refrito de muchas de esas conversaciones, pero es importante señalar algunas de las características de las aplicaciones web que las hacen tan atractivas para los atacantes. La comprensión de estos factores conducirá a una perspectiva mucho más clara de las defensas que deben ser adoptadas para mitigar el riesgo.

Ubicuidad:
Las aplicaciones web están en casi todas partes hoy en día y siguen extendiéndose rápidamente a través de redes públicas y privadas. Para los hackers de aplicaciones web la probabilidad de encontrar una aplicación "jugosa" y vulnerable es cada vez mayor.

Técnicas simples de ataque:
Las técnicas de ataque de aplicaciones web son bastante fáciles de entender, incluso para los legos, ya que son en su mayoría basadas en texto. Esto hace que la manipulación de datos de entrada de la aplicación sea realtivamente trivial. En comparación con los conocimientos necesarios para atacar aplicaciones más complejas o sistemas operativos (por ejemplo, la elaboración de desbordamientos de buffer), atacar aplicaciones web es como quitarle un dulce un niño.

Anonimato:
El Internet todavía tiene muchas regiones no catalogadas o auditadas, y es bastante fácil para lanzar ataques con poco o sin temor de ser rastreado. El rastro del Web Hacking, en particular, es de fácil lavado (y a menudo sin darse cuenta) a través de  proxys HTTP/S que son abundantes en la Red. Hackers sofisticados enrutan cada solicitud a través de un proxy diferente para hacer las cosas aún más difíciles de rastrear. Sin duda, ésta sigue siendo la razón principal para la proliferación del hacking malicioso, ya que el anonimato protege al atacante de uno de los principales factores de disuasión en el mundo físico (es decir, ser atrapado y castigado).

Incapacidad de los Firewalls:
El HTTP/S entrante (puertos 80 y 443) es permitido por todos los cortafuegos o firewalls. Está de más decir que esta no es una vulnerabilidad de los mismos, sino un comportamiento necesario para poder recibir las solicitudes de los navegadores clientes. Inclusive esto seguirá sucediendo a pesar de que cada vez más aplicaciones emigren a la Web.

Código personalizado:
Con la proliferación de plataformas para facilitar el desarrollo web como ASP.NET y LAMP (Linux / Apache / MySQL / PHP), una gran parte de las aplicaciones web son ensambladas por desarrolladores que tienen poca o ninguna experiencia previa en seguridad de aplicaciones.

Seguridad inmadura:
HTTP ni siquiera pone en práctica control desesiones para reconocer usuarios únicos. La autenticación básica y la autorización de principal para HTTP fue adosada en años posteriores a que la tecnología se popularizara y aún sigue evolucionando en nuestros días. Muchos desarrolladores generan código propio de control de sesiones y autorización y logicamente muchos también se equivocan (aunque esto está cambiando con el creciente despliegue de plataformas de desarrollo web que incorporan procesos de gestión de sesiones y autorización nativos.

Cambio constante:
Por lo general, un montón de gente constantemente manipula una aplicación web: desarrolladores, administradores de sistemas y gestores de contenidos de todo tipo. ¡Hemos visto muchas empresas donde el equipo de marketing tiene acceso directo a la granja de servidores web de producción! Muy pocas de estas personas tienen la formación adecuada seguridad y sin embargo, están facultados para realizar cambios en un complejo entorno de aplicaciones web de forma constante. En este nivel de dinamismo, es difícil llevar un control de cambios sencillo, y mucho menos garantizar que la política seguridad se aplique de manera coherente.

...y por supuesto: Dinero.
A pesar de los contratiempos de la era punto-com, está claro que el comercio electrónico a través de HTTP apoyará muchos negocios lucrativos en un futuro previsible. Como era de esperar, las estadísticas recientes indican que la motivación para la piratería informática web ha pasado de la fama a la fortuna, en paralelo con la maduración de la propia web. Cada vez más, las autoridades están descubriendo empresas delictivas organizadas construidas sobre el hacking de aplicaciones web con fines de lucro. Ya sea de forma particular mediante robos de datos a los servidores web, el fraude contra los usuarios finales (también conocido como "phishing"), o la extorsión mediante la denegación de servicio, el hecho lamentable de la situación actual es que el crimen web paga bien.

Hasta la próxima!

¿Cómo practicar para descubrir y remediar las vulnerabilidades web más comunes?

Si bien he hecho énfasis en otros artículos que la mejor forma de prevenir una vulnerabilidad es específicamente conocer cómo el atacante puede valerse de ella, no siempre tenemos ejemplos o sitios a parte de los propios en dónde podamos hacer pruebas de forma legal. Ya he mencionado en otros artículos también sendas soluciones del tipo de aplicaciones premeditadamente vulnerables que podemos instalar en nuestros servidores de desarrollo con las cuales hacer las prácticas necesarias para descubrir las diferentes formas en que dichas vulnerabilidades pueden ser aprovechadas.

He mencionado proyectos muy interesantes como Google Gruyere y el famoso OWASP Webgoat, herramientas muy interesantes con expreso fin didáctico en el área de la seguridad de aplicaciones web, pero existe otra de este tipo de aplicaciones que ha merecido en los últimos meses menciones muy interesantes en las revistas y blogs específicos que tratan el tema. Esta aplicación no es otra que  Damn Vulnerable Web App (DVWA) que no es más que una aplicación en PHP y MySQL que como las anteriores explora el aprendizaje en el área de seguridad de aplicaciones desde una aplicación deliberadamente vulnerable, permitiendo que los programadores o técnicos aprendan y manejen los conceptos y procesos en un entorno completamente legal.

Una de las ventajas más importantes quizás de DVWA es que a diferencia de las anteriores una de sus presentaciones viene ya en formato de imagen ISO (LIVE CD), mediante la cual usted podrá quemar un CD de arranque en el cual ya se encuentra instalada la aplicación y todo el entorno LAMP (Linux, Apache, MySQL y PHP) necesario para que usted puede arrancar en su PC o en un entorno virtual una imagen lista para experimentar y aprender con ella de inmediato sin necesidad de tener que instalar todo el entorno o adaptar la aplicación a un entorno existente.

Sin embargo si usted es de aquellos a quienes les gusta conocer los procedimientos de la instalación o está obligado a instalarla en un servidor existente, entonces también podrá utilizar el formato convencional de aplicación web simple.

DVWA, es un proyecto bien logrado, y sin duda un muy buen aliado para los que como utilizamos este tipo de aplicaciones como ayuda en los cursos que dictamos de seguridad de aplicaciones web.

Hasta la próxima...

Diez razones por las que las aplicaciones web son tan vulnerables.

¿Está su organización gastando más en café que en seguridad de aplicaciones web?

Según un estudio reciente de Ponemon Institute que encuestó a más de 600 profesionales en seguridad IT que trabajan en un vasto rango de industrias, las empresas si bien empiezan a estar concientes del problema que envuelve a la seguridad de sus sistemas y clientes, no están gastando suficiente en la seguridad de sus aplicaciones web. El estudio revela que el presupuesto para café de la empresa es considerablemente más alto que el utilizado (cuando lo hay) para proteger sus aplicaciones web de ataques y corregir vulnerabilidades.

1. Mientras el 73% de las organizaciones de los encuestados han sido hackeadas por lo menos una vez en los pasados 24 meses 72% de ellas testean la seguridad en menos del 10% de sus aplicaciones web.
   
2. 20% de las organizaciones no testean la seguridad sus aplicaciones web para nada.
   
3. 40% de las organizaciones solo testean la seguridad del 5% de sus aplicaciones web.
   
4. El porcentaje extrapolado de todas las aplicaciones web testeadas por seguridad es menos del 13%. La razón principal es falta de presupuesto y de conocimientos necesarios.
   
5. De aquellas organizaciones que hacen tests de seguridad a sus aplicaciones web solo el 13% lo hace en estado de producción.
   
6. 21% de los que respondieron no sabían que tanto tarda corregir una vulnerabilidad y el 6% dijeron que nunca han podido corregir una vulnerabilidad o eliminarla.
   
7. Las decisiones para corregir vulnerabilidades en aplicaciones web son tomadas informalmente (46%) o no existe esfuerzo alguno en priorizar su corrección.
   
8. En el 88% de los casos los presupuestos para café ($30 por empleado al més) son mayores que el gasto en seguridad de aplicaciones web.
   
9. 69% de los participantes confía en los firewalls de red para brindar seguridad a sus aplicaciones web.
   
10. Solamente el 29% de los encuestados cree que los firewalls para aplicaciones web son críticos para la seguridad de la infraestructura de red de la organización.

Como podrá observar, existe poca o muy poca conciencia acerca de la necesidad de testear la seguridad de las aplicaciones web. Si usted está por contratar servicios "outsourcing" para desarrollo de aplicaciones web en su organización, la solución puede ser tan simple como agregar en su contrato de servicios las cláusulas necesarias para que la aplicación pase por un proceso de testeo una vez haya sido finalizada. En el momento anterior a la firma de dicho contrato las empresas de desarrollos serán indudablemente mucho más flexibles y los costos serán muy inferiores a los de adaptar la seguridad a una aplicación ya hecha. Además si se toma en cuenta la seguridad desde el momento mismo de el diseño de la aplicación su organización podrá ahorrarse una cantidad importante de dinero y preocupaciones futuras.

El artículo completo y presentación en inglés se encuentran en el siguiente enlace:

http://www.channelinsider.com/c/a/Security/Security-vs-Coffee-Spending-10-Reasons-Why-Web-Applications-Are-Easy-Targets-824994  

Redactado por Mauro Maulini R.

Cómo evitar el SQL injection en Java y C#

Una de las amenazas más peligrosas del primer tipo de los OWASP top 10 de 2010, es decir de las amenazas que se refieren a inyecciones de código, son precisamente las temidas inyecciones SQL. Si no conoces su funcionamiento antes de continuar puedes ir a http://tecnologiasweb.blogspot.com/2008/07/sql-injection-el-enemigo-ms-peligroso.html y luego regresar a este artículo.


Prevenirlas no ha sido fácil, sobretodo porque muchos programadores han querido filtrar los caracteres que reciben antes de crear las consultas, y en ese caso suceden dos cosas: O no siempre se filtran todos los caracteres perjudiciales que pudieran intervenir en una inyección de código SQL, o se filtran algunos caracteres que pudieran ser de uso común, por lo que se le restringe la usabilidad al usuario.


Las soluciones definitivas y conocidas para este flagelo pasan primordialmente por usar métodos que no puedan confundir parámetros con comandos. El primero de estos métodos es el uso de consultas parametrizadas. ¿Que es una consulta parametrizada? Pues lo mejor en este caso es un ejemplo, empecemos con Java:

---

   // '?' el símbolo indica la ubicación del parámetro
   querySQL = 
   conn.prepareStatement("SELECT nombre FROM empleados WHERE salario > ?");


   // Completando la consulta
   // Note que se empieza con "1" para el primer parámetro
   querySQL.setInt(1, 350);
   rs = querySQL.executeQuery();
}
   catch(Exception ex)
{
   System.err.println("Excepción de base de datos: " + ex);
}

Como se puede observar en el lugar del parámetro que convencionalmente colocaríamos se ha colocado un signo de interrogación, y el método PreparedStatement.setInt() coloca en el primer parámetro un entero igual a 350. 


No hay manera de que se pueda colocar otra cosa en el contenedor que no sea un entero. Si fuera una cadena aunque esta llevara caracteres dañinos, estos no serían jamás tratados como código precisamente por haber sido "parametrizados".


En C# el proceso es parecido:







SqlCommand command = connection.CreateCommand();

command.CommandText = “SELECT * FROM Customers WHERE CustomerID = @CustomerID“;

command.Parameters.Add(
       new SqlParameter(“@CustomerID“, SqlDbType.NChar, 5)).Value = "GSDC3"




En este caso simplemente hemos introducido un parámetro SQL precedido por el arroba (@) "@CustomerID" y lo cargamos con su valor correspondiente con el método command.Parameters.Add()




El segundo método de prevención consiste en desarrollar procedimientos almacenados (stored procedures) directamente en la base de datos SQL. Si bien este método es más complejo, agrega una capa de seguridad adicional a la aplicación ya que los procedimientos almacenados al ser objetos de SQL pueden ser tratados independientemente cada uno con una permisología aparte además de colocar la lógica de manejo de la base de datos en la misma base de datos.

OWASP Appsec Serie de Tutoriales - Episodio 2: Injection Attacks

Lo prometido es deuda. Luego del primer e interesante episodio de la serie de tutoriales de seguridad de aplicaciones web de OWASP aquí tenemos el siguiente episodio sobre un tema muy interesante: Ataques de Inyección o Injection Attacks.

Disfrútenlo.



Hasta la próxima

7 Peligrosos Mitos de la Seguridad de Aplicaciones Web

A continuación aclararemos algunos mitos de seguridad con los cuales tropezamos a diario en nuestra profesión, tratando así de evitar que este tipo de presunciones erróneas puedan convertirse en vulnerabilidades explotadas y empresas o usuarios víctimas de una errónea política de seguridad de aplicaciones web:


Mito 1: Cumplimiento de estándares = Seguridad
Es de anticipar sin mucho cálculo que la velocidad de crecimiento del medio es muy superior a la capacidad de las organizaciones de crear estándares adaptados a las tecnologías que diariamente emergen en el desarrollo web, por lo tanto el hecho de que se apliquen ciertos estándares no garantiza seguridad en las aplicaciónes web y a veces inclusive produce brechas debido a que no aplica el refrán de "lo que fué bueno para mis padres y abuelos...". Los estándares deben aplicarse en el contexto para el que fueron creados, aplicar estándares fuera de contexto o tratar de adaptarlos sin un estudio serio puede ser inclusive un riesgo en sí mismo.

Mito 2: ¡Nosotros no tenemos brechas de seguridad!
Creer que las aplicaciones que utiliza o produce su empresa no tienen vulnerabilidades, es como creer que la tierra es plana o algo así. Ambas son visiones que se tienen porque nuestro conocimiento de la realidad se limita a un ámbito muy específico. Si usted utiliza software de terceros y/o desarrolla software con plataformas de terceros (lo que casi todos hacemos) entonces su software es inequívocamente vulnerable. No hay términos medios. Ah, y esto es suponiendo que usted sea una estrella de la seguridad, porque si usted es un simple mortal como yo entonces el problema es mayor de lo que piensa, y definitivamente la tierra es esférica.

Mito 3: Las defensas de red nos protegerán.
Creer que un sistema con SSL bien implementado lo protegerá de errores en el desarrollo de la aplicación web es muy peligroso. El SSL y los Firewalls o Routers no lo protegerán de vulnerabilidades en el aplicativo. Inclusive los Firewalls de Aplicaciones lo protegerán de inyecciones SQL y XSS en casos limitados, pero si la lógica de su aplicativo presenta fallas estructurales estas herramientas poco pueden hacer para protegerle. Además debe pensar que sus aplicaciones son utilizadas por miles de diferentes entornos y usted además debe prevenir fallas del lado del cliente o la utilización por parte del atacante de usuarios genuinos a manera de puente para intentar penetrar su aplicación, como en el caso del XSRF.

Mito 4: La Seguridad de Aplicaciones Web es problema de otros.
Esta es un de las fallas más recurrentes en el proceso de desarrollo de aplicaciones web. Los desarrolladores no programan defensivamente debido a que piensan que los expertos de seguridad se preocuparán del problema y estos últimos asumen que la aplicación debe bastarse por si sola en lo referente a seguridad. Ni lo uno ni lo otro es cierto. La seguridad bien entendida proviene de una  acumulación de capas concéntricas que se protegen unas a otras.

Mito 5:  La teoría de la solución mágica.
Frases como las siguientes son síntomas inequívocos de problemas de seguridad presentes y futuros:

• Java y C# son lenguajes seguros, usarlos elimina la mayoría de las posibles vulnerabilidades.
• Un test de penetración descubrirá todas las vulnerabilidades
• Un escanner de código encontrará todos las posibles brechas de seguridad de la aplicación
• Nosotros hicimos tal cosa y por ende la seguridad es un tema cubierto.

Los lenguajes como C# y Java ayudan a mitigar los problemas de seguridad en aplicaciones, pero nada pueden hacer si el desarrollador no conoce o tiene un conocimiento limitado acerca de las excelentes herramientas que estos lenguajes ofrecen.

Un test de penetración hallará las vulnerabilidades en proporción directa a la experiencia del experto en seguridad que lo efectúe.

Sucede igual con el resto de las herramientas, su éxito depende de la pericia de quien las utiliza, y aunque esta pericia sea de la mayor posible, la rapidez evolutiva del medio puede y suele sobrepasar cualquier nivel de experiencia.

Un sistema mágico e inexpugnable que resuelve absolutamente todos los aspectos de la seguridad se reconoce porque nos deja "mágicamente" desnudos cuando es vulnerado. No podemos ni debemos creer en una seguridad proveniente de una única solución mágica.

Mito 6: La seguridad es demasiado costosa, por lo que prefiero correr el riesgo.
Aparte del hecho de que un ataque que perjudique los datos sensibles de nuestros usuarios y nuestra empresa siempre es mucho más costoso que los costos de implantar las soluciones y herramientas necesarias para prevenirlo, la seguridad es siempre una buena inversión. Los altos costos de la seguridad son un mito. Organismos como OWASP, WASC pueden con sus tutoriales y herramientas de código abierto ayudar de gran manera en la reducción del costo relativo a la protección de aplicaciones web. Por otro lado empresas como Microsoft ponen a la orden sin costo alguno sus conocimientos con el SDL Software Development Life Cycle, inclusive algunos gobiernos ponen a disposición listados de prácticas seguras y de tipos de vulnerabilidades. En este blog podrá hallar también muchos documentos sobre el tema completamente gratis.

Mito 7: El Código Contratado por Outsourcing es completamente vulnerable (o completamente seguro)
Las empresas contratadas para desarrollo de aplicaciones web, no necesariamente están en una de las vertientes completamente opuestas de este mito. La responsabilidad de la seguridad en el software contratado a terceros empieza en nuestra empresa a la hora de establecer por escrito los requerimientos. Lo que normalmente sucede es que las empresas que desarrollan software se ajustan a los requerimientos de los contratos y rara vez estos tienen cláusulas específicas referidas a posibles técnicas de seguridad necesarias en la aplicación. Por tanto si se descubre una falla en este tipo de aplicaciones, la empresa contratada pasará un presupuesto para corregirla porque simplemente "esa protección o atributo no estaba contemplado en el contrato inicial". Como verá la seguridad empieza por establecer en el contrato las cláusulas correspondientes a la seguridad de la aplicación, y es un hecho que una empresa contratada tomará las medidas necesarias para cumplir dichas cláusulas y no verse demandada a futuro. Para saber qué cláusulas hay que colocar todo lo que debe hacer es leer detenidamente un "checklist" de prácticas de seguridad en desarrollo de aplicaciones web.

Espero que esta visión desde un punto de vista diferente le sea de ayuda a la hora de tomar las decisiones correctas en la materia.

Hasta la próxima...

¡Los 25 Errores de código más peligrosos! - según CWE/SAMS

Una muy importante fuente de información de seguridad de aplicaciones en general es el CWE (Common Weakness Enumeration), una comunidad perteneciente al MIT, que como su nombre lo indica se dedica a enumerar y clasificar los tipos de debilidades y vulnerabilidades de las aplicaciones, incluyendo por supuesto a las aplicaciones web.

Esta organización junto con SANS (SysAdmin, Audit, Network, Security) han publicado una lista muy importante de los 25 errores más graves en desarrollo de aplicaciones, y todos ellos aplican perfectamente a las aplicaciones web.

He traducido en dicha lista para Ustedes los nombres de los errores (excepto cuando la traducción no tiene significado y el término es conocido) para que puedan en nuestro lenguaje verificar cada uno de los errores y su nivel de importancia.
He dejado los enlaces al sitio original para cada uno de los errores de la lista, esperando en próximas entregas poderlos ir traduciendo uno por uno.

Posición	Puntuación	ID	Nombre
[1]	346	CWE-79	Neutralización Impropia del Input Durante la Generación de la Página Web (XSS- Cross Site Scripting)
[2]	330	CWE-89	Neutralización Impropia de Elementos Especiales utilizados en un Comando de SQL (SQL Injection)
[3]	273	CWE-120	Copiado hacia el Buffer sin verificación del tamaño del Input (Classic Buffer Overflow)
[4]	261	CWE-352	Cross-Site Request Forgery (CSRF)
[5]	219	CWE-285	Control de Acceso Inapropiado (Authorization)
[6]	202	CWE-807	Confianza en Inputs no Asegurados en una Decisión de Seguridad
[7]	197	CWE-22	Limitación Impropia del Recorrido de Directorios a un Directorio Específico (Path Traversal)
[8]	194	CWE-434	Capacidad de Subir Archivos de Tipos Peligrosos no Restringida
[9]	188	CWE-78	Neutralización Impropia de Elementos Especiales Utilizados en Comandos de OS (OS Command Injection)
[10]	188	CWE-311	Carencia de Cifrado de Datos Sensibles
[11]	176	CWE-798	Uso de Credenciales en Código Fuente.
[12]	158	CWE-805	Acceso al Buffer con valor Incorrecto de Longitud
[13]	157	CWE-98	Control Indebido de Nombres de archivo para los Comandos Include/Requiere en un Programa en PHP (PHP File Inclusion)
[14]	156	CWE-129	Validación Indebida de las posiciones de un Arreglo.
[15]	155	CWE-754	Verificación Impropia de Condiciones Inusuales o Excepcionales.
[16]	154	CWE-209	Exposición de Información Delicada a través de mensajes de Error.
[17]	154	CWE-190	Indebido control de 'Giro de Enteros'
[18]	153	CWE-131	Cálculo Incorrecto del tamaño del Buffer
[19]	147	CWE-306	Falta de Autenticación para Funciones Críticas
[20]	146	CWE-494	Descarga de Código sin Chequeo de Integridad
[21]	145	CWE-732	Asignación Incorrecta de Permisos para Recursos Críticos
[22]	145	CWE-770	Asignación de recursos sin límites o con límites excesivos
[23]	142	CWE-601	Redirecciones de URL a sitios no confiables (Open Redirect)
[24]	141	CWE-327	Uso de un Algoritmo Criptográfico Inseguro o Roto
[25]	138	CWE-362	Race Condition

Espero que la lista les resulte útil.
Hasta la próxima...