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