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.

Desarrollo de aplicaciones móviles con frameworks multiplataforma: lo bueno, lo malo, lo feo...

A lo largo de estos últimos dos años hemos visto como en el ámbito de desarrollo de aplicaciones móviles, las herramientas multiplataforma han jugado un papel interesante para muchos programadores abrumados por la cantidad de diferentes lenguajes, APIS y kits de desarrollo propuestos por las diferentes plataformas móviles, quienes queriendo quizás adoptar un estándard se encuentran con que el mismo aún no existe.

Al querer abarcar mayor cantidad de público para sus aplicaciones, los desarrolladores se encuentran con por lo menos tres o cuatro diferentes plataformas, cada una con un sistema operativo, lenguaje de programación y un kit de desarrollo completamente diferente, por lo que en muchos casos en vez de dedicarse al desarrollo de aplicaciones nativas para cada sistema, optan por desarrollar con herramientas multi-plataforma como Apache Cordova/PhoneGap, Appcelerator's Titanium, Sencha Touch y otras.

Aún así no todo lo que brilla es oro, y existe una larga lista de asuntos pendientes por aprobación que hacen de las aplicaciones desarrolladas con esta técnica algo como una especie "secundaria". Indudablemente la opción de desarrollar con esta técnica depende directamente del tipo de aplicación a desarrollar y del propósito específico de cada equipo de desarrollo.

Los pros del desarrollo multi-plataforma de aplicaciones móviles pueden resumirse en los siguientes:

• Código reutilizable:Solo tienes que escribir el código una vez y aplicarlo en cada plataforma. Esto indudablemente significa una reducción drástica de tiempo y esfuerzo a la hora de calcular los costos de desarrollo.
  
• Fácil acceso a Plug-ins:Los principales entornos de trabajo le permitirán utilizar extensiones y módulos para mejorar el alcance funcional de su aplicación.
  
• Facilidad de trabajo en grupo:La gran mayoría de los entornos de trabajo multiplataforma utilizan Javascript, HTML5 y CSS3, haciendo más sencillo el proceso de aprendizaje y la comunicación entre desarrolladores ya que estos son estándares muy conocidos y ampliamente utilizados.
  
• Reducción de costes:Aunque ya mencionamos esto de pasada en el primer punto, la razón primordial de este punto es la no dependencia de programadores específicos para cada ecosistema y por consiguiente el pago por separado por cada versión de la aplicación según sistema operativo.
  
• Integración con la nube:Marcos de desarrollo como PhoneGap, Secha y Titanium ofrecen una fácil integración con los servicios de nube, lo que significa que una vez llevado a código el proceso, cualquier versión de la aplicación manejará esta integración casi transparentemente.

Los contras del desarrollo multi-plataforma de aplicaciones móviles también deben tomarse en cuenta:

• Su aplicación podría no soportar todas las características esperadas para cada sistema operativo:Este es un serio problema con las aplicaciones multi-plataforma, o bien se tienen que ajustar a la velocidad con la que el entorno multi-plataforma se adapte a los nuevos cambios en las versiones de los sistemas operativos, o simplemente hay opciones que no existen o no soporta un sistema operativo determinado. El típico problema de tener que escoger el mínimo común divisor, o decidir fragmentar el código en opciones diferentes para cada sistema operativo.
  
• Restricciones de la herramienta:En algunos casos por ejemplo en el caso de adoptar librerías de terceros, sobretodo aquellas desarrolladas para lectores de tarjetas, impresoras y componentes externos hay serias limitaciones que en las aplicaciones nativas simplemente no existen.
  
• Su código podría ser algo más lento:Generalmente el código generado en este tipo de herramientas se apoya en una "traducción" a código nativo, pero en ocasiones el intérprete debe trabajar en tiempo real, haciendo que exista una capa adicional de procesamiento y por ende el código ejecutado sea algo más lento.
  
• Carecen de gráficos y soporte para 3D:Si piensa desarrollar algún tipo de juego 3D, definitivamente estas herramientas no son la mejor solución. También podría tener problemas si necesita utilizar funciones criptográficas avanzadas ya que cada sistema operativo y lenguaje poseen características que diferencian la parametrización de las líbrerías de cifrado aunque se usen los mismos algoritmos.
  
• Alta dependencia del prooveedor:La mayoría de los entornos de desarrollo multi-plataforma usan su propio sub-conjunto JavaScript. Esto significa que si en un futuro deseara cambiar de herramienta le sería bastante difícil.

En conclusión, queda claro que los entornos de desarrollo "híbridos" tienen aún muchos retos por delante, pero si dentro de las necesidades de su empresa no se afectan por los inconvenientes de este tipo de herramienta, pueden ser una buena opción si se necesita una solución rápida y económica.

Redactado por Mauro Maulini R.

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.

Las aplicaciones móviles son fáciles de "decomplilar"

Todos los programadores sabemos a ciencia cierta que las aplicaciones son de una manera u otra "decompilables", es decir podemos obtener con las herramientas adecuadas el código fuente de la aplicación para alterarlo y/o modificarlo (y si no lo sabemos es hora de despertar). Sin embargo cuando una aplicación se encuentra en formato binario el proceso de ingeniería de reverso es mucho más complejo, pero no es este el caso cuando hablamos de aplicaciones móviles desarrolladas en lenguajes como Java o .NET que en realidad no se encuentran en código binario sino en formato intermedio conocidas como "bytecodes" en el caso de Java e "intermediate language (IL)" en el caso de .NET

En el caso de iOS, decompilar las aplicaciones es algo más complejo ya que son necesarios decompiladores costosos y conocimiento avanzado de las técnicas, sin embargo tampoco es un trabajo imposible de realizar.

Si dudan de lo anterior, solo necesitan seguir este enlace http://www.youtube.com/watch?v=3tioug10tuo  que los llevará a un video de cómo decompilar aplicaciones para Android.

Por lo tanto es muy importante entender que debemos ser más eficientes y cautos a la hora de hablar de seguridad en el caso de las aplicaciones móviles, ya que ponemos en riesgo nuestro trabajo (lo cual sería lo menos preocupante) así como la "lógica de negocio" de la empresa para la que desarrollamos la aplicación o lo que es peor aún los datos confidenciales de los usuarios que la utilicen.

Hay una buena cantidad de consejos que deberemos tomar en cuenta mientras desarrollamos aplicaciones móviles, pero quizás el más importante de todos pudiera ser si vamos a desarrollar aplicaciones seguras, no dejar jamás datos específicos "hard coded" dentro de la aplicación. Hablando en lenguaje más simple, no debemos jamás dejar una clave de cifrado, una cadena de conexión a un servidor o base de datos o un algoritmo de negocios en texto plano en nuestro código.

Para evitar lo anterior, todo dato sensible debe ser cifrado y la clave de cifrado debe ser proporcionada por alguna constante del entorno del dispositivo que se mantenga permanentemente pero que sea diferente en otros dispositivos. Por tanto si un amigo de lo ajeno obtiene nuestro código, le será mucho más difícil obtener nuestros datos o lo de nuestros usuarios, ya que cada usuario tendrá una clave de cifrado única.

Lo anterior haría más difícil la obtención de la clave pero no evitaría que el atacante la obtuviera, sin embargo debería repetir un procedimiento complejo para cada usuario o tener acceso directo al dispositivo de cada uno de ellos, lo que reduce drásticamente la superficie de ataque.

Muchos otros son los consejos de seguridad para aplicaciones móviles, como por ejemplo obtener un buen ofuscador de código si realmente se considera de alta prioridad la seguridad, como en el caso de aplicaciones bancarias o de pago. En próximos artículos hablaremos más sobre esto...

Hasta la próxima...