Vulnerabilidades Web

0

En el artículo de hoy vamos a ofreceros el Top 10 de vulnerabilidades web que nos pueden ocurrir hoy en día si administramos un site.

El OWASP u Open Web Application Security Project acaba de publicar su informe anual de amenazas, que muestra resultados parecidos a los de últimos ejercicios, incluyendo vulnerabilidades de inyección de código y Cross site scripting en web.

El laboratorio cita los peligros de inyección de código en webs como la mayor amenza para los desarrolladores actualmente. Los hallazgos en basados en datos proporcionados por 8 firmas especializadas en seguridad de aplicaciones, que arrojan datos sobre más de 500000 vulnerabilidades encontradas en cientos de organizaciones y miles de aplicaciones.

Los mayores peligros

Formando el top 3 de vulnerabilidades web encontramos la “rotura de autenticaciòn“, administración de sesión y el cross site scripting, con las dos primeras ascendiendo un puesto respecto al último estudio. Los problemas de inyecciones como en SQL y Lightweight Directory Access Protocol (LDAP) siguen encabezando el grupo.

Gráfico de vulnerabilidades web

Las vulnerabilidades de inyección de código ocurren cuando una aplicación envía datos no confiables hacia el interprete, según explica el laboratorio. Las inyecciones de código están muy extendidas, sobre todo en código de cierta antiguedad. Normalmente se encuentran en entornos SQL, LDAP, Xpath o peticiones NoSQL, analizadores de XML, encabezamientos SMTP, instrucciones de programas, etc.

“La mejor manera de verificar si una aplicación es vulnerable a ejecución de código comprometido es comprobar que todo el uso de interpretes separa claramente los datos no confiables de los comandos u órdenes”, según apunta el informe. Para llamadas SQL, esto significa emplear variables sujetas o controladas en todas las órdenes y procedimientos guardados, evitando peticiones dinámicas.

Las tres categorías principales son problemas que se conocen desde hace al menos una década, según informa Chris Eng, vicepresidente de Veracode.

“Desafortunadamente -según afirma- estas vulnerabilidades prevalecen tanto (en parte por las prácticas laxas en seguridad que ha habido durante años) que resulta difícil identificarlas y repararlas usando un manual de testeo de seguridad, que es a día de hoy una práctica común”. Consideremos que la gran empresa posee 600 aplicaciones de negocio críticas, y de acuerdo a los datos el 32% de ellas tienen al menos una inyección de código SQL y el 67% posee al menos una vulnerabilidad tipo Cross Site scripting (javascript). Esto es demasiado código y demasiadas vulnerabilidades.

Funcionamiento de un ataque Cross site

Para complicar aún más el panorama podemos decir que la mayoría de aplicaciones en uso no se suelen revisar frecuentemente para comprobar sus peligros de seguridad -en parte porque muchas de ellas empiezan a ser antiguas y no entran en el calendario de actualizaciones habituales.

“Suele ser frecuente que sólo las aplicaciones de alto nivel sean actualizadas”, según Scott Parcel, CTO de Cenzic. Añade además que todas las empresas deberían poner más recursos en monitorizar periódicamente sus aplicaciones en busca de errores de código.

Otras categorías

Al margen de las mayores vulnerabilidades Web, descendiendo en la lista encontraremos: referencias directas a objetos, malas configuraciones de seguridad, exposición de datos sensibles, descuidos en las funciones de Control de Nivel de acceso, peticiones cross-site falsificadas, empleo de vulnerabilidades conocidas en componentes o redirecciones inválidas.

La lista no ha cambiado mucho desde 2010, aunque algunos aspectos se han combinado o han ganado relevancia. La categoría más reciente (empleo de componentes vulnerables) es un hallazgo importante en la lista, ya que pone de manifiesto que las vulnerabilidades en software no son introducidas únicamente por el propio desarrollador (fallo de programación) sino también por las librerías y otros componentes que ellos deciden integrar en los sistemas. Si solo nos limitamos a reparar nuestro propio código, estamos olvidando una parte importante del problema.

Compartir.

Sobre el Autor

Alejandro es técnico micro-informático, experto en seguridad de las TIC y apasionado de la tecnología. Colabora habitualmente en diferentes publicaciones de seguridad, software y análisis de hardware entusiasta.

Dejar una Respuesta

Uso de cookies

Este sitio web utiliza cookies para que usted tenga la mejor experiencia de usuario. Si continúa navegando está dando su consentimiento para la aceptación de las mencionadas cookies y la aceptación de nuestra política de cookies, pinche el enlace para mayor información.

ACEPTAR