Apuntar sub dominio a un App Service en Azure

23 enero, 2018 por Gonzalo Rodríguez

Este post se basa en un caso un poco particular, se trata de un proyecto que cuenta con un blog instalado en un Hosting Linux de Web Empresa en WordPress al cual era necesario agregarle una aplicación web que fue desarrollada con ASP.NET MVC que corre sobre IIS en un App Service de Azure y a la cual se puede acceder a través de sub.dominio.com.

Este post habla de un problema poco frecuente pero que cuando aparece puede generar algunas complicaciones, en mi caso me llevo un ratito llegar a una solución así que espero pueda ser útil para otro programador.

La solución explicada a continuación es muy simple y a diferencia de asignar un sub dominio a otro hosting por medio de configuración de NS, con Azure lo que se hace es una configuración de CNAME al sub dominio.

Pasos en CPanel

Los pasos que se describen a continuación permiten

Crear el subdominio en este caso CPANEL
1. Panel de Control
  1. Subdominios
  2. Crear subdominio
  3. Click en Volver

Ir a la sección Dominios (DNS Editor Avanzado)
1. Seleccionar el Dominio Principal
2. Buscar el subdominio y hacer click en Editar
  1. Nombre: dominio.com
  2. TTL: 14400
  3. Tipo: CNAME (Cambiar el tipo de A por CNAME)
  4. CNAME:azurewebsite.com (Ingresar la dirección de azure sin https).
3. Realizar de forma análoga el registro con nombre www.sub.dominio.com para funcione correctamente con y sin www.

Pasos en Azure

Ir al menú Settings/Custom Domains
1. Click en Add hostname.
2. Ingresar sub.dominio.com sin http/https.
3. Click en Validate
4. Host Name record type: CNAME
5. Click en Add Hostname

Configuración de sub dominio en azure.

Por último, para probar que todo funciona ok, ingresamos el sub dominio en el navegador y deberíamos poder ver la web app instalada en Azure.

En fin, como comentaba al principio, es un caso muy particular y que se resuelve de forma muy simple.

Si te ha servido este artículo, te invitó a compartirlo para que pueda llegar a más gente.

Ngrok para Simplificar Demos y Debuggs

31 julio, 2017 por Gonzalo Rodríguez

Ngrok – Túneles Seguros Hacia Localhost

En esta oportunidad voy a hablar de una herramienta que permite crear un túnel hacia nuestro localhost con un dominio http o https aleatorio a través del cual se puede acceder a un puerto específico de nuestro localhost.

En lo personal a esta herramienta le encontré 3 ventajas fundamentales permite ahorrar tiempo al realizar demos ya que no es necesario hacer un deploy en algún hosting, facilita mucho el debug desde dispositivos móviles ya que al acceder a través del dominio creado por la herramienta se puede probar y debuggear el código como si estuviéramos probando en un navegador directamente en la máquina de desarrollo y por último que la herramienta habilita una web local donde se guarda registro de todas las peticiones que recibe el servidor junto con la información que llega en los request y la que sale en los response.

En este post vamos a ver el funcionamiento básico de la función gratuita, de todas formas es una herramienta bastante completa que incluye opciones de pago las cuales analizare y probare en otro post.

Descargar Ngrok

https://ngrok.com/

Crear Túnel hacia el Localhost

Ngrok abre una consola al ejecutar el programa en la cual debemos incluir el siguiente código para crear el túnel.

ngrok http PUERTO

En caso de estar trabajando con IIS debemos utilizar el siguiente código.

ngrok http PUERTO -host-header="localhost:PUERTO"

Una vez ejecutado este Código se podrá ver algo similar a la siguiente captura de pantalla.

Session Status: Indica el estado del túnel.

Versión: Indica el nro. de versión y en caso de haber una versión superior en la consola se mostrará un Comando a ejecutar para actualizar.

Región: La ubicación del servidor donde se van a recibir las peticiones a través del túnel, esto es importante si se vive muy lejos de la ubicación del localhost ya que se puede producir un efecto de latencia sobre las peticiones que realizamos al servidor web.

Web Interface: La dirección local de la página web creada por ngrok para analizar las peticiones HTTP realizadas a través del túnel.

Fowarding: Son los dominios HTTP y HTTPS que deberá utilizar el cliente para acceder al localhost.

Http Request: Es una lista que se va cargando sola con los últimos 10 request recibidos por el servidor.

Cerrar el Túnel

Una vez finalizado el trabajo solo será necesario hacer en Ctrl + C en la consola y el túnel se cerrará definitivamente.

Ngrok – Inspector

Esta página se instala en localhost y nos permite analizar los request recibidos por el servidor web. La ventaja más importante para mí se da al momento de tratar de detectar un bug ya que simplemente tengo que reproducirlo en el browser y después analizar que información le llego al servidor.

En la siguiente captura de pantalla se puede ver un ejemplo sobre un proyecto que estoy trabajando actualmente. En la pantalla se puede analizar el Response obtenido al ejecutar una petición GET sobre /Home/GetAllBrands. Otra información interesante es el tiempo de respuesta de cada petición eso puede ayudar a trabajar temas de performance.

Ngrok tiene muchas opciones más pero a nivel práctico para cualquier desarrollador las características explicadas son por demás útiles e interesantes.

Por cualquier comentario o consulta por favor hacerlo a través del formulario de contacto.

Gracias.

Diseños Responsive vs Adaptative

17 febrero, 2017 por Gonzalo Rodríguez

Actualmente la programación web exige en la mayoría de los casos que los sitios web tengan la capacidad de ser utilizados desde múltiples dispositivos con pantallas de diferentes tamaños, televisores, computadoras, etc. Para realizar esto existen o por lo menos yo conozco dos técnicas el diseño responsive y adaptative, a continuación vamos a comparar y conocer cada una de ellas.

¿Qué es el diseño Responsive?

Es una técnica de diseño y desarrollo web que permite detectar a través del navegador el tamaño de la pantalla desde donde se está visualizando la web permitiendo de esta manera ordenar y adaptar todos los elementos de una página web para que se puedan visualizar correctamente en cualquier dispositivo. Esta técnica es caracteriza principalmente por realizarse sobre una única plantilla facilitando de esta forma el diseño y mantenimiento de este tipo de sitios web.

¿Qué es el diseño Adaptative?

Al igual que el diseño responsive tiene como objetivo permitir la correcta visualización de la web en cualquier dispositivo, pero la misma varía con respecto al responsive en la forma que se consigue esto. El diseño adaptative debe detectar a nivel de servidor que tipo de dispositivo está pidiendo la web y una vez detectado el servidor responde enviando los archivos específicos para ese tipo de dispositivo. Este tipo de diseño es más complejo y costoso de realizar ya que requiere un diseño específico para cada tipo de pantalla, pero tiene cómo ventaja el permitir descargar más rápido la web ya que solo envía los archivos necesarios en cada caso.

Compración de Adaptative vs Responsive

Identificación de Dispositivo: El diseño adaptative necesita identificar a nivel de servidor que dispositivo está haciendo un request para para enviar los archivos correspondientes al diseño para el dispositivo detectado. Mientras que el diseño responsive utiliza “Media Queries” para detectar el tamaño de la pantalla y aplicar los estilos correspondientes.
Optimización de Contenido: Con el diseño adaptative solo se mostrará la información que fue optimizada para el dispositivo detectado, mientras que en el diseño responsive se mostrará toda la información de la web.
Templates utilizados: En un diseño adaptative hay que utilizar un template para cada tipo de dispositivo mientras que en responsive es solo uno con el que se ajusta la posición y tamaño del contenido para correcta visualización.
Comportamiento: Un diseño adaptative ajusta el comportamiento de acuerdo al dispositivo que se esté utilizando mientras que un diseño responsive utiliza todas las características que puede soportar un navegador.
Velocidad de Carga: Las páginas con diseño adaptative suelen cargar más rápido ya que cada diseño esta optimizado para el dispositivo que lo está cargando por lo tanto carga menos archivos que el responsive que descarga todo y posteriormente tiene que adaptarse. En lo personal creo que para la mayoría de los usuarios estas diferencias de velocidad de carga no son perceptibles.
Costos de Desarrollo: Como hemos indicado previamente el diseño adaptative requiere utilizar un template diferente para cada dispositivo por lo tanto el costo de desarrollo es mayor que en un diseño responsive que funciona con un solo template, también requiere de que la persona encargada de realizar este diseño posea conocimientos avanzados en CSS y JS. En cambio para el diseño responsive es que no hay que ser un experto en CSS y JS para realizarlo ya que hoy en día existen Web Design Frameworks como Bootstrap, Foundation, Titan Framework, etc. que solo requieren conocimientos básicos en HTML, JS, CSS para poder ser utilizados en el diseño de sitios web además la mayoría de estos frameworks son open source por lo cual no implican un costo adicional y también permiten agilizar del diseño logrando de esta forma reducir los costes de desarrollo.

Conclusiones

Ambas formas de diseñar el frontend web tienen como objetivo resolver el mismo problema, las conclusiones a las que podemos arribar en lo personal me gusta enfocarlas en tres aspectos fundamentales, costo de producción, costo de mantenimiento, rendimiento.

En lo que respecta al costo de producción el diseño responsive sería la mejor opción para un diseño desde cero ya que es más rápido de diseñar porque solo es necesario crear una única plantilla y el comportamiento no cambia para los diferentes dispositivos solo cambia el orden de los componentes de acuerdo al espacio disponible en cada pantalla.

En el caso de que el trabajo implique actualizar una web existente habría que evaluar, puede que para estos casos sea más barato aplicar diseño adaptative ya que solo habría que diseñar las plantillas para los dispositivos faltantes y no rediseñar todo el sitio con una plantilla responsive nuevamente. En fin para este caso la respuesta sería “Depende”.

Con respecto al costo de mantenimiento en el caso más simple el diseño responsive sería el más barato ya que solo hay que mantener una única plantilla que serviría para todos los dispositivos y en cualquier diseño adaptative habría que realizar mantenimiento a diferentes plantillas con comportamientos parecidos.

Rendimiento técnicamente los diseños adaptativos son mejores en este aspecto ya que el servidor responde solo los archivos necesarios para el dispositivo que está intentando acceder a la web mientras que el diseño responsive siempre retorna la misma cantidad de información sin importar el dispositivo, después a nivel de browser se detecta el tamaño de la pantalla y es ahí cuando se aplican los estilos necesarios.

En resumen en este post busque explicar de forma resumida y simple de entender en que consiste cada técnica de diseño web, espero haya sido útil y bueno cualquier consulta estoy a las órdenes a través del formulario de Contactar.

Gestión del Tiempo con Toggl

10 febrero, 2017 por Gonzalo Rodríguez

En esta oportunidad voy a hablar de una herramienta muy interesante para ayudar en la gestión del tiempo, se trata de Toggl una aplicación multi-plataforma que permite registrar el tiempo que dedicamos a cada actividad, proyecto y cliente en nuestro trabajo.

En mi caso cómo desarrollador web y emprendedor le sacó provecho principalmente en los siguientes dos aspectos, primero y fundamental es muy fácil tomar información precisa sobre el tiempo invertido para realizar cada actividad esto hace que se puedan calcular costos de producción fácilmente y guardar información muy útil para estimaciones en futuros proyectos. Y en segundo lugar le saco mucho provecho al poder comparar en porcentajes el tiempo dedicado a cada proyecto, esto me ayuda a planificar cada semana y buscar estar lo más enfocado posible en las actividades que me van a hacer cumplir mis objetivos, esto es más que nada porque en el día a día es fácil perder la perspectiva general del esfuerzo realizado principalmente cuando se trabaja en varios proyectos de forma paralela.

Otra ventaja que le encontré a esta aplicación es su modelo de negocio, se trata de un “Modelo Freemium” es decir hay una parte funcional gratis pero aparte hay mejoras Premium que tienen costo mensual e incrementan las capacidades del sistema. La parte gratuita para probar el sistema es muy completa y funcional, y los precios de la membresía en caso de querer ampliar las capacidades del sistema parecen muy accesibles para cualquier tipo de empresa que requiera la planificación y coordinación de proyectos con equipos de varias personas. Por otra parte la versión free solo permite trabajar de a una persona.

Funcionamiento Básico

En este ejemplo vamos a ver cómo funciona Toggl en su versión Free para Web. Conociendo básicamente el funcionamiento de la aplicación web, se puede manejar sin ningún tipo de problema la plataforma en cualquiera de los demás dispositivos disponibles.

La siguiente pantalla es la primera que vemos cuando accedemos a la aplicación, para facilitar marqué 4 recuadros para explicar las diferentes zonas de la interfaz.

Parte 1: Se encuentran los controles de ingreso de Tarea, selección de Proyecto y Control de Tiempo de realización de la tarea.
Parte 2: Se despliega un resumen de todas las tareas realizadas en cada día, en esta lista está la posibilidad de ajustar el tiempo de alguna tarea por si el tracking realizado fue incorrecto, para ser más claro imaginemos que trabajamos de 8:00 AM a 10:00 AM en una tarea y por algún motivo nos acordamos de frenar el tiempo a eso de las 13:00 PM, en este ejemplo el tiempo registrado será incorrecto pero desde la lista podremos corregirlo.
Parte 3: En la sección Manage se encuentran las opciones de configuración de clientes, equipos, proyectos y espacios de trabajo, más abajo en este artículo las iremos trabajando.
Parte 4: Para la versión gratuita solamente podemos utilizar las tres primeras opciones:
1. Timer que corresponde a la pantalla que estamos viendo en la imagen.
2. Dashboard que es la pantalla donde podemos ver gráficas del tiempo dedicado, más adelante veremos capturas de pantalla.
3. Reportes es una pantalla que permite crear reportes utilizando toda la información obtenida a través de la carga de tiempo.

Registrar una Tarea

Una vez que ingresamos nuestra tarea, solo tenemos que hacer clic en Play para que el tiempo comience a correr a partir de ese momento podremos ver una imagen similar a la siguiente y cuando decidamos terminar la tarea solamente hay que hacer clic en el botón Stop y la tarea quedará correctamente almacenada indicando información de, proyecto, cliente, tags y si fue una tarea facturable o no.

Es probable que esta función de poner play y stop a algunas personas les pueda resultar incómoda o poco práctica, para estos casos Toggl permite definir la fecha y hora de comienzo y fin de cada tarea

Configuración

Creación de Clientes

Cómo se puede ver es una pantalla muy sencilla donde solamente ingresamos el nombre del cliente. También podemos desde la opción Settings definir el Workspace en caso de tener más de uno, definir grupos de usuarios y tags. La única información requerida es el nombre del cliente, el resto es opcional

Creación de Proyectos

El siguiente paso sería agregar Proyectos, esta pantalla también es muy sencilla ya que solo tenemos que ingresar el nombre del proyecto y seleccionar el cliente en caso de que corresponda ya que el mismo es parte de la información opcional.

Creación de Equipos

Esta opción permite crear equipos agregando los miembros a través de su correo electrónico, posteriormente estos tendrán que registrarse en Toggl en caso de no estar y aceptar la solicitud. Para esta opción hay que estar utilizando una versión de pago ya que la versión gratuita solo permite trabajar con 1 usuario.

Creación de Workspaces

Se pueden crear espacios de trabajo diferentes, los cuales tendrán por si mismos clientes y proyectos. Y la información registrada podrá pertenecer a un workspace o a otro.

Donde funciona exactamente Toggl

Tiene una versión web a la cual se accede a través de su sitio https://toggl.com/login

Mobile

Android
iPhone

Escritorio

Windows
Mac
Linux

Extensiones para Navegadores

Chrome
Firefox

Y aparte cuenta con una API propia para poder integrarlo en cualquier sistema.

Conclusiones

Desde hace varios meses que utilizó esta aplicación y la verdad creo que es muy interesante ya que permite recolectar información y analizarla de forma fácil. En lo personal me ha rendido mucho para analizar en detalle a que dedicó el tiempo durante el día y las semanas, de esta forma tomo información útil para planificar las actividades de cada proyecto en cada semana.

En resumen creo que esta es una herramienta que colabora en la gestión del tiempo pero no resuelve por completo este aspecto de acuerdo a lo que he podido comprobar, realizar un tracking correcto y preciso junto con una buena planificación a corto plazo en mi caso (semanal) ayudan a trabajar aspectos cómo productividad y minimizar considerablemente los errores en las estimaciones de las diferentes tareas.

Como siempre tengo que recordar que no utilizó enlaces de afiliado, por lo que recomiendo está herramienta porque la considero muy útil.

Configuración AMP en ASP.NET MVC

27 enero, 2017 por Gonzalo Rodríguez

Introducción

Este es un ejemplo concreto en el que se muestra cómo incluir AMP en ASP.NET MVC. Este artículo va a ser técnico y bien enfocado a aspectos de programación por lo tanto NO vamos a hablar sobre las ventajas que puede tener incluir AMP en lo que respecta a aspectos de calidad y SEO; para los que estén interesados en este punto les recomiendo el artículo Conceptos SEO para Programadores donde se trabaja este aspecto y algunos más que puede ser útil conocer.

En este ejemplo vamos a comenzar con un proyecto ASP.NET MVC vacío en el cual vamos a agregar un HomeController, una View Index y su versión AMP en otro archivo Index.amp.cshtml. El ejemplo se enfoca en los ajustes que hay que hacer a nivel de MVC y en la View para poder incluir esta característica, no vamos a trabajar características específicas de maquetar con AMP ni analizar las restricciones que presenta el lenguaje.

En resumen lo que queremos hacer es que para un mismo action del controller se retornen 2 views diferentes una común y otra AMP. Para esto lo que vamos a utilizar se conoce como DisplayModeProviders y es una característica que se incluyó en ASP.NET MVC 4 que permite fácilmente diseñar Views para diferentes dispositivos las cuales responderán al mismo ActionResult.

Configuración Paso a Paso

Los pasos para realizar esto serían los siguientes

Crear una solución vacía de ASP.NET MVC.
Agregar un controller y una view por ejemplo HomeController y ActionResult Index.
Creamos la View Index correspondiente.
Agregamos dentro de Views/Home una nueva vista llamada Index.amp.cshtml (en esta vista es donde vamos a incluir el código AMP).
Creamos una carpeta DisplayModes y dentro incluimos una clase GoogleAmpDisplayMode.cs.
En este punto la solución debería quedar similar a esta imagen.

6. Ahora tenemos que agregar el siguiente código al final del método Application_Start() en el Global.asax.

DisplayModeProvider.Instance.Modes.Clear();
DisplayModeProvider.Instance.Modes.Add(new GoogleAmpDisplayMode());
DisplayModeProvider.Instance.Modes.Add(new DefaultDisplayMode());

DisplayModeProvider contiene una lista de objetos en los que cada uno representa un modo de display. En este caso tenemos DefaultDisplayMode para las view que creamos por defecto y agregamos GoogleAmpDisplayMode para las vistas AMP.

7. Ahora dentro de la clase GoogleAmpDisplayMode incluimos el siguiente código.

public class GoogleAmpDisplayMode : DefaultDisplayMode
{
     public GoogleAmpDisplayMode() : base("amp") // para archivo.amp.cshtml.
     {
          ContextCondition = context => context.Request.RawUrl.Contains("?amp");
     }
}

GoogleAmpDisplayMode hereda de DefaultDisplayMode y lo que hace es permitirnos que la view amp se cargue en el response cuando se agrega en la url el parámetro ?amp.

Probar que todo funciona

En este momento si ejecutamos nuestra solución por defecto nos va a mostrar la view que no tiene AMP, pero si al final de la url le agregamos el query string amp (http://localhost:18190/Home/Index?amp) ahora con la ayuda de la configuración de DisplayModeProvider el response generado se cargará la view Index.amp.cshtml. Por ahora NO incluimos el código AMP solamente hicimos la configuración para que se retorne la vista correspondiente en cada caso.

View con AMP

Ahora sí vamos a agregar los mark-ups requeridos para que una vista sea AMP, por lo tanto a partir de ahora vamos a trabajar sobre en el archivo Index.amp.cshtml. Este código al ser requerido yo recomiendo siempre tomarlo directamente desde la web AMP de Google y hacerle los ajustes particulares para nuestro código, para eso hay que ir a la siguiente url https://www.ampproject.org/docs/get_started/create/basic_markup.

Los únicos ajustes que tuve que hacer por estar trabajando con ASP.NET MVC fue agregar un @ delante de cada @ dentro del style.

Con eso ya podemos tener una vista simple, debajo de este código vamos a explicar las líneas importantes el cabezal de la página AMP.

En nuestro caso el código de la view quedaría así:

 @{
 Layout = null;
}
<!doctype html>
   <html amp>
     <head>
       <meta charset="utf-8">
       <link rel="canonical" href="~/Views/Home/Index.cshtml">
       <meta name="viewport" content="width=device-width,minimum-scale=1,initial-scale=1">
       <style amp-boilerplate>
          body {
            -webkit-animation:-amp-start 8s steps(1,end) 0s 1 normal both;
            -moz-animation:-amp-start 8s steps(1,end) 0s 1 normal both;
            -ms-animation:-amp-start 8s steps(1,end) 0s 1 normal both;
            animation:-amp-start 8s steps(1,end) 0s 1 normal both;
          }
          @@-webkit-keyframes -amp-start{from{visibility:hidden}to{visibility:visible}}
          @@-moz-keyframes -amp-start{from{visibility:hidden}to{visibility:visible}}
          @@-ms-keyframes -amp-start{from{visibility:hidden}to{visibility:visible}}
          @@-o-keyframes -amp-start{from{visibility:hidden}to{visibility:visible}}
          @@keyframes -amp-start{from{visibility:hidden}to{visibility:visible}}
     </style>
     <noscript>
        <style amp-boilerplate>
           body {
             -webkit-animation: none;
             -moz-animation: none;
             -ms-animation: none;
             animation: none;
           }
       </style>
   </noscript>
       <script async src="https://cdn.ampproject.org/v0.js"></script>
</head>
<body>
 <h2>Ejemplo simple con AMP</h2>
 <div id="contenido">
    <p>Lorem ipsum dolor sit amet, consectetur adipiscing elit.</p>
 </div>
</body>
</html>

Algunas particularidades de una view AMP

<html amp> – Es el tag que indica que se trata de una web implementada con AMP.
<link rel=”canonical” href=”~/Views/Home/Index.cshtml”> – Aquí se incluye la URL de la vista regular correspondiente a la actual vista AMP.
<script async src=”https://cdn.ampproject.org/v0.js”></script> – Inclusión del código javascript de amp.

Conclusiones

En fin como se puede ver en este artículo la configuración es bastante simple. Tal vez lo que pueda llegar a complicar sea la maquetación por las limitaciones que parece tener el lenguaje según su documentación oficial, pero bueno esto será tema de artículos futuros donde pretenderé analizar en detalle el lenguaje AMP.

Espero el artículo sea útil y bueno cualquier consulta quedó disponible a través del formulario de Contactar.

Auditoria de Vulnerabilidades Web

20 enero, 2017 por Gonzalo Rodríguez

El tema de la seguridad web para el desarrollo lo considero un tema muy importante y que aporta mucho valor en la calidad en el producto final. En este post vamos a hablar de OWASP ZAP una herramienta Open Source por de más interesante que permite analizar nuestros proyectos realizando un escaneo en busca de potenciales vulnerabilidades. Es importante destacar que vamos a realizar un repaso práctico básico para que quien esté interesado pueda tener un lugar por donde comenzar a conocer esta herramienta.

En el mercado existen muchas herramientas y por mi parte cuando trabajaba como empleado de una multinacional utilizábamos NetSparker, para mí una de las mejores que he visto hasta el momento. Pero bueno otra de las cosas a las que me he tenido que adaptar al emprender como Profesional Independiente es al no tener los mismos recursos que tenía dentro de una empresa grande así que bueno investigando y preguntando a colegas del sector llegue a conocer OWASP ZAP y la verdad es que me ha dado muy buenos resultados.

Según la información que se puede leer en el sitio web oficial de la herramienta, la misma fue creada por personas con mucha experiencia en seguridad informática construida especialmente para desarrolladores y testers funcionales. La idea es que si bien los desarrolladores y tester seguramente no somos expertos en seguridad informática con esta herramienta podemos trabajar estos aspectos de seguridad en nuestra aplicación y lograr con ella construir productos con menos vulnerabilidades.

Ejecutar Auditoría de Vulnerabilidades

En este apartado vamos a mostrar un ejemplo simple y práctico para que cualquier desarrollador web puede detectar vulnerabilidades y aspectos de seguridad para mejorar sus aplicaciones web.

Es una herramienta cuyo funcionamiento se basa en ejecutar diferentes ataques para ver cómo responde nuestra aplicación web, es conveniente que la prueba se ejecute en un ambiente controlado para evitar tener cualquier tipo de problema legal. Yo recomiendo utilizar esta herramienta en ambiente de desarrollo y si desean hacer un chequeo final antes de salir a producción, hacerla sobre la versión de pre-producción.

Primero por supuesto hay que descargar e instalar el programa, aquí les dejo el link.

Cuando abrimos el programa vamos a ver una pantalla cómo la siguiente, para realizar un análisis inicial simplemente colocamos nuestra url en el TextBox “URL to attack” y hacemos clic en el botón “Attack”.

Tan solo con esto es posible que ya tengamos trabajo de mejoras que realizar. Vamos a comenzar analizando este caso básico y posteriormente vamos a profundizar un poco en el tipo de ataques que se pueden agregar al análisis configurado por defecto.

Es importante destacar que esta es una guía básica de funcionamiento de OWASP ZAP y si les gusta este post y quieren recibir uno más completo y explicando más en detalle las funcionalidades de esta herramienta solamente tendrán que pedirlo a través del formulario contactar.

Para esta prueba voy a ejecutar la auditoría de vulnerabilidades sobre una aplicación ASP.NET MVC creada con la plantilla por defecto en Visual Studio 2015 Community, utiliza .NET Framework 4.5.2 sin ningún ajuste realizado por mí. Esto lo aclaro por si alguien quiere repetir exactamente esta misma prueba para empezar a conocer la herramienta.

Una vez hecho clic en el botón “Attack” comienza la auditoría durante el proceso podemos ver la ventana de Scan Progress en la cual se muestra una barra de progreso por cada ataque que se va ejecutando.

Cuando el proceso de auditoría finaliza podemos ver una pantalla similar a la siguiente donde vamos a ver por parte los resultados obtenidos.

En la zona de referencia Nro 1, podemos archivos de nuestro proyecto con una bandera de color a la izquierda donde se pretende indicar el tipo de alerta encontrado.

En la zona de referencia Nro. 2 en la izquierda inferior de la pantalla podemos ver todas las alertas encontradas.

Al ingresar en la Alerta y hacer clic sobre ella, sobre la derecha se nos despliega un formulario en el que se destaca la siguiente información:

Tipo de Riesgo: Alto, medio, bajo

Descripción: Un texto que pretende hacernos entender por qué se detectó la vulnerabilidad.

Otra Información: Un apartado de información adicional que solo sale en algunos casos.

Solución: Es un pequeño texto en el cuál te ayuda a entender cómo solucionar la vulnerabilidad.

Referencias: Un apartado también de información opcional que pude establecer referencias de sitios web’s sobre todo para poder obtener más información sobre la solución.

Simplemente con conocer hasta acá, el desarrollo de una aplicación web puede lograr importantes mejoras tanto a nivel de seguridad cómo de la calidad general del producto. De todas formas vamos a intentar profundizar un poco más en este revisando que tipo de procesos de escaneo se ejecutan.

Repaso sobre escaneo de seguridad

Para ver un poco las pruebas que hace el escáner podemos ir al menú (Analyse / Scan Policy Manager / Default Policy / Modify).

Podemos ver que se ofrecen opciones de escaneo divididas en 4 grupos (Information Gathering, Injection, Miscellaneous, Server Secutiry).

En la imagen vemos 5 grupos pero Client Browser por defecto no trae ninguna opción de escaneo.

A continuación vamos a repasar algunas de las Scan Policy configuradas por defecto:

Injection

Cross Site Scripting (XSS): Esta vulnerabilidad suele aparecer por falta de controles adecuados sobre los campos de entrada que dispone la web. En este tipo de ataques el hacker inserta un código malicioso dentro de la aplicación web, que permite posteriormente al atacante robar información de usuarios o insertar código para realizar Spam.

Server Side Injection (SSI): Es una vulnerabilidad donde el atacante introduce código malicioso a través de los campos de entrada de una aplicación web. Este tipo de ataques pueden producir que un hacker tenga acceso a nuestro web.config por ejemplo y a través del mismo lograr acceso a nuestra base de datos, este es uno de los escenarios más comunes que se presentan como ejemplo en páginas que explican sobre este tipo de vulnerabilidades.

CRLF Injection: A través de esta vulnerabilidad el atacante web puede inyectar datos a través de peticiones a un servidor. También es conocida cómo inyección de encabezado HTTP. Cuando una petición HTTP contiene un retorno o salto de línea inesperado, el servidor podrá responder con diferentes respuestas HTTP en vez de una sola, lo cual puede permitir al atacante controlar alguna de estas respuestas y utilizarla para ejecutar un ataque por XSS por ejemplo.

SQL Injection: Es una vulnerabilidad también es muy peligrosa que puede permitir a los atacantes ejecutar instrucciones SQL a través de los inputs de una página web. Cuando algún hacker explota esta vulnerabilidad generalmente el resultado es la destrucción de la base de datos, ya que el atacante suele tener la posibilidad de modificar o eliminar información en la base.

Server Security

Remote File Inclusion: Este tipo de vulnerabilidad puede existir en aplicaciones web desarrolladas con PHP ya que permiten la inclusión de archivos a través de funciones include. Las web atacadas con este tipo de técnicas pueden llegar a incluir archivos remotos ubicados en otros servidores los cuales pueden ejecutar cualquier tipo de código malicioso.

En este apartado se hizo un breve repaso sobre algunas de las vulnerabilidades analizadas, todas son muy complejas pero al ser detectadas por esta herramienta, la misma nos propone soluciones sobre los lugares de la web que pueden ser atacados.

Conclusiones

Si bien la profundidad de este post es básica, el contenido es muy práctico y aplicable; de hecho la herramienta está pensada para que personas sin conocimientos ni experiencia en seguridad web puedan utilizarla para mejorar la seguridad y calidad de sus productos.

Escribí este artículo con la idea de mostrar una herramienta que puede ser muy útil para otros desarrolladores web.

Y cómo dije anteriormente si les gustó el post y quieren uno nuevo más técnico y con ejemplos prácticos completos, solamente tienen que pedirlo a través del formulario de contactar.