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

OWASP Top 10 Mobile Security Risks

Nuevamente OWASP pone a disposición de los programadores interesados en desarrollar código seguro (debiéramos ser todos, pero tristemente no es así) un proyecto interesante, pero esta vez haciendo énfasis en la programación de aplicaciones móviles. Este proyecto no es más que el OWASP Mobile Security Project, que al igual que el Web Application Security Proyect ofrece una serie de utilidades, consejos y material didáctico muy interesante. 

Dentro de los recursos que ofrece sin fines de lucro este proyecto, no podía faltar la lista de los 10 riesgos más importantes a tomar en cuenta por los programadores al desarrollar aplicaciones para plataforma móviles.

Estos riesgos según OWASP son los siguientes:

• M1: Insecure Data Storage - Almacenamiento de datos inseguro
• M2: Weak Server Side Controls - Controles del lado del servidor débiles
• M3: Insufficient Transport Layer Protection - Insuficiente Protección en la Capa de Transporte
• M4: Client Side Injection - Inyección del lado cliente
• M5: Poor Authorization and Authentication - Autorización y Autentificación Pobres
• M6: Improper Session Handling - Manejo indebido de sesión
• M7: Security Decisions Via Untrusted Inputs - Desiciones de seguridad a trávés de entradas no confiables
• M8: Side Channel Data Leakage - Pérdida de datos por canales laterales
• M9: Broken Cryptography - Criptografía Rota
• M10: Sensitive Information Disclosure - Divulgación de información confidencial

Es una lista muy interesante que todo programador de aplicaciones móviles debiera conocer independientemente de a plataforma para la cual desarrolle. La lista fue publicada en Junio 2013, y como es lógico todos estos puntos forman parte también del curso de Seguridad de Aplicaciones Web y Móviles.

Cómo implementar el encabezado HTTP Strict Transport Security en código

Si el video de OWASP del anterior post sobre HSTS (HTTP Strict Transport Security) los dejó con algo de espectativas acerca de la implementación del encabezado de HTTP para el uso estricto de HTTPS, entonces lo que viene a continuación les interesa.

Si bien se puede implementar el encabezado a nivel de servicio web agregando en la configuración de las diferentes plataformas (Apache, IIS, nginx y otros) un "header", a veces es mucho más práctico agregar la cabecera directamente a nivel de aplicación o en las rutinas específicamente sensibles.

Cómo el vídeo no nos muestra el código para ello a continuación algunos ejemplos en diferentes lenguajes y/o plataformas:

Implementación en PHP.

// Usar HTTP Strict Transport Security para forzar al cliente a usar 
// conexiones seguras

$use_sts = true;
 
// iis sets HTTPS to 'off' for non-SSL requests
if ($use_sts && isset($_SERVER['HTTPS']) && $_SERVER['HTTPS'] != 'off') {
    header('Strict-Transport-Security: max-age=31536000');
} elseif ($use_sts) {
    header('Location: https://'.$_SERVER['HTTP_HOST'].$_SERVER['REQUEST_URI'], true, 301);
    // we are in cleartext at the moment, prevent further execution and output
    die();
}  

Implementación en Perl CGI.

# Usar HTTP Strict Transport Security para forzar al cliente a usar
# conexiones seguras

use CGI;
use URI;
 
my $q   = new CGI;
my $url = URI->new($cgi->request_uri)
my $use_sts = 1;
 
if ($use_sts and $url->scheme eq 'https') {
    print $q->header('Strict-Transport-Security' => 'max-age=31536000'); 
} elsif ($use_sts) {
    $url->scheme('https');
    print $q->redirect(status => 301, location => $url);
}  

Implementación en Ruby on Rails.

class ApplicationController < ActionController::Base
  before_filter :ensure_proper_protocol
 
private
  def ensure_proper_protocol
    if request.ssl?
      response.headers['Strict-Transport-Security'] = 'max-age=31536000'
    else
      redirect_to "https://" + request.host + request.request_uri, :status => 301
    end
  end
end  

Implementación en C# / ASP.NET. Código en archivo global.asax

// Usar HTTP Strict Transport Security para forzar al cliente a usar 
// conexiones seguras
protected void Application_BeginRequest()
{
    switch (Request.Url.Scheme)
    {
        case "https":
            Response.AddHeader("Strict-Transport-Security", "max-age=31536000");
            break;
        case "http":
            var path = "https://" + Request.Url.Host + Request.Url.PathAndQuery;
            Response.Status = "301 Moved Permanently";
            Response.AddHeader("Location", path);
            break;
    }
}  

Implementación en ColdFusion Markup Language (CFML).

<!--- Usar HTTP Strict Transport Security para forzar al cliente a usar
conexiones seguras --->

<cfset use_sts = true>
 
<cfif use_sts is "True">
    <cfif cgi.https is "on"> 
        <cfheader name="Strict-Transport-Security" value="max-age=31536000">
    <cfelse> 
        <cfheader statuscode="301" statustext="Moved permanently">
        <cfheader name="Location" value="https://" + CGI.SERVER_NAME + CGI.SCRIPT_NAME + CGI.QUERY_STRING>
    </cfif>
</cfif>  

Implementación en JavaServer Pages (JSP) o Java Servlets.

// Usar HTTP Strict Transport Security para forzar al cliente a usar 
// conexiones seguras
boolean use_sts = true;
 
if(use_sts) {
    if(request.getScheme().equals("https")) {
        // Send HSTS header
        response.setHeader("Strict-Transport-Security", "max-age=31536000; includeSubdomains");
    } else {
        // Redirect to HTTPS
        response.setStatus(301);
        String url = "https://" + request.getServerName();
        if(request.getPathInfo() != null) {
            url = url + "/" + request.getPathInfo();
        }
        if(request.getQueryString() != null && request.getQueryString().length() > 0) {
            url = url + "?" + request.getQueryString();
        }
        response.setHeader("Location", url);
    }
}

Espero les sea suficientemente útil y como podrán apreciar no es nada complicado.

Comenzando con Seguridad para ASP.NET

Recientemente llegó a mis manos un libro muy interesante llamado "Beginnig ASP.NET Security" de la serie de libros de WROX Programmer to Programmer, que no puedo dudar ni por un segundo en recomendarles en este artículo.

A pesar de ser un libro para programadores, su lenguaje es bastante claro en los primeros capítulos para que cualquier programador de la excelente plataforma de desarrollo web de Microsoft, pueda entender sin inconvenientes todos los "intrigulis" de la seguridad web.

En este libro encontrará, como proteger sus aplicaciones en ASP.NET basándose en el documento OWASP TOP 10, que es el documento creado por la Open Web Application Security Proyect para implantar un estándar de referencia acerca de los 10 tipos más comunes de vulnerabilidades detectadas en aplicaciones web. Por tanto el libro toca cada una de las anteriores y muestra las diferentes formas de proteger las aplicaciones, y además permite seguir paso a paso los métodos de cifrado mas eficientes utilizándolos desde la plataforma .NET para proteger los datos de nuestros usuarios.

También maneja un amplio capítulo acerca de la seguridad en el IIS (Internet Information Server) que es la plataforma de servicios con la que se ofrece lógicamente ASP.NET (entre otros). Además uno de sus más extensos capítulos está dedicado a la seguridad de Web Services, bajo WCF (Windows Communication Foundation) a través de RIA, SOAP y otros protocolos de servicios web. Por último ofrece todo un capítulo que explica como adaptar los procesos de seguridad básicos al ASP.NET MVC (Model View Controller).

El libro está actualizado a la plataforma de ASP.NET 4, pero sus capítulos están adaptados para ser utilizados en versiones anteriores.

Es mi recomendación que este libro se convierta en una referencia de seguridad obligada para todo proyecto en ASP.NET.

Hasta al Próxima...

OWASP Appsec Serie de Tutoriales - Episodio 3: Cross Site Scripting (XSS)

Ya acaba de ser publicado el tercer episodio de OWASP Appsec Tutorial Series que trata específicamente acerca de XSS o mejor conocido como Cross Site Scripting. No dejes de verlo es muy interesante y sencillo de entender.



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

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

Nuevo tipo de DoS: HTTP POST Denial of Service.

Un nuevo tiepo de ataque de DoS fue presentado en la Black Hat DC Security Conference por dos desarrolladores de Truswave y SpiderLabs. Se trata de lo que podría denominarse Ataque de DoS en la séptima capa del modelo OSI.

Mientras la mayoría de los ataques de DoS actuan en la cuarta capa del modelo OSI, específicamente sobre protocolos de identificación y comunicación, otros recursos de ataque se basan en atacar al protocolo de la aplicación (Octava capa OSI), ya hemos mencionado muchas razones por las cuales una falla o un uso inocente de los recursos pueden generar que un ataque de DoS de este tipo pueda causar efectos impredecibles y aunque la mayoría de los ataques pueden solventarse manejando la forma en que la aplicación accede a los recursos y liberándolos eficientemente, en el caso que vamos a estudiar mitigar el ataque es mucho más difícil.

Sin embargo el ataque del que queremos hablar se coloca una capa más arriba. Se trata específicamente del HTTP POST DoS.  La idea principal del ataque es la de solicitar conexiones con el servidor web (HTTP) y una vez realizado el "handshake" enviar datos de solicitud a una velocidad muy baja, de forma que el servidor se vea obligado a mantener la comunicación abierta esperando que se complete la solicitud (request). Si al mismo tiempo se abren cantidades de conexiones simultáneas con el mismo propósito, se llegará a obstruir las comunicaciones con el servidor ya que este en algún momento podría quedar sin recursos de comunicación disponibles.

Tom Brennan director de Trustware, involucrado también con  OWASP (Open Web Application Security Project) desarrolló una herramienta de Pen-Testing para ayudar a los programadores a conocer si sus servidores están en capacidad de soportar este tipo de ataque y por supuesto resolver las fallas que pudieran dar cabida al mismo. La herramienta forma parte de uno de los proyectos de OWASP llamado HTTP POST Tool y pueden encontrarla en este enlace.

A diferencia de los ataques generados por métodos que atacan la cuarta capa del modelo OSI, o ataques directos a la aplicación, este tipo de ataques de la séptima capa OSI son más difíciles de limitar ya que no dependen directamente del protocolo de red. Por otro lado son muy fáciles de crear. El siguiente ejemplo de un simple archivo bash es concluyente:

Mitigar este tipo de ataques es mucho más complejo, ya que no dependen ni del protocolo de comunicación ni de la aplicación. Para cada servidor (IIS, Apache, Nginx...) y versión existen soluciones diferentes que iremos analizando en futuros artículos. 

Hasta la próxima...

Limitaciones de los Escaners de Vulnerabilidades para Aplicaciones Web.

Un típico error de las empresas con sus propios equipos de desarrollo o las empresas de desarrollo específicamente, es la tendencia a creer que las aplicaciones web pueden ser convertidas en fortalezas impenetrables con un simple Pen-testing realizado mediante el uso de un programa de escaneo de vulnerabilidades especializado para la web.

Existen muchos de estos programas en formatos diferentes y  la intención de estos (al menos la mayoría) es ayudar al experto en seguridad a realizar una serie de pruebas que permitirán conseguir vulnerabilidades para pasar de inmediato a corregirlas. Sin embargo estos programas, tienen muchas limitaciones:

• Debido a la gran cantidad de vulnerabilidades posibles, y a sus cientos de variantes toman horas en realizar un análisis exhaustivo de la aplicación web, consumen una gran cantidad de recursos y someten a la misma a un "stress" indebido para entornos de producción. Aunque la práctica recomienda tener un entornos independientes de desarrollo y control de calidad, en muchos casos estos no existen.
• Cualquiera que los haya utilizado sabe que producen una gran cantidad de "falsos negativos" y "falsos positivos".
• Necesitan de constante actualización, cada día se descubren nuevas formas de penetrar aplicaciones y por tanto nuevas vulnerabilidades afloran.
• Producen un falso sentido de seguridad web.
• Normalmente no explican la razón por la cual se considera una vulnerabilidad como tal, y menos aún dan al programador y su equipo tips para corregirla, por lo que las vulnerabilidades tienden a quedar sin arreglo.

Programas como Acunetix, W3af, Netsparker, N-Stalker, Burp y otros, si bien han conseguido convertirse en excelentes herramientas, dependen en mayor o menor grado para desempeñar su trabajo de forma exitosa de los conocimientos de un experto en seguridad web.

En un estudio realizado por David Shelly, Randy Marchany, Joseph Tront  - Closing the Gap: Analyzing the Limitations of Web Application Vulnerability Scanners - que fue presentado en el evento OWASP AppSec DC 2010, utilizando una aplicación en la que se implementaron una serie de vulnerabilidades premeditamente, demostraron  que 6 diferentes escaners de vulnerabilidades detectaron entre todos de la serie de vulnerabilidades implantadas los siguientes porcentajes:

• 59.7% de las vulnerabilidades de SQL Injection por formulario. 
• 6.3% de las vulnerabilidades de SQL Injection por Cookies
• 43.3% de las vulnerabilidades por Reflected XSS
• 11.1% de las vulnerabilidades por Stored XSS
• 0% de las vulnerabilidades por DOM based XSS
• 20% de las vulnerabilidades de Predictable SID en manejo de Sesión.
• 4.4% de variables de Sesión Inseguras por Cookies.

Para obtener los falsos negativos simplemente hay que restar el porcentaje al 100%. Lo anterior significa que usted tendría que escanear su aplicación con 6 diferentes herramientas y seguiría teniendo un nivel muy alto de vulnerabilidades latentes, inclusive en algunos casos todas ellas seguirían sin detectarse.

Por otro lado el estudio demostró, que las diferentes herramientas utilizadas arrojaron las siguientes cantidades de falsos positivos:

• 12% en SQL Injection.
• 13.9% en XSS

Entonces: ¿Son acaso como los malos periodistas? ¡Solo dicen una parte de lo que hay e inventan otra parte de lo que dicen!

Esto no significa que los escaners de vulnerabilidades para aplicaciones web no sean útiles, claro que lo son y mucho, pero lo son solamente en manos de personal especializado que tenga la capacidad de dicernir entre la realidad y lo que reportan. Si el personal que los va a utilizar no tiene bases sólidas de Seguridad de Aplicaciones Web no podrá obtener de ellos una gran parte lo que pueden ofrecer. En definitiva, son las herramientas de pen-testing que nos dan indicios sobre "como abrir la lata" pero hacerlo y obtener su contenido son asuntos más complejos.

OWASP ESAPI - Enterprise Security API

Uno de los proyectos más interesantes de OWASP en referencia a la generación de código web seguro, es precisamente el que se denomina ESAPI o Enterprise Security API. Se trata de una librería de código que meneja objetos y métodos que permiten validaciones y controles eficientes para evitar XSS, CSRF y muchos otros tipos de ataques web.

OWASP ESAPI tiene puertos para la mayoría de entornos y lenguajes de programación web como por ejemplo ASP.NET, Java, PHP, ColdFusion, Javascript, Ruby y Python entre otros.

Entre algunas de las empresas y organizaciones que han empezado a adoptar ESAPI como plataforma de seguridad para aplicaciones web están American Express, Banco Mundial, US Navy y muchas más.

La librería incluye extensiones y utilidades que permiten homogeneizar el tratamiento de los procesos de seguridad para aplicaciones web, y documentación variada en formato "chm". Sin embargo una serie de artículos muy interesantes de John Melton, denominados "The OWASP Top Ten and ESAPI", nos podrán guiar de forma eficiente acerca de los diez tipos de vulnerabilidades más frecuentes según OWASP y cómo defenderse de estas usando ESAPI. Los ejemplos están en Java pero las clases, métodos y propiedades son básicamente los mismos para todos los lenguajes.

Espero que les sea de ayuda para homologar los procedimientos de seguridad y desarrollar alicaciones web mucho más seguras.

Hasta la próxima...

OWASP Cheat Sheets Series - Hojas de Trucos de OWASP

A veces es necesario tener a mano soluciones rápidas y eficientes para evitar tener que releer todo un libro buscando aquel truco que sabemos que hemos leído pero que no recordamos a perfección como era  o dónde fué exactamente que lo leímos. Por otro lado si bien "googlear" es a veces la solución más rápida, tratándose de prevención y seguridad pudieran existir diferentes "soluciones" o puntos de vista, y tratando se escoger las apropiadas podríamos perder un tiempo preciado.

Cuando se trata de seguridad de aplicaciones, tener a mano una lista de trucos eficientes que nos ayuden a prevenir ataques a la hora de generar código o plantear soluciones integradas de protección puede ser una ayuda invaluable.

Pensando precisamente en lo anterior, la gente de OWASP ha creado las listas u hojas de trucos o "cheat sheets", para tener a mano de forma rápida la información de seguridad necesaria para aplicar las técnicas correctas cuando estemos ensamblando y programando las rutinas esenciales de nuestras aplicación.

Estas hojas de trucos  o "cheat sheets" son varias, y a continuación les muestro los enlaces de las más conocidas y útile a mi parecer:

• Authentication Cheat Sheet
• Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet
• Cryptographic Storage Cheat Sheet
• SQL Injection Prevention Cheat Sheet
• Transport Layer Protection Cheat Sheet
• XSS (Cross Site Scripting) Prevention Cheat Sheet

Sin duda como podrán apreciar al leerlas son documentos eficiente que van directo al grano en lo referente a explicar los procesos de los tipos de ataque pero sobretodo en lo que se refiere a las técnicas de prevención necesarias a la hora de ensamblar y crear código. Espero que les sean de utilidad.

Hasta la próxima...

OWASP - Checklist de Prácticas de Código Seguro

Un documento muy importante creado por OWASP es el que se refiere a cómo ser programadores "seguros", aclarando específicamente una por una las prácticas que debemos seguir cuando generamos código para aplicaciones web. Este documento es precisamente la Guía de Desarrolo Seguro de OWASP.

Espero que tengan tiempo para leer esos documentos tan importantes que tocan a fondo temas actualizados referentes a seguridad web, pero quizás pensando precisamente en que no todos los programadores tenemos el tiempo necesario para ello OWASP ha redactado un checklist de prácticas de código seguro que puede descargar en este enlace.

Sin embargo si es de aquellas personas que cree que mediante ayuda visual puede mejorar su captación entonces el siguiente video grabado en OWASP AppSec USA 2010 le será de gran ayuda para comprender los temas y la terminología de seguridad web involucrada.

Keith Turpin: The Secure Coding Practices Quick Reference Guide

from AppSec USA 2010 on Vimeo.

Hasta la próxima!

Tipos de ataques de DoS basados en fallas de la aplicación.

Cuando hablamos de DoS y DDoS podemos referirnos a muchos tipos diferentes de ataque que en definitiva lo que buscan es obligar al servidor a dejar de ofrecer el servicio. Sin embargo desde el punto de vista de la seguridad de aplicaciones web hay ciertos tipos de DoS (los más comunes) en los que no entraremos en explicaciones ya que no atacan directamente a la aplicación sino a los diferentes servicios necesarios para que esta pueda seguir en línea. Este tipo de ataques se denominan "Network based DoS Attacks" o Ataques de Dos basados en Redes y tratan primordialmente de explotar vulnerabilidades o limitaciones de los protocolos de red de las diferentes capas del protocolo TCP/IP.

Hablaremos hoy de un tipo de ataque de DoS que como programadores nos conciernen directamente y que se apoyan en fallas o vulnerabilidades de la aplicación. Aunque menos populares dichos ataques, son mucho más eficientes, ya que basados en vulnerabilidades en código de aplicación o de base de datos, suelen en muchos menos intentos consumir los recursos del servidor de forma muy eficaz.

Podemos dividirlos según OWASP en los siguientes:
NOTA: todos los enlaces llevan a la página correspondiente de OWASP en la que se trata acerca de cómo verificar y corregir el tipo de fallo que pudiera ocasionar estos tipos de ataque.

1. SQL Wildcard Attacks.
   Son aquellos que se basan en desarrollar consultas que consumen gran cantidad de recursos del servidor SQL y aunque atacan a varios tipos de servidor SQL suelen preferir el MS-SQL por la cantidad de "wilcards" disponibles en las sentencias LIKE.
2. DoS Locking Customer Accounts.
   Uno de los sistemas de defensa de las aplicaciones con validación de usuarios es la utilización de bloqueo de estos luego de una cantidad de intentos fallidos. Este mecanismo de defensa se convierte en un arma de negación de servicio bajo este tipo de ataque.
3. DoS Buffer Overflows.
   La intención es hacer que una vulnerabilidad de Buffer Overflow en el control de la capacidad de los datos recibidos, se convierta en un arma que no permita que las rutinas completen y por ende liberen los recursos solicitados.
4. DoS User Specified Object Allocation.
   Suele suceder cuando un usuario tiene la capacidad de solicitar multiples copias de un objeto a ser creado en el entorno del servidor sin un límite superior, lo que podría generar que dicho entorno quedara sin memoria disponible.
5. User Input as a Loop Counter.
   Se produce al forzar a la aplicación a entrar de forma repetitiva en un bucle de código que consume gran cantidad de recursos.
6. Writing User Provided Data to Disk.
   El objeto de este tipo de ataque es obligar al servidor a quedar sin suficiente espacio en disco, bien escribiendo datos provistos por el usuario, o llenado los archivos de logs de forma que crezcan lo suficiente como para acaparar el espacio en disco.
7. DoS Failure to Release Resources.Este ataque se debe a la falla del programador o del entorno de desarrollo en liberar eficientemente los recursos utilizados por la aplicación. Suele suceder con mucha frecuencia especialmente al no liberar conexiones y sets de registros de bases de datos que consumen recursos por encima del promedio de otro tipo de objetos.
8. Storing too Much Data in Session.
   Sucede cuando como el nombre lo indica, se guardan demasiados datos en la sesión del usuario, específicamente si el usuario no es un usuario autentificado, por lo cual el atacante no necesita de mucho esfuerzo para dejar a la aplicación sin recursos en el pool de memoria.

Hasta la próxima...

El entrenamiento en seguridad web y lo que puede hacer por su empresa.

Para los negocios en línea, la seguridad es una parte vital en lo referente a la eficiencia y retorno de inversión de los mismos. Las aplicaciones web son las herramientas principales para las transacciones en línea, promoción de productos y servicios además de ser también las principales en presentar inconvenientes de seguridad que pudieran perjudicar a usted y a sus clientes a través de su aplicación. La capacitación de personal en el área de seguridad de aplicaciones web es definitivamente un valioso activo para las empresas. Proporcionar conocimientos básicos esenciales y la comprensión de las cuestiones de seguridad relacionadas, así como la capacitación práctica necesaria a su personal es actualmente imperativo. Este tipo de capacitación también ayuda al personal a entender y reconocer las posibles fallas de seguridad en sus negocios en tiempo real y por ende a evitar perjucios derivados.

¡Hacer las cosas bien antes desde el principio significa ahorrar dinero! 

La magnitud del riesgo actual es sin exageraciones demasiado alta para obviarla. Según fuentes de la industria, las aplicaciones web representan el 80% de las vulnerabilidades en línea. Su aplicación en línea puede tener cientos de vulnerabilidades latentes y por tanto una evaluación de riesgos al momento de la instalación de la misma es vital para el futuro de sus negocios en línea.

Aquí es donde la seguridad siempre es más eficaz, en la prevención de problemas antes de que sucedan. Pruebas exhaustivas y la comprobación de cada parte de su sistema para detectar las posibles deficiencias es parte primordial de una política preventiva. Los ahorros de costos pueden ser enormes. Infracciones o malas prácticas de seguridad pueden resultar en ataques tanto a las empresas en línea como a sus clientes, incurriendo en pérdidas financieras a veces muy graves. Y para añadir a los gastos, lo que usted no haya resuelto antes deberá resolverlo después, por tanto una política de prevención en el 80% de los casos significa un ahorro sin discusión.

Los problemas de seguridad en sus aplicaciones web son totalmente evitables. La mejor práctica es la prueba rigurosa y sistemática de todas las aplicaciones web antes de salir a la luz o entrer en línea de forma definitiva.

Piense en su aplicación web como en un buen submarino recién terminado: ¿Usted lo sumergiría a 5000 metros de profundidad sin haber hecho anteriormente una serie de pruebas de capacidad? Francamente no lo creo.

Tipos de entrenamiento necesarios:
La seguridad de aplicaciones web puede ser mucho más compleja de lo que parece por tanto existen varios tipos de entrenamiento dependiendo de las áreas en las que se desenvuelva el personal:

• Entrenamiento Básico:
  Es necesario para cualquier personal a cargo de las áreas de negocios en línea conocer los riesgos a los que están expuestos así como ciertos principios fundamentales en cuanto a seguridad de las aplicaciones en línea con las que tienen relación y con las que desempeñan su trabajo cotidiano. La idea es formar una cultura de seguridad en línea sólida que forme parte a su vez de la cultura empresarial.
  
• Entrenamiento Medio:
  Este es el que se brinda específicamente a las personas involucradas en las tomas de decisiones y que inciden en el tipo de aproximación al cliente y por tanto en el formato de las áreas de las aplicaciones en línea. Es importante que este personal esté al tanto de todos tipos de ataques que existen y cómo sus decisiones pudieran influir en que de una u otra forma estos tipos de ataque pudieran ser efectuados. Este entrenamiento debe convertirlos en conocedores de las posibles vulnerabilidades y las consecuencias que estas pudieran tener aunque no sean los encargados de corregirlas.
  
• Entrenamiento Avanzado:
  Definitivamente, es a la hora de producir código y diseñar los procesos de la aplicación cuando se comete la gran parte de los errores que dejan abiertas las puertas a futuras complicaciones. En este tipo de entrenamiento, que es el más largo y especializado el programador o desarrollador deberá reconocer las fallas a nivel de código, pero por supuesto además deberá entender cómo evitarlas. Este entrenamiento tiene dos fases: La primera se encarga de enseñar a detectar, evaluar y evitar las fallas en forma genérica, y la segunda se basa en aquellas fallas específicas que dependen de la plataforma en la cual han sido desarrolladas o se desarrollarán la aplicación o aplicaciones.

Es importante aclarar que todo el aprendizaje debe estar basado en estándares OWASP y WASC, para que de esta forma se le haga entrega al personal de las herramientas necesarias para a su vez transmitir a otros los conocimientos adquiridos y potenciar los conocimientos en seguridad web como parte del capital de conocimientos empresarial.

Hasta la próxima...

OWASP Code Crawler

¿Porqué tenemos que esperar a que se realice sobre nuestra aplicación web un test de penetración, un escaneo de vulnerabilidades o peor aún a que esta sea atacada por una vulnerabilidad no corregida a tiempo?

Lo primero es programar de forma segura, o por lo menos manteniendo una clara visión de las posibles fallas de seguridad que pudieran existir en nuestras aplicaciones. Y cómo ya hemos hablado del tema con anterioridad, así como hemos hablado de las guías de desarrollo OWASP, no voy a aburrirles con el tema.

Es cierto que en muchas ocasiones la revisión de vulnerabilidades en código ante los típicos "deadlines" improrrogables queda relegada a un último plano, sin embargo hoy vamos a hablar de una utilidad que puede ahorrarnos muchas horas en estos casos y por lo menos nos va a permitir ubicar las posibles fallas en nuestro código.

Estoy hablando del OWASP Code Crawler que es una herramienta de depuración de posibles vulnerabilidades en código fuente para código en .NET y J2EE/JAVA. Puedes descargarlo aquí.

Es una aplicación desarrollada en .Net 3.5, que se basa en una maquinaria muy afinada de control de Expresiones regulares, que nos permitirá encontrar errores tradicionales y nos permitirá utilizar herramientas como un calculador DREAD (calculador de riesgo de una condición o amenaza de seguridad).

Hasta la próxima...

Seguridad Web y Google: Gruyere

Es imposible pensar que Google podía faltar a la cita que tiene con todos los programadores a nivel mundial en lo referente a publicar algún tipo de documento para educar a los mismos en el proceso de generación de código seguro.

Pero Google no se conformó con hacer alguno que otro documento, sino creó toda una serie de cursos especializados en seguridad web en lo que se conoce como Google Code University , desarrollando toda una sección de cursos acerca de seguridad web a los que puedes acceder en http://code.google.com/edu/security/index.html

Una aplicación llena de agujeros

Entre estos cursos aparece una muy interesante aplicación llamada Gruyere hecha especialmente para que los programadores puedan aprender cómo son realizados los ataques  las aplicaciones y tomar las medidas pertinentes en su propio código.

Claro, ya se que algunos de ustedes dirán que han utilizado el  proyecto WebGoat de OWASP (Open Wen Application Security Proyect) a la que nos hemos referido en otros artículos pero este caso es algo diferente.

La diferencia primordial entre WebGoat y Gruyere, es que el segundo no necesita ser instalado en un equipo, ya que se puede ejecutar en línea sin necesidad de instalar la aplicación y ponerla en marcha, lo que es para muchos usuarios una ventaja, aunque para otros pudiera ser una limitación. 

La segunda diferencia es que WebGoat está desarrollada en JSP y Java bajo Tomcat, mientras Gruyere está hecha en Python. Esta puede ser una importante diferencia a la hora de tomar una decisión.

Sin embargo en ambos casos el lenguaje en que han sido desarrolladas no es lo importante a menos que quisiéramos ver el código de "como no debemos hacerlo", lo importante es su capacidad de explicarnos paso a paso como los errores o descuidos que comúnmente cometemos a la hora de programar pueden convertirse en nuestro peor enemigo.

Me gustó mucho la forma en que Gruyere explica el procedimiento del XSS en sus varias versiones aunque debo reconocer que WebGoat me pareció más completa y su interfaz es quizás más trabajada (posee incluso un instalador para Windows ). Sin embargo, la capacidad de que la aplicación pueda ser vulnerada directamente en línea le otorga a Gruyere un extra que no posee WebGoat. No se preocupen, la aplicación puede resetearse y además corre en un proceso de "sandbox" que no permite que puedan afectar a otros usuarios mientras ustedes cometen errores y dan sus primeros pasos, ya que cada usuario está ejecutando una copia personal.

Google al igual que OWASP no solo ha desarrollado esta aplicación sino muchas plantillas, presentaciones y otros tipos de material didáctico que valen la pena ser leidos, por lo que les recomiendo que visiten  http://code.google.com/edu/security/index.html y se pongan al tanto con lo que Google tiene que decirnos en cuanto a seguridad web, cuyo equipo seguramente algo de experiencia debe tener en el tema. ¿Cierto? ;)

Hasta la próxima!

Guías de Desarrollo Seguro de OWASP

Las amenazas constantes a las aplicaciones web, el crecimiento de cada vez más veloz de las plataformas desarrolladas en línea y una creciente evolución de lo que se conoce como "Aplicaciones en la Nube" o "Cloud Computing" son razones de peso para pensar en orientar nuestros esfuerzos a ser programadores más "seguros".

Programar de forma segura en la web, amerita una serie de conocimientos acerca de una gran cantidad de vulnerabilidades que pueden ser explotadas por los atacantes y cómo prevenirlas, por lo que si eres programador, diseñador web o estás de alguna manera involucrado con el desarrollo de aplicaciones web, es muy posible que ya hayas enfrentado algún problema de seguridad en alguna de las aplicaciones web que has desarrollado.

Por tanto, es necesario para evitar que nuestras aplicaciones sean fácilmente vulneradas y darle a nuestros clientes la seguridad que necesitan, replantear algunos aspectos acerca de la forma en que vamos a crear dichas aplicaciones de ahora en adelante.

Para mejorar la forma en qué desarrollamos nuestras aplicaciones desde el punto de vista de la seguridad, OWASP ha colocado en línea desde hace ya varios años una guía en varios idiomas destinada al aprendizaje de técnicas de seguridad. 

Ya está en línea la versión de esta guía del 2010 en la dirección: http://code.google.com/p/owasp-development-guide/wiki/Guide. Sin embargo esta versión aun no está disponible en castellano, aunque puedes bajar en formato pdf la versión anterior aquí: http://www.owasp.org/images/b/b2/OWASP_Development_Guide_2.0.1_Spanish.pdf

Como todo lo que desarrolla OWASP, estás guías son completamente gratis.

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.