¿Qué son los HTTPonly Cookies?

Como ya es sabido una de las mayores amenazas que rondan las aplicaciones web es el XSS o Cross Site Scripting, y algunas de sus múltiples variantes basan su operatividad en la modificación o lectura de los cookies generados por la aplicación en el navegador del usuario.

Si bien un buen sistema de desinfección de parámetros de entrada desde y hacia la aplicación es siempre la mejor solución ante este tipo de ataques, una técnica muy útil que existe desde hace tiempo en el navegador Internet Explorer 6 SP1 y adoptada por todas las nuevas versiones de otros navegadores (Firefox desde 3.01, Opera desde 9.5 )  consiste en declarar los cookies como HTTPonly, protegiéndolos de lectura y escritura por parte de scripts del lado del usuario. De esta forma solo el servidor y el navegador tendrán acceso a la información guardada en los mismos.

La solución es en realidad muy simple en algunos casos, por ejemplo en ASP.NET solo tendrá que agregar un parámetro a la línea de configuración "httpCookies" al archivo de configuración web.config:

<httpCookies httpOnlyCookies = "true"... />

En PHP el proceso es parecido, añada la siguiente línea al archivo php.ini:

session.cookie_httponly = True

En Java EE desde la versión 6, se soporta la propiedad o flag HttpOnly en la interfaz Cookie y esta puede modificarse a true o false con los métodos setHttpOnly y getHttpOnly.
En Tomcat 6 puede colocar la línea del archivo context.xml . Esto es válido para cualquier framework basada en Tomcat como por ejemplo JBoss.

useHttpOnly = True

Como cualquier programador web podrá apreciar el proceso es muy simple, sin embargo esto no es la panacea anti-XSS, recuerde que para estar seguro ante ataques de este tipo de amenaza y otras como el SQL injection, la única solución eficiente proviene de una desinfección a conciencia de los parámetros de entrada hacia a la aplicación.

Vishing, Smishing y ¿Que tan segura es la plataforma en línea de mi banco?

Dos técnicas interesantes están volviendo al ruedo y tomando fuerza en la actualidad: El Vishing y el Smishing. Aunque desde hace tiempo son conocidas, en estos momentos en que la plataforma de VoIP crece cada vez más, es cuando empezamos a escuchar acerca de casos con este tipo de ataques.

Vishing no es más que un termino acuñado a partir de VoIP y Phishing, es decir hacer Phishing a través de sistemas de "Voz sobre IP" (Voice over IP) tales como Skype, Messenger o cualquier otro que permita comunicación de voz desde su PC.

El Smishing es también un termino acuñado de la mezcla de SMS y Phishing, o lo que significa hacer Phishing por SMS o mensajería de texto (se incluyen los sistemas para chatear en línea también).

Es un  hecho que los usuarios saben en su gran mayoría que no deben entregar claves de acceso ni otro tipo de información por teléfono o por SMS, pero los amigos de lo ajeno ensamblan sistemas muy inteligentes a la hora de cometer sus fraudes.

Por ejemplo, ¿Que haría usted si mientras está conectado a su página del banco, recibe una supuesta llamada del mismo banco por Skype? ¿Creería en la autenticidad de la misma si un operador le dice que para confirmar su transacción es necesario enviar sus datos por este medio alterno también?

Posiblemente usted no, pero seguro conoce mucha gente de la que no tiene idea acerca de cómo reaccionaría ante este tipo de fraude.

La mecánica del mismo es simple: los atacantes normalmente se basan en la ignorancia de ciertos aspectos tecnológicos, y algunos usuarios podrían creer incluso que ellos originaron la llamada al entrar en la interfaz del banco. La llamada es generada en algunos casos, porque el usuario ha instalado una aplicación que sin que él lo sepa envía una señal a los atacantes cada vez que se abre la página de la aplicación del banco.

Es por esta razón primordial que cada vez más son necesarios métodos de validación mas eficientes y seguros. Si su banco es de los que simplemente valida sus transacciones con un simple código o número de tarjeta y/o clave de acceso cuasi permanente, la cual es usted responsable de cambiar cada tanto porque ni siquiera le advierte que lleva mucho tiempo usándola, entonces es hora de que piense en cambiar de banco o exigir mejoras radicales en la plataforma.

Pero: ¿Cómo reconocer una interfaz bancaria segura?
En realidad aunque esto sea trabajo de profesionales, hay puntos muy interesantes para que usted pueda verificar si una plataforma bancaria en Internet al menos cumple con uno que otro estándar. No hablaremos aquí del protocolo seguro (SSL, HTTPS) ni del candadito del certificado, ya que sería el colmo que no lo usaran. A continuación cuatro puntos muy importantes que usted puede verificar:

1. No solo usted debe validar su acceso, la interfaz de la aplicación debe poder demostrar que no es falsa, mediante la presentación de elementos que solo usted conozca o que solamente puedan haber sido creados por dicha interfaz. Esto se logra por acceso en dos etapas, es decir en la primera usted solo entrega un dato (a veces su login o número de tarjeta) y en la siguiente fase de la interfaz reconociendo ese dato la aplicación debe mostrarle algo que solo usted conoce. De esta forma usted sabrá sin duda que no está en una página falsa ya que ha validado su autenticidad.
   
   
2. A la hora de las transacciones debe existir, una clave de seguridad adicional variable (si es fija el atacante solo tendría que hacerle una consulta más). Un pin que se recibe por otro medio en tiempo real puede ser la solución (OTP - One time password). También puede recibir en la misma interfaz unas coordenadas que debera verificar en una tarjeta matricial o rejilla de números, para introducir como clave segura los caracteres que se encuentran en cada una de las coordenadas recibidas de la rejilla. Hay otros métodos, pero lo importante es que existan, no entraremos ahora en que tan seguros son.
   
   
3. No debe permitir que usted pueda entrar a la interfaz desde dos computadoras simultáneamente, al menos una de las dos sesiones debe bloquearse al siguiente movimiento. Esto le protegerá de técnicas como CSRF (Cross Site Request Forgery) y otras mediante las cuales el atacante puede apropiarse de su sesión una vez que usted ha accedido a la página correcta.
   
   
4. Verifique que una vez dentro de la aplicación el URL completo siga siendo exactamente el mismo a pesar de que usted haya hecho varios clics y operaciones. De esta forma se asegura que la aplicación no está dando al atacante datos de cómo puede intentar acceder a las rutinas sin pasar por el proceso de acceso.

Estas son pruebas sencillas y usted mismo puede verificar estos puntos. Si usted duda del resultado simplemente no han sido contempladas por los desarrolladores o no lo han hecho con éxito.

Existen lógicamente muchas otras pruebas complicadas ante ataques de todo tipo, pero si su banco pensó en las anteriores ya tiene una buena parte de la calificación necesaria.

Hasta la próxima.

Fraude en línea especializado: Man in the Browser Attack

Zeus, Silon, Torpig y Yaludle son solo algunos de los troyanos letales de los más salvajes que están enfocados en procesos de fraude en línea. Este tipo de troyano, espera a que sus clientes o empleados certifiquen los datos de sus cuentas (log-in) en el sitio de la aplicación de banca en línea del banco para el que fueron creados, e interceptan la comunicación entre el navegador y el usuario o entre el navegador y el sistema operativo, aprovechándose de debilidades del software o de la comunicación entre aplicaciones del sistema. De esta forma la información es enviada a repositorios específicos (desde cuentas de gmail hasta servidores IRC (internet relay chat) en donde los datos son almacenados a la espera de que el atacante los analice y extraiga la información de acceso para cometer el fraude. Este tipo de ataques también son conocidos como "Zero day attacks".

Normalmente la victima debe ser muy lista e inteligente para poder darse cuenta de algún síntoma de este tipo de ataque ya que inclusive a través de SSL todo trancurre con extremada normalidad en su equipo.

Este tipo de troyano se manifiesta o se adquiere de muchas maneras, pero básicamente las mas comunes son:

• Objetos BHO (Browser Helper Objects) conocidos como complementos del navegador en el caso de Internet Explorer.
• Extensiones de Firefox (el mismo caso pero diferente navegador)
• Api-Hooking: Programas insertados en el equipo que interceptan la comunicación entre el navegador y sus librerías DLL.
• Librerías Javascript: Usando gusanos AJAX ( AJAX worms) se puede ver un ejemplo como prueba del concepto en http://myappsecurity.blogspot.com/2007/01/ajax-sniffer-prrof-of-concept.html.

Menos de un 20% de las victimas logran detectar este tipo de estafa a tiempo, y ello se debe a la total normalidad aparente del sistema en el momento del fraude.

Este tipo de ataque fué detectado por primera vez en Julio del 2007, cuando fué utilizado para robar información al  United States Department of Transportation. Sin embargo a partir de mediados del 2009 ha sido detectado de forma creciente. La red de equipos infectados con Zeus, por ejemplo se estima en más de 3.5 millones de computadores solamente en USA. En Julio 14 de este año (2010) la empresa de seguridad Trusteer hizo público un reporte según el cual un gran número de tarjetas de crédito de 15 bancos no mencionados habían sido comprometidas. La más reciente variante de este troyano es conocida como Kneber.

En la actualidad este tipo de ataques tienen mucho éxito y en latino-américa se han detectado varios casos en México, Perú y Argentina esperando su pronta propagación hacia otros países de la zona.

Los 10 riesgos más comunes de las aplicaciones web según OWASP - versión 2010

OWASP, Open Web Application Security Proyect, entre muchos otros proyectos enfocados a la educación de los desarrolladores en los métodos de defensa de las aplicaciones web, publica todos los años su lista de los 10 más peligrosos riesgos de seguridad para aplicaciones web (OWASP Top 10 Application 
Security Risks – 2010), la cual me he permitido traducir para ustedes a continuación:

Los riesgos expuestos por la OWASP para este año 2010 en orden de importancia son:

A1 - Inyección.
Fallas de inyección, tales como inyecciones SQL, de comandos de Sistema Operativo y de LDAP, ocurren cuando datos no verificados se insertan en comandos y consultas. El atacante puede utilizar el intérprete de estos para introducir comandos no permitidos o acceder datos no autorizados.

A2. - Cross Site Scripting, XSS.
Las fallas de XSS suceden cuando una aplicación toma datos no autorizados y los envía al navegador sin la propia validación o códigos de escape. El XSS permite a los atacantes ejecutar scripts en el navegador de la victima que pueden secuestrar su sesión, modificar sitios web o redirigir al usuario a sitios web dañinos.

A3. - Autentificación y Manejo de Sesión Rotos.
Las funciones relacionadas con la autentificación y el control de sesión muchas veces no son implementadas correctamente, permitiendo a los atacantes comprometer claves de acceso, llaves de control y tokens de sesión, permitiendo a los atacantes asumir las identidades de las victimas.

A4. - Referecias directas a objetos inseguras.
Una referencia directa insegura ocurre cuando el desarrollador expone una referencia a una implementación interna de un objeto, tal como un archivo, directorio o claves y campos de bases de datos. Sin control de acceso a los mismos u otra protección, un atacante puede manipular este tipo de referencia para tener acceso a datos de forma no autorizada.

A5. - Cross Site Request Forgery (CRSF).
Un Ataque de CRSF, fuerza al navegador "logueado" de la victima a mandar un "request HTTP", incluyendo el cookie de sesión de la victima y cualquier otra información de validación de la victima a una aplicación web vulnerable. Esto permite al atacante forzar al navegador de la victima para acometer daños o estafas que la aplicación piensa son iniciados por un usuario legítimo.

A6. - Fallas de Configuración de Seguridad.
Una buena seguridad requiere tener una configuración segura definida y entregada para la aplicación en si misma, entorno, servidor de aplicación, servidor web, servidor de base de datos y plataforma. Todos estos ajustes deben ser definidos, implementados y mantenidos, ya que no necesariamente las partes del sistema son entregadas con dichas configuraciones por defecto. Esto incluye mantener todo el software al día, incluyendo todas las librerías de código usadas por la aplicación.

A7. - Almacenamiento criptográfico inseguro.
Muchas aplicaciones no protegen los datos sensibles, como números de tarjetas de crédito, números de identificación del usuario y credenciales de autentificación con los tipos de cifrado y hashing apropiados. Los atacantes pueden robar o modificar estos datos pobremente protegidos para conducir ataques de robo de identidad, fraudes de tarjetas de crédito y otros crímenes.

A8. - Fallas en restricción de acceso a URLs.
Muchas aplicaciones verifican los derechos de acceso antes de que el usuario acceda a la aplicación por primera vez, sin embargo este tipo de verificaciones deben efectuarse cada vez que cualquiera de las páginas de la aplicación sea accedidas, o los atacantes podrán forjar direcciones URL que accedan a páginas o recursos prohibidos.

A9. - Insuficiente protección en la capa de transporte.
Las aplicaciones frecuentemente fallan en los procesos de autentificación, cifrado y garantia de confidencialidad e integridad del trafico de red sensible. Cuando no fallan, entonces puede suceder que usen algoritmos de cifrado débiles, certificados expirados o inválidos, o que no los usen correctamente.

A10. - Redirecciones y reenvíos sin debida validación.
Las aplicaciones web, generalmente redirigen o envían a los usuarios a otras páginas y sitios web usando datos no validados para hacerlo. Sin la apropiada validación, los atacantes pueden pueden redirigir a las victimas a sitios de phishing o malware, o usar los reenvíos para acceder a páginas no autorizadas.

Nuevamente coloco a disposición del lector el enlace de la OWASP como en otros artículos ya que es una de las fuentes más importantes de información acerca de la seguridad de aplicaciones web en la actualidad.

La importancia de la desinfección de parámetros para evitar ataques en la web

La razón más frecuente por la cual los sitios web sufren ataques de XSS (Cross Site Scripting), SQL inyection así como de otros tipos, se debe primordialmente a la falta de previsión por parte de los programadores a la hora de “Desinfectar los datos recibidos” desde la web o de terceros que pudieran sufrir del mismo problema.

La primordial razón para que un hacker pueda generar un ataque de este tipo a nuestra base de datos y a nuestros usuarios se debe primordialmente a lo anteriormente expuesto y la aceptación de parámetros infectados a su vez se debe a causas como:

Exceso de confianza: El programador no cree que su sitio por diversas razones amerite ser atacado por con alguno de estos métodos debido a que es un sitio común, no transaccional y que no mueve dinero. Lo anterior es falso, ningún sitio está a salvo actualmente debido a que si bien su sitio puede no ser blanco directo de una estafa, puede ser utilizado como redirección confiable de la misma o peor aún como distribuidor de la misma.

Inocencia a la hora de desinfectar los datos: Un desconocimiento de las técnicas básicas de XSS y “SQL Inyection” en la mayoría de los casos es el culpable de esta “inocencia” que genera sistemas de desinfección ineficientes.

Aumento de las rutinas de interacción con el usuario: Los programadores están acostumbrados a recibir datos por el URL o por un formulario. Si bien las técnicas AJAX y los componentes WEB 2.0 utilizan los mismos sistemas de paso de parámetros, como han sido creados por terceros se pudiera llegar a la falsa idea de que tratan el problema por defecto, lo cual en la gran mayoría de los casos es falso. Cualquier procedimiento que tome parámetros bien sea del usuario o de otras fuentes como bases de datos de terceros y servicios web, debe desinfectar dichos datos.

Grandes volúmenes de código y la carencia de rutinas centralizadas para el tratamiento de los datos: Cundo se generan cientos de páginas web, una gran mayoría de estas recibe parámetros. La falta de una rutina que centralice todas las solicitudes y redirija las mismas a las rutinas correspondientes, es la razón por la cual siempre escapa una rutina en la cual los datos no son validados correctamente. Bien sea por descuido o intervención de varios programadores en un mismo proyecto, a medida que una aplicación tiene más rutinas tiene más entradas de datos y por consiguiente más problemas de desinfección.

Creer que solo los campos de texto son vulnerables: En manos de personas expertas, todo parámetro o campo es vulnerable a infección. En un formulario forjado, lo que para nosotros es un “checkbox”, para un hacker es una entrada más de información en la que puede incluir código infectado. Lo mismo va para las listas y otros campos con entradas predefinidas.

Confiar en la validación del lado cliente en Javascript: Esto es un error muy común, basta solo desactivar el javascriopt para hacer que un formulario de datos se comporte de forma completamente impredescible para el sistema.

Para no entrar en detalle y aburrir, vamos a dejar las causas y entremos en las posibles soluciones:

• Estudio por parte del programador de las técnicas básicas de XSS y SQL Inyection (y otras): Una de las mejores fuentes de aprendizaje para un programador web es el OWASP (Open Web Application Security Proyect) http://www.owasp.org/index.php/Main_Page . Allí encontrará libros y artículos de seguridad web así como el proyecto WebGoat que consiste en una aplicación web auto instalable en su equipo, que deberá ser atacada por usted mediante técnicas que aprenderá paso a paso.

• Uso de APIs y librerías de desinfección de código:
  Para disminuir el esfuerzo requerido en grandes proyectos en referencia a la desinfección y control de parámetros, existen proyectos interesantes entre los cuales caben destacar los proyectos AntiSamy de OWASP para diferentes plataformas, que son simplemente APIS que permiten asegurar que los datos recibidos desde el cliente no contienen código maligno. Para aquellos que programen en ASP.NET , Microsoft pone gratis a disposición del programador la librería Microsoft Anti-Cross Site Scripting Library

• Centralización de las rutinas de recolección de desinfección de parámetros: Si su proyecto es razonablemente grande y debe evolucionar en manos de varios programadores, entonces debería empezar a pensar en generar una rutina única de recepción de parámetros. Esta rutina debe recoger los parámetros recibidos y enviarlos a las rutinas correspondientes ya depurados, así usted dejará de preocuparse por la desinfección de parámetros y otros asuntos de seguridad para los cuales tendrá que hacer revisiones en una sola rutina centralizada.

Espero que estos consejos les sean útiles para prevenir ataques de varios tipos de ahora en adelante, sin embargo recuerde un último consejo: No asuma absolutamente en cuanto a la desinfección de los datos, los atacantes se basan precisamente en vulnerar las posiciones comúnmente asumidas por los programadores.