Problemas de Seguridad Informática Dificultan la Adopción de Web 2.0


seguridadinformatica

Más de seis de cada diez empresas ya han sufrido pérdidas de 2 millones de dólares de media, con una pérdida colectiva de más de 1.100 millones de dólares relacionada con incidentes de seguridad informatica en el último año. El 60% muestra preocupación por la pérdida de reputación como resultado de los abusos de la Web 2.0.
“Las tecnologías Web 2.0 están impactando en la forma de trabajar de las empresas" afirma George Kurtz, CTO de McAfee. “El aumento de popularidad de la tecnología Web 2.0 ha provocado que las organizaciones se enfrenten a una elección – permitir que se propaguen sin control, bloquearlas o adoptarlas, así como sus beneficios, a la vez que se gestionan de forma segura".

"Leer Mas"

Comentarios

Opciones de visualización de comentarios

Seleccione la forma que prefiera para mostrar los comentarios y haga clic en «Guardar las opciones» para activar los cambios.
Imagen de ezamudio

Pues sí...

porque muchos creen que por poner validaciones con javascript ya no es necesario validar en el server, y porque la mayoría de las herramientas y frameworks que han salido últimamente van orientadas a producir algo que funcione muy rápido, o al menos que aparente que funciona; y los "programadores" que hacen esas aplicaciones no tienen idea de cómo funciona web ni nada, porque la herramienta "es tan fregona" que te oculta el funcionamiento de HTTP y todas esas cosas "complicadas".

El resultado? Que es muy fácil hacer submits a ciertas páginas, enviando datos inválidos y hacer que truene el servidor, o acceder a páginas a las que no se tiene permiso, a las que solamente se debería entrar con una sesión activa, pero se pueden ver porque no se hicieron las validaciones adecuadas de que la página solamente la vea un usuario registrado, etc. Regresa la inyección de SQL, que ya no era un problema tan grave, y regresa el XSS más efectivo que antes.

Súmale que muchos piensan que por agregar unas rutinas de "encriptación" de datos ya su sistema es seguro, o al menos con eso convencen al jefe o al cliente de que es seguro, y tienes un sistema muy vulnerable y luego los mismos creadores no saben ni cómo les están pegando. Como ejemplos recientes muy sonados, bastan los dos hacks de twitter que salieron tan seguido, donde se podía crear un tweet que no se veía pero que con pasar el mouse por encima del texto ya se ejecutaba un script que propagaba el ataque como tweet en el usuario que vio el tweet.

Imagen de tHe pLuCkY

La Importancia

Buenas noches ezamudio entonces quiere decir que estas herramientas son demasiado vulnerables si no son aplicadas de forma usual y con un buen uso de las herramientas o un buen framework que pueda evitar que se vulneren como lo sucedido hace dias en twitter, Pero obvio sin dejar de ser rapida la herramienta utilizada.
Muchas gracias por tu comentario y seguimos aprendiendo.

Saludos ! ! !

Imagen de JaimeItlzc

Vectores de ataque

Tal ves tenga algo que ver esto con seguridad de sitios web Ezamudio plateaba uno ejemplo sobre vectores de ataque muy buenos los deberias de chechar, incluso no se que tan nuevos sean algunos como los que atacan al hardware directamente al BIOS introduciendo codigo caracterizado como malisioso.

ACPI (Advanced Configuration and Power Interface) posee un lenguaje propio de alto nivel que puede ser usado para introducir código malicioso en la BIOS.

Todas las motherboard modernas poseen en su memoria flash tablas que asocian comandos en ASL (ACPI Source Language) y AML (ACPI Machine Language) concomandos de hardware. Esto permite añadir funcionalidades y reemplazar las existentes por otras, por ejemplo para elevar los privilegios de un programa (los procesadores actuales permiten controlar esto, aumentando la seguridad del sistema, sin embargo su estrecha relación con la BIOS merma este beneficio).

Esta que te acabo de describir es ACPI (Advanced Configuration and Power Interface) pero tambien esta otra que es la IPMI (Intelligent Platform Management Interface) esta es un herramienta de administracion remota.

Algunas marcas como son HP,intel y toshiba ultilizan esta herramienta que te comento para escuchar peticiones sobre los puertos UDP 663 y 664( No importa el sistema operativo su iteractividad es independiente del S.O)

Saludos.

Imagen de Nopalin

ese google

Llamenme puritano o lo que quieran, pero siempre he creido que el web no se creo con la idea de hacer sistemas y mucho menos seguros, fue creado con la idea de mostrar páginas con información que con hiper-enlaces te lleven a otra página con información. Creo que el problema del web es de diseño, no de implementación.

¿Por un cliente quiere un sistema web cuando solo va a hacer accesado desde su intranet? Alomejor por lo que ha escuchado, pero en realidad está demás, por que le mete al programador más trabajo y complicaciones con seguridad, siendo que una aplicacion de escriorio deberia ser mas segura y mas controlada.

En fin, sobres!

RE: ese google

Difiero contigo. Si bien en un principio la web fue lo que comentas, ahora las cosas han cambiado, los clientes han cambiado, los requerimientos del cliente han cambiado.

Una aplicación Web puede ser tan segura cómo una de escritorio....Y una de escritorio puede ser tan insegura cómo una web. Considero que lo que dijo @ezamudio tiene razón, es culpa más del programador y en ocasiones de las vulnerabilidades de las herramientas (hay ocasiones, muy pocas, pero las hay).

Además que cada una tiene sus ventajas, pero los requerimientos los pone el cliente y en base a esto se supone que uno debe hacer un análisis y decidir entre web o escritorio, x o y paradigma. No sé varios aspectos deben ser tomados en cuenta, por ello es que contratan nuestros servicios ;).

Imagen de ezamudio

Downtimes recientes

Y qué me dicen de los hacks recientes a Twitter y el downtime de varias horas que tuvieron Facebook y Foursquare... en todos los casos al final es falta de control de calidad. Los hacks de Twitter por no hacer pruebas suficientes; se me hace imperdonable que un sitio que vive del contenido de sus millones de usuarios, no verifique y limpie ese contenido que los usuarios meten. En el caso de Facebook, por configuraciones mal hechas se metieron a un ciclo infinito que les tiraba el sistema completo. Y ahora con Foursquare, una mala configuración de MongoDB (o un bug en ese software, no se sabe a ciencia cierta) los dejó fuera del aire durante 11 horas.

No es que MondoDB sea una porquería, o PHP (que usa FB) o Scala (que usa Twitter). Pero porquerías se pueden hacer en cualquier lenguaje. Yo pienso que si estás involucrado en el desarrollo de un proyecto con el potencial de ser usado por miles o incluso millones de usuarios, no solamente tienes que pensar en escalabilidad, que al parecer es lo único que trae todo mundo en la cabeza estos días; es vital también la seguridad, el monitoreo, la administración, tener planes de contingencia, respaldos, etc etc. El desempeño del sistema es importante pero no sirve de nada que tengas una pronta respuesta de un sistema que es fácilmente hackeable por vectores de ataque tan accesibles como un tweet. Ese campo de texto en la página, y los correspondientes campos en el API, debería estar super vigilado.

Tal vez sean consecuencias de la tendencia a test-driven development mal llevado, a integración contínua mal llevada, o a usar tecnologías de desarrollo rápido; las tecnologías y las metodologías como tales no son nada malas, son bastante buenas, pero creo que están siendo mal utilizadas y en varios casos se están usando para querer tapar la falta de talento en los programadores que han hecho estos sistemas. Otro ejemplo son las fallas de seguridad que se han hallado en el código fuente de Diaspora, que son tan abismales que a muchos les ha dejado una muy mala impresión, desprestigiando por completo el proyecto; está bien que al ser open source todos podemos ver el código, pero cuando ves código tan mal hecho a nadie le quedan ganas de tener que entrarle a corregir tantos errores.

Imagen de Nopalin

Bugs impensables

Pues a menos que tengas un equipo de testeo y debugeo de al menos unos 20 tipos, no creo que a 5 programadores se les puedan ocurrir todos los posibles escenarios que ocacionen algun bug. Tal vez es un poco burdo el ejemplo que voy a dar pero has visto la pelicula de un niño autista, donde decifra un codigo de criptografía que se utiliza para a segurar la información de muchas personas importantes, y este codigo vale millones de dolares? Bueno pues a pesar de ser película, yo creo que s acerca mucho a la realidad, donde dice que la mente humana es tan impresionante que puede hacer cosas que todavia no sabemos que hace. Estoy de acuerdo con tigo en que se deben hacer las suficientes pruebas para que un sistema se mantenga online 24/7 y no sea posible robar información, pero dime, con todos tus años de experiencia ¿crees que algún dia sea posible eso?, eso de hacer un sistema cuasi perfecto. Otro ejemplo que te puedo dar es un video juego. Acaban de sacar la segunda versión de un juego para pc llamado StarCrat, lo anunciaron desde el 2007, duro un año como beta siendo probado por miles y miles de usuarios, ademas de que la compañia tenia un equipo de expertos que se deicaban a ello tambien, y estoy un 99.9% seguro de que ya detectaron errores o lo haran en poco tiempo.

A lo que voy es que en esta época el web es la moda, impuesta casi por google con su facinante gmail, pero la tirada ahí fue mucho mas diferente. Apoco no han agregado parches y parches (o cambios y cambios) al protocolo http que ya difiere muchisimo de su origen? como lo dije antes el http tiene un problema de diseño no de implementación, si no fuera así entonces creo que el https nunca hubiera existido.

sobres!

Imagen de ezamudio

http

https es HTTP con SSL encima. No resuelve ningún problema de diseño de HTTP. HTTP no fue diseñado para dar seguridad en las comunicaciones, precisamente porque ya existían otras soluciones para eso; por eso se hizo https que es http via SSL. Http no tiene problemas de diseño; el problema es que se ha querido usar para todo y no siempre es la mejor opción. Hay aplicaciones para las que otros protocolos son mucho mejor solución... pero explícale eso a un programador .NET que no sabe ni qué es un socket, pero se siente muy fregón porque puede implementar un "web services" (así, en plural siempre), y si están haciendo un sistema que se va a comunicar con tu sistema, a fuerzas quieren que la interfaz sea via web services, obvio SOAP sobre HTTP, cuando por ser comunicación host to host se puede manejar un esquema de comunicación asíncrona con una sola conexión, algo mucho más eficiente para un volumen alto de transaccionalidad. Pero nuevamente: eso no es culpa de HTTP. HTTP es un protocolo que sirve muy bien para lo que fue hecho: transferir hipertexto.

Las broncas que menciono en los sitios que menciono, no fueron causadas por http. En el caso de Facebook, fueron unos scripts que hicieron para corregir una bronca en su base de datos, que estaban mal hechos y tiraron la base de datos, pero en cuanto reiniciaban el sistema, los scripts corrían de nuevo y volvían a tirar la base de datos. Dime, eso no se puede arreglar haciendo unas pruebas antes de echarlo en producción así nomás?

En el caso de Foursquare, tuvieron broncas con MongoDB, la base de datos que usan, de las que ahora están de moda, tipo NoSQL y que son distribuidas y pueden manejar millones de datos etc etc pero no se sabe bien si la tenían mal configurada o hay un bug en MongoDB pero la cosa es que uno de sus nodos estaba sobrecargado, la carga no se estaba esparciendo bien entre todos sus nodos (cada nodo es un server dedicado), y cuando quisieron arreglar ese problema, tiraron todo su sistema, dejándolo inaccesible durante 11 horas. Se supone que estas bases de NoSQL son distribuidas y son de alta disponibilidad, precisamente para que si un nodo falla, lo demás siga siendo accesible; pero supongo que si lo tienes mal configurado o diseñaste mal tu base de datos, puedes tener estas broncas. Entonces, no es control de calidad? No es algo que se pudo haber evitado? No pudieron haber hecho las cosas de manera distinta cuando detectaron el problema? Los mismos desarrolladores ya dijeron que primero intentaron una cosa que los dejó fuera del aire 5 horas, luego 1 hora para pensar la siguiente estrategia, la cual tomó 5 horas implementar. Tal vez son más broncas de deployment y administración de sistemas que del desarrollo, no podemos saber con la info que han dado hasta ahora, pero sigo creyendo que se pudo haber evitado o que se pudo haber solucionado más rápido. Y creo que el problema puede radicar en que "se les hace fácil" simplemente instalar MongoDB y usarlo porque el software se anuncia como la octava maravilla.

Y lo de Twitter... pues ahí sí creo que deberían haber hecho pruebas más rigurosas; no me parece aceptable que se les haya ido algo tan básico como no filtrar javascript en los tweets que publican los usuarios. El simple hecho de que la solución la hayan encontrado e implementado tan rápido, ni siquiera creo que hable bien de los desarrolladores, todo lo contrario, porque quiere decir que el problema también era muy simple, cómo es que nadie lo vio en pruebas?

Imagen de benek

Difiero contigo. Si bien en

Difiero contigo. Si bien en un principio la web fue lo que comentas, ahora las cosas han cambiado, los clientes han cambiado, los requerimientos del cliente han cambiado.
Una aplicación Web puede ser tan segura cómo una de escritorio....Y una de escritorio puede ser tan insegura cómo una web. Considero que lo que dijo @ezamudio tiene razón, es culpa más del programador y en ocasiones de las vulnerabilidades de las herramientas (hay ocasiones, muy pocas, pero las hay).
Además que cada una tiene sus ventajas, pero los requerimientos los pone el cliente y en base a esto se supone que uno debe hacer un análisis y decidir entre web o escritorio, x o y paradigma. No sé varios aspectos deben ser tomados en cuenta, por ello es que contratan nuestros servicios ;).

No del todo. Aunque las aplicaciones web cada vez se "asemejan" más a las de escritorio, en algunas ocasiones es solo el parecido visual. Adolecen precisamente de lo que dice Nopalin: la web fue pensada para desplegar páginas, no para crear aplicaciones. Poco a poco se ha ido adoptando, pero es por eso que ocasionalmente tenemos problemas que en una aplicación de escritorio serían impensables o triviales, acá un ejemplo.

Pasa lo mismo con la seguridad, poniendo el ejemplo del bug que comenta ezamudio: XSS, es un agujero de seguridad que causa dolores de cabeza desde que las páginas web quisieron implementar algo de lógica, y sigue vigente actualmente cuando ya hay "aplicaciones empresariales" en web, es un mal heredado que no tiene una solución determinante y generalizada.

Saludos.

Imagen de Nopalin

https es HTTP con SSL

https es HTTP con SSL encima

Claro, eso lo sé. En lugar de andar instalando en cada cliente un ssh que haga un tunel seguro lo hicieron directo sobre http, llamandolo https, presisamente para intentar resolver problemas de seguridad que en teoria no deberian de existir. Existen por que casi estoy seguro que una vez alguien dijo: "hey, es muy molesto esto de andar instalando actualizaciones en cada cliente cuando hacemos un cambio, mejor pongamos que la aplicación sea por el web y listo", jajaja, aclaro, me lo estoy inventando.
En java eso se soluciona fácil, se utiliza javaws y listo. Ahora en lo personal nadar manteniendo un servidor de aplicaciones es molesto para mi y no lo uso, en cambio utilizo un classloader especifico que me regrese los jars que ocupo de un contenedor de servlets (o script php o cgi o lo que sea), pero para no mantener un servicio aparte, la aplicacion servidor lanza jetty el cual tiene presisamente este servlet y viola!, ya tengo mi sistema que se actualiza en automatico sin necesidad de andar instalando en cada cliente algo mas que la pura jvm. A todo esto no digo que las web sean malas, son buenisimas, pero en un tono personal ya no me gusta hacia donde las estan llevando.

Y no solo ese problema @benek, que pasaria si tu cliente te dice: oye quiero que la autentificacion sea mediante un lector biométrico, o necesito que mande/reciva datos de un puerto serie o peor aún ,que monitoree algpun PLC que esta conectado a la red usando ethernet con una ip fija.

sobres