Leer correctamente los datos provenientes del Request

Un "error" muy común de los programadores web en cuanto a la seguridad de sus aplicaciones, es acceder directamente a las variables enviadas desde las solicitudes recibidas desde la colección genéricas Request, como la clase "Request" en ASP o la variable $_REQUEST en PHP:

En ASP:
String nombre = Request["name"];

En PHP:
$nombre = $_REQUEST['name'];

Si bien esta forma de hacerlo es "correcta" lingüisticamente hablando, es bueno recordar que las variables de input tradicionales de una solicitud web suelen llegar por tres diferentes vías: por el método GET, el método POST o a través de cookies. Cuando usamos la clase Request o la variable $_REQUEST según el caso del lenguaje (ASP o PHP) estamos solicitando información en una colección genérica que agrupa las tres opciones (y otras más), y si bien es mucho más fácil y limpio de usar, este método infiere en el error por omisión, de admitir que un dato específico llegue a nuestras páginas por cualquiera de los tres métodos.

El hacker entonces podría perfectamente modificar el valor de un cookie introduciéndolo desde el URL, podría también modificar valores de un formulario que viaja por POST atacándolo desde un simple enlace enviado por e-mail. Esto se debe a que nuestra aplicación al solicitar los datos no diferencia por cual de los tres métodos están siendo enviados. Las implicaciones de poder infectar los cookies del navegador del usuario a través de un URL pueden ser enormes, pero no vamos a detallar esa práctica en este artículo.

Es imperativo, utilizar el método determinado según el acceso por el que debemos recibir los datos y evitar usar el método genérico Request. Ejemplo:

En ASP:
String nombre = Request.QueryString["name"]; // para el método GET
String nombre = Request.Form["name"]; // para el método POST
String nombre = Request.Cookies["name"]; // 

En PHP:
$nombre = $_GET['name'];
$nombre = $_POST['name'];
$nombre = $_COOKIE['name'];

En el lenguaje JSP (Java Server Pages) el problema es aún más grave debido a que el lenguaje no diferencia con el método Request.getParameter("name") si la solicitud es recibida por POST, GET o es un Cookie. En este caso se recomiendan o bien utilizar el método Request.getMethod(), que nos aclara por donde han llegado los datos, simplemente utilizar la tecnología de servlets que si diferencia entre ambos métodos con doGet(request, response) y doPost(request, response).


Redactado por Mauro Maulini R.

Confiar en que el viewState de una página en Asp.NET está cifrado: ¡Error!

Uno de los errores más comunes de seguridad de los programadores de Asp.NET que utilizan "web forms" en sus aplicaciones, es creer que el "viewState" (ese campo oculto que se puede ver en todas las páginas desarrolladas con "web forms" que contiene un cantidad apreciable de caracteres ilegible) está cifrado.

El viewState es un repositorio de información en el que se apoyan los "web forms" para guardar los datos de los diferentes componentes o áreas de una página entre llamada y llamada al servidor. Incluso es accesible desde el código y podemos guardar información allí para usarla en de forma eficiente en nuestras páginas por ejemplo:

ViewState["password"] = thepassword;

Pero no es una buena práctica colocar información sensible como un password en dicho repositorio, debido a que la creencia de que el viewState está cifrado es completamente errónea. El viewState no es cifrado entre viaje y viaje al servidor sino codificado. Si usted conoce algo de criptografía entenderá que la diferencia entre cifrar y codificar es muy obvia, caso contrario permítame explicarle de forma muy resumida un importante detalle a la hora de proteger sus datos: para descodificar solo es necesario conocer el algoritmo en el cual el texto fue codificado, mientras que pare descifrar es necesario conocer una clave de cifrado además del algoritmo y esta no viaja junto al texto cifrado. 

Por lo anterior entenderá que si sabemos el algoritmo con el que el viewState es codificado, solo tenemos que usarlo en reversa para decodificarlo. Y bien ese algoritmo es el conocido Base64. Compruébelo usted mismo introduciendo el viewState de una página Asp.NET en este decodificador de viewState gratuito en línea: http://ignatu.co.uk/ViewStateDecoder.aspx 

Ante este problema tenemos dos soluciones: 

1. No colocar nunca información delicada en el viewState
2. Cifrar el viewState o cifrar la información que coloquemos en él.

La primera opción no necesita explicación, la segunda si amerita de algo de información adicional. El viewState, desde la versión de Asp.NET 2.0 en adelante también puede ser cifrado. Usted puede decidir hacerlo en absolutamente todo el sitio web colocando el siguiente atributo en la sección <pages> del archivo web.config:

<pages viewStateEncryptionMode="Always">

Sin embargo hay que tomar en cuenta que el cifrado puede reducir la velocidad de respuesta sobretodo si estamos en un sitio de alto consumo, por lo que podemos también utilizar el cifrado del viewState a nivel de cada página colocando el siguiente atributo en la cabecera <% @ Page >

<% @ Page Language="C#" AutoEventWireup="true" CodeBehind="login1.aspx.cs" ViewStateEncryptionMode="Always" %>

Espero que este truco e información sean de utilidad para los desarrolladores en Asp.NET.

OWASP Dirbuster - Escaneando directorios y archivos ocultos de una aplicación web

Uno de los problemas más comunes a la hora de programar es la creencia de que una página o directorio al que no lleva ningún enlace, jamás serán vistos. Pues si esto fuera cierto, lo sería solo en parte, y esa parte dependería de la facultad del programador de escoger nombres complejos y difíciles de adivinar por los expertos en seguridad y por supuesto los atacantes.

La idea de este artículo, es la de encarar al programador con herramientas capacitadas para descubrir la mayor parte del árbol de directorios de nuestra aplicación así como muchas de las rutinas y páginas de esta, por el simple motivo de que todos los programadores usamos casi las mismas herramientas, venimos de una misma corriente de pensamiento o leemos los mismos artículos y vemos las mismas películas y libros. En pocas palabras que debido a que usamos Macromedia Dreamweaver o Visual Studio, nombramos los directorios y archivos de una forma específica.

Este tipo de herramientas trabajan con diccionarios de nombres de archivos y directorios (en varios idiomas) los cuales se prueban solos o con extensiones comunes. Por ejemplo, este tipo de aplicaciones no tardaría prácticamente nada en descubrir un archivo cuyo nombre fuera "admin.zip" en donde un programador incauto podría haber dejado copia de respaldo de todas las rutinas del backoffice de su aplicación. Ejemplos como este hay muchos y algunos espeluznantes, ya que los aciertos no necesariamente son tan sencillos de imaginar como el anterior.

En fin, la intención es que ustedes mismos puedan descubrir cuan vulnerables son esas rutinas administrativas que damos por ocultas o inalcanzables desde la web, y para ello no hay mejor maestro que la experiencia. Y precisamente para que podamos experimentar con nuestras aplicaciones web,  OWASP (quien más podría ser) ha puesto uno de sus proyectos  de seguridad al alcance de todos, y en este caso se trata específicamente del Proyecto "Dirbuster". Disbuster (según palabras de sus creadores) es una aplicación Java multi hilo diseñada para obtener por fuerza bruta los nombres de directorios y archivos en servidores de aplicaciones web.

Puede descargarla en formato comprimido zip en este enlace.

Recuerde, Dirbuster no es más que una aplicación eficiente que nos muestra las posibles fallas de seguridad en la forma en que nombramos nuestras rutinas y directorios, pero cualquier herramienta de análisis de vulnerabilidades seria cuenta con rutinas para el mismo fin y algunas veces suelen ser muy superiores a esta.

Ejecute Dirbuster sobre su aplicación web de forma local, para evitar demoras por problemas de ancho de banda o bloqueo de firewalls, y verá como su forma de nombrar sus archivos y directorios cambiará para siempre.

Hasta la próxima...

Decálogo de Principios de Seguridad para Desarrollo de Aplicaciones Web

Independientemente del lenguaje y/o plataforma de desarrollo que usted utilice, hay cosas que de una o de otra forma siempre hay que tomar en cuenta si queremos tener una aplicación web "relativamente" segura. Además acoto la palabra "relativamente", porque en primer orden nunca se puede obtener una aplicación 100% segura. Dice un chiste de seguridad que la única aplicación segura es la que está desconectada del cualquier red, no se ejecuta y se introduce en un "bunker antiaéreo" sellado a 50 metros de profundidad y aún así nadie apostaría un ojo asegurando la integridad de la misma.

Por lo tanto el presente artículo, tiene como fin el poner al lector al tanto de una serie de principios de seguridad que debería seguir en el proceso de desarrollo si realmente desea obtener un resultado favorable en lo referente a este tema.

• Defensa en profundidad.
  Nunca confíe en un solo punto de defensa. Su aplicación en la mayoría de los casos será siempre la última línea de defensa entre el atacante y servidores del entorno de redes corporativas. Por tanto usted debe proveerle a su aplicación más de un método de defensa si desea proteger servidores de bases de datos e información sensible de la empresa.
  
• Nunca confíe en las entradas de datos.
  Como usted podrá descubrir mediante un simple ejemplo de XSS o SQL injection, la mayoría de los problemas empiezan por creer que la validación del lado cliente en Javascript puede ser suficiente, suponer que la única forma de solicitar un tipo de datos es un formulario u olvidar validar que los datos no excedan la capacidad de un contenedor. En las aplicaciones web los datos pueden venir de cualquier parte, pueden ser y muchas veces son forjados, y su aplicación debe tener la capacidad de responder ante este hecho.
  
• Controle los errores elegantemente.
  Aunque usted haya pensado en todo, siempre algo nuevo puede suceder para lo que la aplicación podría no estar preparada. Controle las respuestas de error y trate de no entregar en ellas información que pudiera ayudar al atacante a descubrir datos acerca de como está hecha o funcionan los procedimientos de la misma. Utilice siempre que sea posible controles de error (try - catch) para que su aplicación no muestre la típica página de error 500. Una simple página de error 403 (acceso denegado) puede decirle a un escaner de vulnerabilidades que un directorio sacado de un diccionario existe, y permitirle montar un aproximado de su la estructura de directorios por ensayo y error.
  
• Esté atento a los ataques.
  Inclusive si usted maneja los errores elegantemente, usted pudiera no estar guardando en bitácora (log) cuáles son las causas de dichos errores. Hacerlo le permitirá corregirlos sin esperar que un usuario se los reporte y además podrá verificar si la aplicación está siendo o ha sido atacada y lo mejor de todo, podrá verificar cómo está siendo atacada.
  
• Use los menores privilegios posibles.
  Posiblemente a la hora de desarrollar la aplicación usted no tenga inconvenientes en utilizar una cuenta de administrador de su servidor de bases de datos, pero dejar esa información de conexión administrativa para una aplicación que probablemente solo ejecute procesos que pudieran perfectamente asociarse a una cuenta con muchos menos privilegios, es una falla que puede costar cara si el atacante logra obtener acceso a algún archivo de configuración. Lo mismo sucede con la permisología de escritura y ejecución en directorios. Si solo necesita subir archivos a un directorio una vez, no tiene sentido dejar los privilegios de escritura de forma permanente. Use siempre los menores privilegios posibles para su aplicación.
  
• Los Cortafuegos (Firewalls) y la Criptografía no son una panacea.
  Es muy fácil creer que por que algo está cifrado no podrá ser accedido, o que porque tenemos un firewall el atacante no podrá tener acceso al sistema. Ninguno de los anteriores es cierto. Los firewalls deben permitir el acceso al puerto en el que se desempeña su aplicación (típicamente el puerto 80 y el 443) y una sentencia SQL a través de un campo mal validado no puede ser bloqueada por este medio.
  Lo mismo sucede con la cryptografía, hace años se consideraba muy seguro un hash MD5 o SHA1, hoy en día los ataques por diccionario y tablas de arcoiris nos hacen pensar en nuevos métodos y trucos de cifrado que antes no eran necesarios. El ancho de banda y la velocidad de procesamiento hacen posibles ataques por fuerza bruta que tiempo atrás eran impensables.
  
• La Seguridad debe ser el estatus por defecto.
  Es muy fácil instalar un servicio, hardware o aplicación y dejar los atributos por defecto que vienen habilitados desde la casa matriz. Un ejemplo de esto es la cara lección que tuvo que aprender Microsoft por el caso del SQL Slammer, que atacaba el el servicio de SQL Browser que venía activo por defecto en todos los paquetes de SQL Server, cuando en realidad la gran mayoría de usuarios no lo necesitaba. Revise bien los atributos por defecto de sus instalaciones y no deje servicios activos que no necesita. Usted reducirá así la superficie de ataque y con ello el riesgo de uno.
  
• El Documento OWASP Top 10
  OWASP desarrolló una lista de los 10 grupos de vulnerabilidades más comunes en orden de importancia. También creó ejemplos explicativos de las mismas y de cómo proteger a su aplicación  de dichas fallas o vulnerabilidades. Usted no puede dejar de leer este documento y de aplicar esta lista en el rastreo de los posibles errores de seguridad en su desarrollo. También puede acceder a una traducción hecha por mi persona de la lista en este enlace.
  
• Manténgase un paso adelante
  Su aplicación si bien puede haber sido realizada con todo lo anterior en mente por su propia naturaleza será expuesta a todo el mundo. Internet no es una capsula, nada más lejos de eso. Su aplicación estará disponible a todos los posibles atacantes mediante una simple consulta en un buscador. Google Hacking Database es un ejemplo de cómo obtener listados de posibles aplicaciones víctimas mediante el uso de búsquedas avanzadas en Google. Por tanto usted debe estar al tanto de cualquier tipo de vulnerabilidad descubierta para poder protegerse de ella antes de que un posible atacante descubra la falla en su sitio.
  
• Mantenga el software de terceros actualizados.
  Su aplicación se basa en software desarrollado por terceros en mayor o menor grado. Usted la coloca en un servidor web (Apache, ISS, Nginx, etc) que a su vez corre en un sistema operativo. También accede a manejadores de bases de datos. Todos estos servicios suelen tener fallas y deben siempre que sea posible ejecutar en sus últimas actualizaciones. Usted también podría utilizar manejadores y componentes de terceros directamente en su aplicación. Este y todo tipo de software de terceros debe estar actualizado siempre que sea posible . Usted se sorprenderá al saber que los atacantes son los primeros en estar registrados en las listas de control de vulnerabilidades para saber cuáles versiones de determinado software son vulnerables a un determinado tipo de ataque.

Todos las anteriores son recomendaciones y principios generales que no dependen del tipo de lenguaje y/o plataforma de desarrollo que utilice. Son prácticamente obligaciones que tiene usted como desarrollador para con su empresa, sus clientes y sus usuarios. Téngalos en cuenta y se ahorrará muchas molestias.

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...

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...

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

Solución: Mayor integración a nivel corporativo de equipos de seguridad y de desarrollo.

En la experiencia adquiridas en el marco de la seguridad de aplicaciones web para empresas como bancos, administradoras y otros tipos de instituciones financieras, me he encontrado con cierta disociación entre los departamentos de desarrollo de aplicaciones (esos locos que no prueban bien lo que hacen) y de seguridad de datos y sistemas (esos gruñones que nunca aprueban lo que desarrollamos a la primera).

Como si fuera ya una tradición, no es nuevo escuchar que los primeros (desarrolladores) se quejan de la cantidad de protocolos de verificación, metodologías de testeo y lentitud o redundancia de los procesos de validación de los sistemas, mientras los segundos (técnicos en seguridad de datos y aplicaciones) lo hacen acerca de la falta de controles en código, rutinas insuficientemente testeadas en desarrollo, "agujeros" de seguridad heredados en código reutilizado, entre muchas otras cosas.

El cambio actual del tipo de plataforma de aplicaciones convencionales o de entorno manejable a una plataforma aún más abierta y peligrosa como el entorno de aplicaciones web cuyos límites y procesos no son fácilmente controlable, no solo ha afianzado la brecha entre estos dos departamentos, sino pareciera crear en algunos casos conflictos infranqueables.

Mi punto de vista es que en la actualidad ambos tipos de departamentos se encuentran en esta encrucijada debido al mantenimiento de políticas de desarrollo y seguridad en ambos lados que poco o nada tienen que ver con la forma en que las aplicaciones web pueden ser y son atacadas actualmente.

He constatado como empresas de cierta magnitud, no tienen políticas adecuadas para solventar los ya no tan nuevos tipos de ataques a aplicaciones web y a sus usuarios, y he visto personalmente como intentan aplicar en ambos bandos procesos ineficientes y absurdos a la hora de minimizar o anular un ataque (de phishing o pharming por ejemplo). Y por último he visto también como ambos bandos culpan al otro cada vez que se encuentran en este tipo de conflictos.

Desde una mirada exterior experimentada, puedo asegurar que el problema no pertenece a ninguno y a los dos bandos simultáneamente. Las razones son las siguientes:

• Los protocolos de seguridad actuales no permiten responder con la celeridad necesaria ante ataques al entorno de aplicaciones web. Este tipo de ataques son en su gran mayoría del tipo masivo (phishing, pharming, DDoS, XSS). Son ataques que por sus características, una vez implantados y procesados atacan a un amplio espectro de los usuarios y no a uno o dos. Minutos perdidos son cantidades de dinero que no vuelven, y los protocolos de seguridad convencionales pueden llegar a estorbar más que a ayudar en estos casos.
• Los desarrolladores y expertos en seguridad, en tiempos anteriores jamás tuvieron que preocuparse por la seguridad de un usuario que se encuentra ante su computador en su propia casa. Este es un concepto radicalmente nuevo para ellos, al punto que por ejemplo los ataques de phishing hasta hace poco eran considerados problema del usuario y no de la empresa.
• Ambos equipos jamás tuvieron que validar aplicaciones y las interfaces de estas que funcionan simultáneamente en todos los sistemas operativos, bajo al menos una decena de navegadores web diferentes y una miríada de configuraciones diferentes.
• Ambos equipos jamás pensaron o se imaginaron que sus aplicaciones podrían ser atacadas desde zonas que hasta el momento eran completamente irrelevantes. A nadie le importaba lo que pudiera hacer un hacker en países como Rusia, China y otros que quizás nunca habían escuchado nombrar.
  

En fin, lo que trato de exponer es que definitivamente la seguridad nunca y mucho menos ahora ha sido un problema interdepartamental. Las empresas necesitan técnicos que manejen ambas áreas de forma actualizada y eficiente y reconduzcan al personal existente a una nueva forma de observar los procesos de desarrollo así como los procesos de validación y testeo.

El enemigo además de ser un enemigo oculto, no es enemigo de un solo departamento. Es un enemigo común que posee tecnología sofisticada que puede obtenerse de forma cada vez más simple, por lo cual su capacidad de ataque se multiplica exponencialmente con el tiempo. 

El trabajo de seguridad (y no hablo solo de aplicaciones web) actualmente debe ser definitivamente compartido. Se necesitan desarrolladores en capacidad de entender los nuevos modelos de seguridad y tipos de vulnerabilidades para ser capaces de prevenirlas en código, así como expertos de seguridad en capacidad de comprobar la existencia de este tipo de vulnerabilidades y de crear procesos dinámicos de validación pero jamás sacerdotes que promulguen tablas de leyes bíblicas inamovibles.

Por otra parte las empresas deben canalizar sus presupuestos de seguridad e invertir más en actualizar su personal en seguridad de aplicaciones web, y proveerlos de mejores herramientas de control y desarrollo para tal fin. Así como pretenden que una gran cantidad de usuarios utilice las nuevas y más económicas tecnologías, deben entender que dicha pretensión conlleva un riesgo mayor y por ende un presupuesto mayor en respaldo de las mismas.

El enemigo actual solo puede ser combatido desde una perspectiva que no es nueva ni mucho menos innovadora, pero que tiende a ser olvidada en el día a día y enterrada por los procesos. Esa perspectiva no es más que la de un verdadero trabajo de equipo por un fin común.

Hasta la próxima...