El gran Jenkins - automatización

Veremos en términos rápidos y generales algunas características básicas de Jenkins, principalmente lo que debemos saber sobre esta gran herramienta para dar una breve descripción para enseguida ir directo a trabajar con ella, no profundizaremos en su historia y orígenes, simplemente hablaremos de lo principal como cultura general:

• Jenkins es un software de integración continua muy potente de código abierto escrito en Java, anteriormente conocido como Hudson, con esta herramienta podremos desplegar nuestro código en un servidor donde será compilado y probado.
• Por medio de Jenkins podemos configurar la forma en la que vamos a obtener el código fuente y en la que queremos analizar el código de nuestro proyecto e integrar la herramienta con otras aplicaciones para hacer un análisis profundo de los resultados obtenidos, tales como generación de reportes, ejecución de distintas pruebas, gráficos o informar de malas prácticas implementadas en las líneas de código entre otros muchos tipos de informe.
• Jenkins tiene soporte para sistemas de control de versiones, algunas como SVN, CVS, Git y corre en un servidor de aplicaciones como por ejemplo los muy conocidos como Tomcat o Jboss permitiendo la ejecución de proyectos configurados con Ant y/o Maven. También el paquete war de Jenkins contiene un servidor interno Jetty el cual con solo ejecutar el war con Java le da funcionamiento a Jenkins.
• Con Jenkins basándonos en el concepto de integración continua o continuous delivery, cada vez que un programador del equipo de trabajo realice un cambio sobre el código fuente y lo suba al repositorio de código fuente, el sistema mediante la ejecución de sus tareas automáticas podrá revisar dichas actualizaciones y determinar su correcto funcionamiento mediante compilación, ejecución de pruebas unitarias y/o funcionales. 
• Facilita el seguimiento a procesos de distintas áreas (Desarrollo, Testing, UAT y demás), encontrar defectos lo antes posible y poder tomar de decisiones sobre bugs o mejoras en la calidad del software.
• Se integra al equipo de trabajo como una herramienta muy útil, facilita la organización pudiendo mejorar y agilizar los procesos, estabilizar la aplicación y mejorar la calidad del proyecto.

Lo anteriormente dicho son algunas de las características básicas de Jenkins, como vemos esta es una pequeña y rápida introducción de la Herramienta, tal vez un poco confusa pero con muchas mas aplicaciones, desde la página oficial de Jenkins se puede consultar más información, acceder a su wiki, comunidad, foros y herramientas ingresando a http://jenkins-ci.org/

Reconstruir el proyecto de Ionic

Me ha pasado varias veces que agrego librerías en Ionic para hacer distintas pruebas y luego cuando ya defino que plugin o librería usar, el proyecto me queda sobrecargado de librerías. Por eso la idea de este post es poder limpiar todas las librerías agregadas y que solo queden las que realmente se van a usar en el proyecto.

Cuando se quiera limpiar el proyecto y volver a construir el proyecto desde los archivos de configuración, se debe seguir los siguientes pasos:

1. Borrar los directorios node_modules, plugins y platforms
2. Ejecutar en la raiz del proyecto 

• npm install -g

• ionic cordova prepare

• ionic cordova platform add android

Otra forma mucho mas facil que hace exactamente lo mismo es correr el siguiente comando:

• ionic repair

Ataques Web - Exposición de datos sensibles

Muchas aplicaciones Web no protegen adecuadamente los datos sensibles, tales como números de tarjeta de crédito o credenciales de autenticación. Los atacantes pueden robar o modificar tales datos para llevar a cabo fraudes, robos de identidad u otros delitos. Los datos sensibles requieren de métodos de protección adicionales tales como el cifrado de datos, asi como tambien de precauciones especiales en un intercambio de datos con el navegador.

Como detectarlo

Lo primero que debe determinar es el conjunto de datos sensibles que requerirán protección extra. Por ejemplo, contraseñas, números de tarjeta de crédito, registros médicos, e información personal deberían protegerse. Para estos datos:

1. ¿Se almacenan en texto claro a largo plazo, incluyendo sus respaldos? 
2. ¿Se transmiten en texto claro, interna o externamente? El tráfico por internet es especialmente peligroso. 
3. ¿Se utiliza algún algoritmo criptográfico débil o antiguo? 
4. ¿Se generan claves criptográficas débiles, o falta una adecuada rotación o gestión de claves? 
5. ¿Se utilizan tanto cabezales como directivas de seguridad del navegador cuando son enviados o provistos por el mismo?

Como prevenirlo

Los riesgos completos de utilizar cifrado de forma no segura, uso de SSL, y protección de datos. Dicho esto para los datos sensibles, se debe realizar como mínimo lo siguiente:

1. Considere las amenazas de las cuales protegerá los datos (ejemplo atacante interno, usuario externo), asegúrese de cifrar los datos sensibles almacenados o en tráfico de manera de defenderse de estas amenazas. 
2. No almacene datos sensibles innecesariamente. Descartelos apenas sea posible. Datos que no se poseen no pueden ser robados. 
3. Asegúrese de aplicar algoritmos de cifrados fuertes y estándar así como claves fuertes o gestionelas de forma segura. Considere utilizar módulos criptográficos validados como FIPS 140. 
4. Asegúrese que las claves se almacenan con un algoritmo especialmente diseñado para protegerlas como ser bcrypt, PBKDF2 o scrypt. 
5. Deshabilite el autocompletar en los formularios que recolectan datos sensibles. 
6. Deshabilite también el cacheado de páginas que contengan datos sensibles.

Ataques Web - Demostración - XSS Reflected

Este tipo de vulnerabilidad compromete la seguridad del usuario y no la del servidor. Consiste en inyectar código HTML o Javascript en una web, con el fin de que el navegador de un usuario ejecute el código inyectado en el momento de ver la página alterada cuando accede a esta. La forma conocida como reflejada comúnmente se produce en sitios que reciben información vía GET (aunque también puede darse el caso vía POST), como por ejemplo:

buscador.php?d=cadena_a_buscar

Si sufriera este tipo de vulnerabilidad se podría inyectar código en el navegador del siguiente modo:

buscar.php?d=<script type="text/javascript">script();</script>

De esta forma el código insertado no se mostraría de forma persistente, pero aun así un usuario malintencionado podría crear una URL que ejecute el código malicioso para posteriormente enviárselo a una persona y que al ejecutarlo ésta pueda sustraer cookies o incluso su contraseña (Pishing).

Para ejemplificar este tipo de vulnerabilidad DVWA presenta una página en la que se solicita un nombre a través de un formulario. Una vez enviado, el script muestra la cadena de texto “Hello nombre_enviado”.

En el nivel de seguridad low el código fuente vulnerable es el que se muestra a continuación:

Esta porción de código sólo valida que el nombre introducido no sea una cadena vacía.

Así pues, para probar la vulnerabilidad de esta página se inyectará el siguiente código HTML que incluye un script Javascript:

<script>alert("Pagina vulnerable en nivel low")</script>

que mostrará una ventana de alerta con el mensaje “Página vulnerable en nivel low”.

A continuación se introduce código HTML mostrar una imagen en lugar de una cadena de texto como sería de esperar:

<img src="http://spf.fotolog.com/photo/31/9/87/de_viginin/1236543937498_f.jpg" alt="Pato" />

En el nivel de seguridad medium se realiza un pequeño filtrado de la cadena de texto recibida a través del formulario haciendo uso de la función str_replace() para, en caso de ser encontrada, reemplazar la cadena <script> por una cadena vacía.

DVWA muestra en este nivel el mismo formulario que en el nivel low:

Se usará el mismo mensaje de alerta Javascript usado para el nivel low, con la diferencia que en esta ocasión el tag HTML se escribirá en mayúsculas (y de este modo evitar que la función str_replace() encuentre coincidencia y sustituya el tag por una cadena vacía):

<SCRIPT>alert("Pagina vulnerable en nivel medium")</SCRIPT>

Aunque también hubiera bastado con añadir el tipo de script al tag <script> para que no se produjera coincidencia:

<script type="text/javascript">alert("Pagina vulnerable en nivel medium")</script>

Como la única etiqueta HTML filtrada es <script>, se podría insertar cualquier código HTML
 imaginable. Por ejemplo, un hipervínculo a la página www.as.com:

<a href="http://www.as.com/">As.com</a>

Aunque este ejemplo pueda parecer inocuo, ejemplifica perfectamente las posibilidades que podría llegar a permitir esta vulnerabilidad, como por ejemplo añadir un enlace a un script que se encargará de robar cookies…

Prevención

Para evitar este tipo de vulnerabilidad se recomienda filtrar siempre la información procedente del usuario antes de hacer uso de ella. Generalmente con filtrar los caracteres “<” y “>” sería suficiente, aunque se recomienda también filtrar los nombres de las etiquetas que pueden resultar peligrosas en este tipo de ataque como <script>, <object>, <applet>, <embed> y <form>.

Asimismo se pueden realizar comprobaciones para comprobar que el tipo de dato introducido y la longitud de cada campo se correspondan con lo esperado.

Por su parte, DVWA en el nivel de seguridad high hace uso de la función htmlspecialchars() para convertir caracteres especiales en entidades HTML.

Para que comprender mejor su funcionalidad se muestran algunos ejemplos:

• & (et) se convierte en &amp; 
• “ (comillas dobles) se convierte en &quot; cuando ENT_NOQUOTES no está establecido. 
• ‘ (comilla simple) se convierte en &#039; (o &apos;) sólo cuando ENT_QUOTES está establecido. 
• < (menor que) se convierte en &lt; 
• > (mayor que) se convierte en &gt; 

Otra contramedida enfocada a los propios usuarios de páginas web es la de tener el navegador lo más actualizado posible. Por ejemplo el navegador Internet Explorer a partir de su versión 8, introduce como novedad un filtro Anti XSS que detecta posibles manipulaciones de la página mediante la inyección de código en un parámetro de la URL.

Ataques Web - Demostración - Sql Injection Blind

Este tipo de ataque es similar al SQL Injection que se acaba de estudiar, con la diferencia que la página web no devuelve ningún mensaje de error al producirse resultados incorrectos tras una consulta a la base de datos. Esta falta de muestreo de resultados se produce por el tratamiento total de los códigos de error, y la imposibilidad de modificar, a priori, información alguna de la base de datos, teniendo respuesta únicamente en caso de que la consulta sea correcta.

La falta de mensajes de error no quiere decir que no sea vulnerable una página web. ¿Cómo se sabe que una web es vulnerable a SQL Injection Blind? Pues basta con probar un poco más y siempre que la inyección esté bien ejecutada se mostrará el contenido esperado.

Sentencias condicionales tipo Or 1=1 o having 1=1 ofrecen respuestas siempre correctas (true o verdadero) por lo cual suelen ser usadas por los programadores como formas de comprobación.

En el nivel de seguridad low el código fuente vulnerable es el que se muestra a continuación, la única diferencia con el nivel low de SQL Injection es el tratamiento de errores:

DVWA vuelve a mostrar una página similar a la de SQL Injection, donde escribir el ID de un usuario de la base de datos, y al igual que antes, devuelve el nombre y apellido asociado a dicha ID:

Se prueba con una comilla simple para ver que realmente no se devuelve ningún error y efectivamente al pulsar en “Submit” se vuelve a llevar a la pantalla original en blanco:

Tras ver que no se devuelve ningún error se pasa a probar a inyectar una consulta de tipo condicional, en este caso se va a insertar ' OR 'x'='x, lo que devolverá un listado con los usuarios:

A continuación se inyectará una consulta más compleja, anidando a la original:
1' and 'test' = 'b' union select database(), user() #
Que debe devolver la base de datos en que se está trabajando y el usuario utilizado:

En el nivel de seguridad medium el código difiere del anterior en que la id recibida desde el formulario HTML es filtrada a través de la función mysql_real_scape() como se muestra a continuación:

Al igual que en el nivel medium de SQL Injection, DVWA vuelve a restringir el uso de caracteres especiales, por lo que se vuelve a usar la inyección de nivel low ' OR 'x'='x como ejemplo:

En SQL Injection Blind, como ya se ha mencionado, en caso de error en la consulta no se devuelve nada, ni tan siquiera un mensaje de error advirtiendo del problema:

Se inyecta otra consulta condicional pero en esta ocasión sin los caracteres especiales:
1 OR 0=0----

Esta consulta devolverá un listado con los nombres y apellidos de los usuarios:

Como último ejemplo se extraerán todos los campos de la tabla users inyectando:

1 and 1=0 union select table_name, column_name from information_schema..columns where table_name = 0x7573657273

Donde el número hexadecimal de SQL (0x7573657273) representa el nombre de la tabla en que se va a buscar. Este número puede ser muy importante dado a que a priori nadie conoce las tablas que se han creado en el sistema.

Prevención

Dado que SQL Injection y SQL Injection Blind son a efectos prácticos la misma vulnerabilidad (pero en el caso Blind, sin mensaje de error devuelto en las consultas), las recomendaciones para evitar este tipo de ataques son las mismas:

• Filtrado en tiempo de ejecución y bajo demanda.
• Hacer uso de las funciones addcslashes(), mysql_real_escape_string() y stripslashes(), ya explicadas anteriormente, a la hora de filtrar los datos recibidos para realizar la consulta.
• Uso de la librería mysqli.

Ataques Web - Demostración - XSS Almacenado

XSS stored, también llamado XSS directo o persistente, consiste en embeber código HTML o Javascript en una aplicación web pudiendo llegar incluso a modificar la propia interfaz de un sitio web (defacement). Al igual que en el caso de XSS reflejcted, esta vulnerabilidad compromete la seguridad del usuario y no la del servidor.

La diferencia frente a XSS reflected es que este tipo de vulnerabilidad es persistente (de ahí que se le conozca también por ese nombre) ya que el código malicioso insertado generalmente es almacenado en una base de datos.

A modo de ejemplo, se considera el siguiente sitio web:

Un blog de noticias sobre Informática donde cada artículo permite la inclusión de comentarios por parte de sus usuarios. Una vez enviado un comentario, el contenido de éste será insertado en la base de

datos e inmediatamente visible en la página del artículo.

Tras descubrir cómo inyectar código en la web, las posibilidades que ofrece esta vulnerabilidad al atacante son diversas:

• Inyectar código que robe las cookies del resto de usuarios.
• Inyectar código que redirecciona la página web a una página externa.
• Realizar un deface a la interfaz con el propósito de estropear el diseño web.
• Troyanizar un gran número de navegadores de usuarios, tomando un control remoto sobre muchos navegadores.

En el nivel de seguridad low el código fuente vulnerable es el que se muestra a continuación:

Este script recoge la información enviada a través del siguiente formulario, en el que los visitantes de la web pueden dejar un mensaje con su nombre (a modo de libro de visitas). Ambos campos son filtrados con la función trim() y mysql_real_escape_string() antes de ser insertados en la base de datos.

Así mismo, el campo correspondiente al mensaje pasa por la función stripslashes() para eliminar las barras en caso de que el mensaje contenga comillas escapadas. Sin embargo no se realizar ningún filtrado para eliminar código HTML que pudiera contener el mensaje…

Una vez que se pulsa en el botón de envío del formulario, el nombre y el mensaje quedan grabados en la base de datos y al volver a cargar la página se mostrarán bajo dicho formulario:

Para comprobar si es vulnerable a XSS en el campo textarea mtxMessage esta vez introduciremos un tag HTML con el que lanzar una ventana de alerta Javascript:

<script> alert("Vulneravilidad low")</script>

El resultado de esta acción es que el mensaje se ha guardado correctamente en la base de datos y en cada carga de la página del libro de visitas se muestra la alerta esperada:

Un usuario mal intencionado podría, por ejemplo, provocar un deface del sitio web, modificando la estructura de la página pudiendo llegar en algunos casos a hacer ilegible su contenido.
Por ejemplo, inyectar:

</div></div></div></div><div>Qué lástima

provocaría un cambio en la estructura HTML de la página web y, por consiguiente, del aspecto general de la página web:

En el nivel de seguridad medium el código difiere nivel low en el uso de la función strip_tags() para eliminar los tags HTML que pudiera contener el mensaje y el uso de str_replace() para eliminar la etiqueta <script> del campo correspondiente al nombre:

Mediante la combinación de las funciones strip_tags() y htmlspecialchars() el ataque a través de este campo textarea ha quedado sin efecto como se comprueba en la siguiente figura:

Por su parte, el campo input correspondiente al nombre no es seguro. El único filtro antes de ser insertado a la base de datos es el realizado con la función str_replace() para eliminar coincidencias con el tag <script>. Esta medida se muestra insuficiente debido a que podría hacer uso del mismo tag con la adición del parámetro type, con lo que ya no se produciría coincidencia y pasaría el filtro. Es más, podría incluso inyectarse cualquier otro tag HTML.

Sin embargo, el código HTML del formulario no permite la inserción de más de 10 caracteres.

<input type="text" maxlength="10" size="30" name="txtName">

Esta limitación no supone un problema puesto que, como vimos en la vulnerabilidad CSRF, Firebug permite la edición inline del código fuente de una página web, por lo que a través de esta herramienta eliminaremos ese parámetro del campo input y, por consiguiente, se podrá inyectar cuanto texto permita el tipo de campo definido en la base de datos.

<SCRIPT language="javascript">window.location="http://webexterna.com";</SCRIPT>

Como se observa en la siguiente figura, la entrada con el código inyectado fue insertada en la base de datos:

Una vez inyectado el código, cada vez que algún usuario intenta cargar la página web, es redireccionado a la página principal del buscador Google España.

Si el filtrado no permitiera la inserción del tag <script> en ninguna de sus formas, se podría haber inyectado la etiqueta <meta> para provocar este mismo efecto:

<html><meta http-equiv="refresh" content="0;url=http://www.google.es/"></html>

Prevención

Para evitar este tipo de vulnerabilidad se recomienda filtrar siempre la información procedente del usuario antes de hacer uso de ella. Generalmente con filtrar los caracteres “<” y “>” sería suficiente, aunque se recomienda también filtrar los nombres de las etiquetas que pueden resultar peligrosas en este tipo de ataque como <script>, <object>, <applet>, <embed> y <form>.

Por su parte, DVWA en el nivel de seguridad high hace uso de las funciones stripslashes(), mysql_real_escape_string() y htmlspecialchars().

Las medidas de seguridad para filtrar la información recibida del formulario son las mismas que en el caso de la vulnerabilidad XSS reflejected con la diferencia de que también ejecuta la función mysql_real_escape_string() antes de insertar la información en la base de datos.

Otra contramedida enfocada a los propios usuarios de páginas web es la de tener el navegador lo más actualizado posible. Por ejemplo el navegador Internet Explorer a partir de su versión 8, introduce como novedad un filtro Anti XSS que detecta posibles manipulaciones de la página mediante la inyección de código en un parámetro de la URL.

Manejo de Roles y Permisos en Jenkins

Manejo de Roles y Permisos en Jenkins

Prerrequisitos

Para poder tener un buen sistema de usuarios y roles, es necesaria la instalación de los siguientes plugins:

Matrix Authorization Strategy Plugin -

http://wiki.jenkins-ci.org/display/JENKINS/Matrix+Authorization+Strategy+Plugin

Role-based Authorization Strategy -

http://wiki.jenkins-ci.org/display/JENKINS/Role+Strategy+Plugin

Creación de Roles

Para ir a la Gestión de Roles dentro de Jenkins hay que ingresar en: “manager Jenkins” -> “Manage and Assign Roles” - > “Manage Roles”:
Se puede definir roles a nivel global, a nivel de proyecto o a nivel de slave, pero para una primer instancia solo es necesario generar roles a nivel global.

Veremos tres roles definidos admin, developer y líder, estos serán designados según categoría de cada usuario. Permitiendo a los developer ver resultados y ejecutar cualquier tarea en Jenkins, el rol líder puede hacer lo mismo que el developer además de poder crear, configurar y borrar tareas. El rol admin tiene todos los permisos.

Asignar Roles a los usuarios

Para poder asignar roles hay que ir a: “manager Jenkins” -> “Manage and Assign Roles” - > “Assing Roles”:

Solo es necesario poner el nombre de usuario y luego agregarlo a la lista, para posteriormente a agregarse a la lista poder asignarle el rol correspondiente.

Existen usuarios genéricos, donde se les puede definir el rol, para todos los usuarios que complan con la misma condición:

Anonymous: Es el usuario genérico que se utiliza para cualquier usuario que ingrese al sistema sin estar logueado.

Authenticated: Es el usuario que por medio del LDAP se autentica al servidor Jenkins y no tiene ningún permiso especial asignado.