martes, 1 de diciembre de 2015

Ejercicio de Cipher Block Chaining

A continuación se presenta un ejercicio del CBC (Cipher Block Chaining). En este caso, tomando
como dato a cifrar uno en hexadecimal, que luego es convertido a binario y ya sobre el cuál se trabaja.

Para poder llevar a cabo el cifrado, el dato en binario se divide en bloques de 8 bits, a los cuales se les denomina "p", después se prosigue llevando a cabo el cifrado de cada uno de los bloques comenzando por p1, donde primero se le realiza un XOR con el vector de inicialización (IV) para después hacer un FES con las claves de AND1, OR2 y NOT, con lo que se obtiene C1, posteriormente se cifra el siguiente bloque, pero en este caso haciendo XOR con la C anterior y después aplicando un FES con las mismas operaciones clave y obteniendo así la siguiente C.

Todo ese proceso se repite ocho veces hasta obtener las 8 Cs.

Ahora para el descifrado, se parte de la primer C, se le aplica un FES inverso para descifrarla y al resultado se le hace un XOR con el vector de inicialización, que por resultado debe dar el bloque que se cifró, es decir las Ps, para las siguientes Cs, se aplica el mismo proceso, sólo que haciendo el XOR con la C anterior. Y finalmente para comprobar esto, cada descifrado tiene que dar exactamente lo mismo que cada una de las P.

Con esto queda realizado el CBC de manera exitosa.



domingo, 15 de noviembre de 2015

La maquina enigma y el cifrado por bloques

Maquina Enigma.

La máquina Enigma fue inventada por un ingeniero alemán, Arthur Scherbius, Su idea consistía en aplicar el Cifrado de Vigenère, es decir se aplicaba un algoritmo de sustitución de unas letras por otras.

Al no contar con recursos para fabricarla, se asoció con Willie Korn quien tenía una compañía llamada Enigma Chiffiermaschinen AG en Berlín. Mejoraron el diseño y en 1923 la presentaron en la Exhibición Postal Internacional de Berlín para el cifrado de secretos comerciales.

La máquina enigma era electromecánica, es decir que una parte de su funcionamiento era mecánica, mientras que la otra era eléctrica, consistía en una serie de teclas con las letras del alfabeto, similar a una máquina de escribir, que en realidad eran interruptores que accionaban los dispositivos eléctricos y hacían mover unos cilindros rotatorios. Desde el punto de vista del operador, la forma en que funcionaba era bastante simple, tenía que teclear las letras de su mensaje y anotar las letras que devolvía la máquina (a través de un alfabeto que se iba iluminando).

El código a usar se fijaba con las posiciones de los cilindros que constaban, cada uno, de 26 cables que se conectaban al teclado pero, con la particularidad, que el primer cilindro giraba un veintiseisavo de vuelta después de cada pulsación, de tal manera que la posición de las conexiones iba cambiando con cada entrada del teclado, obteniendo un cifrado polialfabético.

Sumado a esto, el segundo cilindro sólo daba un giro cuando el primero había completado 26 giros y el tercero cuando el segundo había dado sus 26 y añadió la posibilidad de que los rodillos pudiesen ser intercambiados de posición, de manera que el número de posibilidades aumentase hasta tener 105,456 alfabetos.

Además, el sistema contaba con 6 cables de conexión que también permitían introducir modificaciones dado que podrían conectarse a 26 lugares (representando a las 16 letras del alfabeto de Enigma) lo que producía 100.391.791.500 maneras distintas de conectar los cables que unidos a los 105.456 alfabetos daba un total de:

3,283,883,513,796,974,198,700,882,069,882,752,878,379,955,261,095,623,
685,444,055,315,226,006,433,616,627,409,666,933,182,371,154,802,769,920,000,000,000 posibilidades distintas de codificación.

En 1933 Alemania nacionalizó a la compañía creadora de ésta máquina, y posteriormente procedió a armar a todo su ejército con ella, además de agregarle un cuarto cilindro para complicar aún más el intento de descifrar los mensajes.

Desde que obtuvieron esta máquina, el ejército nazi obtuvo una gran ventaja debido a que sus códigos eran prácticamente indescifrables y así tomaban la ventaja en el campo de batalla al poder envíarse mensajes sin el temor de que los aliados los interceptáran y los descifraran.

Sin embargo y a pesar de todos los mecanismos que utilizaba la máquina enigma, eventualmente fue vencida debido a los principales factores:

  • Al haber sido en un inicio un producto comercial que fue presentado al público dentro de lo que cabe, la información de cómo operaba de manera esencial era conocida.
  • La codificación de un mensaje obligaba al operador a introducir 3 letras dos veces cuando se iniciaba el mensaje, en un estilo de bandera, el ejército nazi no modificaba esa secuencia, por lo que se convirtió en una constante que aprovecharon los aliados para descifrar los códigos.
  • Los aliados lograron capturar un submarino Alemán, con lo cual lograron obtener una máquina enigma y el libro de claves, pero hicieron la captura para el público como que el submarino se terminó hundiendo para así evitar que cambiaran las claves.
Debido a todos esos factores es que fue posible para los aliados derrotar a la máquina enigma y descifrar los mensajes de los alemanes, éstos intentaron recuperar la ventaja con su sucesora, la M4, pero los aliados crearon un computador llamado "Colossus" que fue diseñado para descifrar sus mensajes.

Al final de día, la máquina enigma terminó teniendo una mayor repercusión de lo que se podría pensar, dado que más allá de su uso militar, fue la causante de la creación de las primeras computadoras, que ya en el futuro se convertirían el todo lo que conocemos hoy en día.


Cifrado por bloques.

Una unidad de cifrado por bloques es una unidad de cifrado de clave simétrica que opera en grupos de bits de longitud fija (bloques), aplicándoles una transformación invariante.

Cuando se hace el cifrado, se toma como entrada un bloque de texto plano (o claro) y produce un bloque cifrado de igual tamaño. La transformación exacta es controlada utilizando una segunda entrada, ésta es la clave secreta dada por el usuario. Para realizar el proceso inverso (descifrado), se ingresa un bloque de texto cifrado y se produce el texto plano original.

El cifrado por bloques es diferente al cifrado por flujo (stream ciphers) debido a que, en este último, se opera en dígitos individuales, uno tras otro, y la transformación varía durante el proceso de cifrado.
 
Un ejemplo de cifrado por bloques conocido, es el llamado DES (Data Encryption Standard), que fue un diseño de unidad de cifrado por bloques de gran influencia. Fue desarrollado y publicado por IBM y se volvió un estándar en 1977, éste tuvo un sucesor, el Advanced Encryption Standard (AES), que fue adoptado en 2001.

Funcionamiento del cifrado por bloques.

Se emplean bloques de tamaño fijo del texto en claro y se crea un bloque de tamaño fijo de texto cifrado, por lo general de igual tamaño que la entrada. Dicho tamaño de bloque debe ser grande, para evitar ataques de texto cifrado, mientras que la asignación de bloques de entrada a bloques de salida debe ser uno a uno, para que el proceso reversible y parezca aleatorio. 

Para la asignación de bloques, los algoritmos de cifrado simétrico realizan sustituciones y permutaciones en el texto en claro hasta obtener el texto cifrado. La sustitución es el reemplazo de un valor de entrada por otro de los posibles valores de salida. La permutación es un tipo especial de sustitución en el que los bits de un bloque de entrada son reordenados para producir el bloque cifrado, esto es para preservar las estadísticas del bloque de entrada (el número de unos y ceros). 

Finalmente, los algoritmos de cifrado por bloques iterativos funcionan aplicando una transformación (función de rotación) sucesivas veces a un bloque de texto en claro. La cantidad de "rotaciones" depende del nivel de seguridad buscado. Se aplica una misma función a los datos usando una subclave obtenida de la clave secreta original dada por el usuario. 

Para implementar un algoritmo por bloques, se necesita romper el texto de entrada en bloques de longitud fija. Esto puede hacerse de cuatro formas: 
  • ECB (Electronic Code Book).
  • CBC (Cipher Block Chaining). 
  • OFB (Output Feedback Mode). 
  • CFB (Cipher Feedback Mode) 
CBC (Cipher Block Chaining) 

En el Cipher Block Chaining, a cada bloque de texto plano se le aplica la operación XOR con el bloque cifrado anterior antes de ser cifrado. De esta forma, cada bloque de texto cifrado depende de todo el texto en claro procesado hasta este punto. Para hacer cada mensaje único se utiliza asimismo un vector de inicialización. Es útil para transmisiones orientadas a bloques. Sin embargo, debido a este tipo de funcionamiento, no es posible realizar operaciones de cifrado en paralelo sobre varios bloques por esta dependencia de cada bloque con la operación del anterior.


CFR (Cipher Feedback).

Para comprender la forma en que funciona el CFR, es necesario primero conocer el funcionamiento del OFB (Output Feedback Mode) y a su vez, para éste es necesario el CTR (Counter Mode).

CTR simula un cifrado de flujo. Es decir, se usa un cifrado de bloque para producir un flujo pseudo aleatorio conocido como keystream. Este flujo se combina con el texto plano mediante XOR dando lugar al cifrado.

Para generar el keystream se cifra un contador combinado con un número aleatorio ("nonce") mediante ECB (Electronic Code Book Mode) y se va incrementando. El valor del contador puede ser públicamente conocido, y es necesario que el valor de nonce + contador lo conozcan ambos lados de la comunicación.

Una de las ventajas que ofrece es la posibilidad de precalcular el keystream (y/o trabajar en paralelo).

Como desventajas hay que tener en cuenta que reutilizar un contador en la misma clave puede ser desastroso, pues se generará de nuevo el mismo keystream. Modificar bits en el texto plano es muy sencillo, porque al modificar un bit del cifrado se modificará el bit del texto plano correspondiente (Bit-flipping attacks). Debido a esto es aconsejable usar el modo de cifrado junto con una verificación de la integridad del mensaje.

Ahora, la forma en la que funciona el OFB es muy similar al CTR, nada más que el keystream se genera cifrando el bloque anterior del keystream, dando lugar al siguiente bloque. El primer bloque de keystream se crea cifrando un vector de inicialización IV.

Conociendo esto, ya puede entenderse que el CFB funciona de manera similar a los dos anteriores, únicamente que para producir el keystream se cifra el último bloque de cifrado, en lugar del último bloque del keystream como hace OFB, pero por todo lo demás comparte las vulnerabilidades de éste, y por lo tanto del CTR.


Método de distribución de claves.

La distribución de claves es una de las partes más delicadas con las que se debe de lidiar al momento de trabajar con este tipo de sistemas, dado que si se lleva a cabo de una manera inadecuada, todo el trabajo que se hizo en el cifrado, valdría para absolutamente nada, debido a que se conocerían las llaves para obtener toda la información de lo que se quiere proteger.

El
 protocolo
 
IEEE802.10 muestra
 tres
 tipos 
de
 técnicas 
de 
distribución
 de 
claves, 
las
 cuales
 son:
 distribución
 
 manual
 de
 claves,
 distribución
 centralizada
 de
 claves
 y
 distribución
 certificada
 de 
claves.
Distribución manual de claves.

Las
 técnicas
 de
 distribución
 manual
 de
 claves
 utilizan
 procedimientos
 de
 entrega
 fuera
 de
 línea
 para
 establecer 
contraseñas 
compartidas
 en
 parejas
 o
 en 
grupos,
 esto
 es,
 se
 apoyan
 en 
métodos
 tradicionales 
(seguridad
 física
 y
 de 
confianza,
 correos 
seguros).

Distribución centralizada de claves.

Este
 tipo
 de
 distribución
 se
 hace
 necesaria 
cuando
 se
 requiere
 que
 ésta
 se
 lleve
 a
cabo
 sobre
 la
 misma
 red
 de
 comunicación
 donde
 se
 está
 transmitiendo
 la
 información
 que
 se
 va
 a
 proteger,
 cuando
 se
 necesita
 establecer
 contraseñas
 seguras
 entre
 parejas
 o
 en
 multidifusión
 entre
 entidades
 en
 comunicación
 y
 que
 se
 realice
 de
 manera
 automática,
 entonces
 la
 entrega 
se
 hace
 mediante
 una
 tercera
 entidad
 de
 confianza
 la
 cual
 puede
 ser
 un
 centro
 de
 distribución
 y
 trabajar
 conjuntamente
 con
 un
 centro
 traductor
 de
 claves.

Distribución certificada de claves.

Se 
emplea
 principalmente para
 realizar
 comunicaciones
 seguras 
entre
 parejas
 de
 interlocutores.
 En
 este
 contexto
 se
 identifican
 principalmente
 dos
 clases
 de
 técnicas
 de
 distribución:
 las
 cuales
 se
 conocen
 normalmente 
como
 transferencia
 de
 claves
 y
 acuerdo
 o
 intercambio
 de 
claves.

  • Transferencia de Claves: La 
entrega
 o
 distribución 
se
 realiza
 a
 través
 de
 un
 criptosistema
 público
 a
través 
del
 cual
 se
 cifra 
una 
clave 
generada 
localmente
 en
 la 
entidad
 u 
organismo
 encargado
 de
 esta
 tarea
 así,
 la 
clave
 viajará
 protegida 
hasta
 la 
entidad 
remota
 de
 gestión
 de
 claves
 para
 su 
uso.
  • Acuerdo o Intercambio de Claves: 
La
 clave
 a 
utilizar 
para
 la
 comunicación
 se 
genera
 con
 la
 participación
 de 
las
 entidades
 involucradas, 
esto
 es,
 la
 entidad 
que 
requiere 
dicha 
clave
 y
 la
 encargada
 de
 la 
generación 
de 
claves
 (la
 entidad 
local
 y
 la
 entidad 
remota).
http://hipertextual.com/2011/07/la-maquina-enigma-el-sistema-de-cifrado-que-puso-en-jaque-a-europa

http://www.alegsa.com.ar/Dic/cifrado%20por%20bloques.php

http://enciclopediateleco.blogspot.mx/2014/12/modos-de-operacion-ecb-cbc-cfb-ofb-y.html

http://dlerch.blogspot.mx/2007/07/modos-de-cifrado-ecb-cbc-ctr-ofb-y-cfb.html

http://www.openboxer.260mb.com/asignaturas/criptografia/distribucionDeClaves.pdf?ckattempt=1

martes, 10 de noviembre de 2015

Pruebas de Caja Negra

La prueba de caja negra lo que permite obtener es un conjunto de condiciones de entrada para así poder probar los funcionamientos de un sistema. A diferencia de la caja blanca que se enfoca en analizar cada uno de los caminos que puede recorrer el programa y ver qué hace en cada uno de ellos, en la caja negra, como bien dice su nombre, no se va a poder observar qué es lo que ocurre dentro de la caja (programa), sólo se va a poder observar qué es lo que entra y qué es lo que sale. Es debido a esto que este tipo de pruebas tienen ese nombre, y podría considerarse que son complementarias entre si, normalmente llevando a cabo primero la de caja blanca y después la de caja negra.

La utilidad de las pruebas de caja negra es bastante notoria, y dentro de las utilidades que ofrece, se encuentra el encontrar:
  • Funciones incorrectas o ausentes.
  • Errores de interfaz.
  • Errores en estructuras de datos o en accesos a las Bases de Datos externas.
  • Errores de rendimiento.
  • Errores de inicialización y terminación.
Dentro de las pruebas de caja negra, existen principalmente 4 técnicas para llevarlas a cabo:
  • Método Gráfico.
  • Partición Equivalente.
  • Análisis de Valores Límite.
  • Tabla Ortogonal
Método Gráfico.

El método gráfico de caja negra, como bien dice su nombre se basa en tomar el programa en cuestión y hacer una representación gráfica del mismo, con la diferencia respecto a la caja blanca, de que aquí el enfoque va a ser principalmente a los objetos que conforman el programa y lógicamente, las entradas y las salidas.

Existen 5 tipos de modelados que se pueden utilizar en esta técnica, los cuales son:
  • Modelado del flujo de transacción: Los nodos representan los pasos de alguna transacción, y los enlaces representan las conexiones lógicas entre los pasos.
  • Modelado de estado finito: Los nodos representan diferentes estados del software observables por el usuario, y los enlaces representan las transiciones que ocurren para moverse de estado a estado.
  • Modelado de flujo de datos: Los nodos son objetos de datos y los enlaces son las transformaciones que ocurren para convertir un objeto de datos en otro.
  • Modelado de Planificación: Los nodos son objetos de programa y los enlaces son las conexiones secuenciales entre esos objetos. Los pesos de enlace se usan para especificar los tiempos de ejecución requeridos al ejecutarse el programa.
  • Gráfica Causa-efecto: La gráfica Causa-efecto representa una ayuda gráfica en seleccionar, de una manera sistemática, un gran conjunto de casos de prueba. Tiene un efecto secundario beneficioso en precisar estados incompletos y ambigüedades en la especificación. Un gráfico de causa- efecto es un lenguaje formal al cual se traduce una especificación.
Con estos 5 tipos de modelados, es posible utilizar la técnica del método gráfico de una manera versátil y así permitir que se adapte a nuestras necesidades.

Partición Equivalente.

Lo que se hace en esta técnica, es dividir los datos de entrada en clases de equivalencia, esto quiere decir que dependiendo del tipo de dato que teóricamente acepta el programa, se creen clases de equivalencia de datos que sean válidos para lo que está esperando el programa e inválidos para el mismo:
  1. Si una condición de entrada específica un rango de datos, existen 3 clases de equivalencia; dentro del rango (válido), debajo del rango (inválido) y por encima del rango (inválido).
  2. Si la condición de entrada especifica un valor, existen 3 clases de equivalencia; el valor (válido), debajo del valor (inválido) y por encima del valor (inválido).
  3. Si la condición de entrada especifica a un miembro de un conjunto, existen 2 clases de equivalencia; dentro del conjunto (válido) y fuera del conjunto (inválido).
  4. Si la condición es booleana, existen 2 clases de equivalencia, verdadero y falso.

Análisis de Valores Límite.

Como dice su nombre, esta técnica maneja los valores límite que puede aceptar el programa, de cierta forma es algo similar a la partición equivalente, nada más que en este caso los datos de entrada con los que se trabajan se encuentran al borde de lo que puede aceptar el programa antes de provocar un error en su funcionamiento (aunque también puede utilizar los que están fuera de lo que puede aceptar, pero se acercan a ello), por ejemplo si un programa aceptara valores desde 1 hasta 10, el análisis de valores límite crearía los casos de prueba en base a los valores límite, es decir, tomando como datos 1 y 10, además de posiblemente, un 0.99 y un 10.1111, dado que así probaría los valores límite de la clase de equivalencia inválida para el programa.

Una característica que no debe olvidarse es que como se observó, en esencia se puede decir que el análisis de valores límite lo que hace es probar los extremos de cada clase de equivalencia que se podrían obtener para el programa.

Tabla Ortogonal.

Existen programas en donde el número de parámetros de entrada es pequeño y los valores de cada uno de los parámetros está claramente delimitado (es decir, no sé tiene que lidiar con un gran rango de posibilidades de datos de entrada). Cuando estas posibilidades son muy pocas, la prueba de tabla ortogonal permite proporcionar una buena cobertura de pruebas con bastantes menos casos de prueba que en la estrategia exhaustiva, esto debido más que otra cosa a que resultaría innecesario llevar a cabo una precisamente porque las posibilidades de entrada y salida del programa son muy pocas.

Fuentes:

http://www.innosupport.net/index.php?id=2084&L=6

http://www.innosupport.net/index.php?id=2080&L=6

http://www.ecured.cu/index.php/Pruebas_de_caja_negra

http://avanzada.idict.cu/index.php/avanzada/article/view/357

domingo, 8 de noviembre de 2015

Prueba aplicada a un pseudocódigo

El siguiente es el pseudocódigo al cual se le aplicará la prueba, en particular la prueba de caja blanca:

































Como puede verse, este pseudocódigo describe un proceso que acepta variables, les aplica procesos y al final devuelve otras.

Ahora, como se van a indicar con número cada proceso que lleva a cabo el código, el pseudocódigo marcado quedaría así:





Lo primero que debe de hacerse para aplicar la prueba es tomar este pseudocódigo y representar el proceso que describe de manera gráfica, en un principio a manera de diagrama de flujo y con cada uno de sus componentes con su numero de proceso (Se debe tener en cuenta que la union de los if, cuanta como el final del if, por lo tanto de un proceso.):


Con esto ya puede verse de manera gráfica cómo funciona el programa, ahora el siguiente paso es pasar el diagrama de flujo a un grafo utilizando nodos para representar cada proceso del programa:


Ya con este grafo, lo que se debe de hacer para aplicar la prueba de caja blanca, es analizar el grafo para determinar el número de caminos que existen en el proceso, con el objetivo de saber cuántos caminos tiene en total (complejidad ciclomática) y así determinar qué datos deben de ingresarse para recorrer cada camino y así probar la funcionalidad de los mismos.
  1. 1, 4, 10, 11, 13
  2. 1, 4, 10, 12, 13
  3. 1, 4, 5, 8, 9, 2, 4, 10, 11, 13
  4. 1, 4, 5, 6, 7, 8, 9, 2, 3, 4, 10, 11, 13
  5. 1, 4, 5, 8, 9, 2, 4, 10, 12, 13
  6. 1, 4, 5, 6, 7, 8, 9, 2, 3, 4, 10, 12, 13
Como se puede observar, existen 6 caminos que el programa puede recorrer durante su ejecución y llegar hasta el final, sin embargo algo que debe de tenerse en cuenta, es que es posible encontrar más caminos, pero éstos van a volverse redundantes en el sentido de que una secuencia del camino se va a repetir, y por lo tanto ya no sería válido.


Ahora una vez que tenemos los caminos, lo que se debe hacer es determinar los datos que deben de ingresarse para que el programa recorra todos los caminos.

Al analizar el programa, puede verse que acepta cuatro datos: valor, minimo, maximo y suma, sin embargo se puede observar que después se declara la variable de valor como un arreglo y se le dice que sus valores van a ser de 1 a 100, mientras que con suma, en una línea se iguala a 0, por lo tanto no tiene importancia qué valores se ingresen en estos campos, los únicos que sí importan es mínimo y máximo, sin embargo con estos dos campos sólo pueden recorrerse dos caminos:
  • mínimo: 2, maximo: 5
  • minimo: 0, maximo: 99
Como el resto de los caminos dependen de las condiciones de total.entrada y el valor de la variable valor en la posición i, para poder recorrerlos va a ser necesario forzar ciertas variables o condiciones, en este caso sería:
  • total.entrada = 99
  • total.entrada = 101
  • i = -999
  • i = -1000
Forzando esas condiciones, ya es posible recorrer el resto de caminos porque ya se pueden manipular las condicionales, y con esto se recorren todos los caminos y se verifica que cada uno de ellos funcione, es decir así ya se aplicó la prueba de caja blanca.

domingo, 18 de octubre de 2015

Características de las Pruebas

Las pruebas que se deben llevar a cabo a lo largo del desarrollo de un software, además de tener una clasificación en base a su función y un orden en el que deben llevarse a cabo, también poseen ciertas características generales que se aplican a todas, las cuales si se cumplen satisfactoriamente facilitan la aplicación de esas pruebas, e incrementan su efectividad.

Esas características son:
  1. Ser fácil: Como su nombre lo dice, simplemente indica que la prueba debe de ser fácil de llevarse a cabo, o aplicarse.
  2. Tener operatividad: Este aspecto quiere decir que mientras mejor hecha y más compleja sea la prueba en sí, va  a ser más fácil poder aplicarla para que encuentre los errores rápidamente.
  3. Ser observable: Se refiere a que mientras se esté llevando a cabo una prueba, ésta va a tener entradas, salidas y uno o varios procesos, el ser observable quiere decir que todos estos elemento se saben y pueden analizarse.
  4. Controlable: El que la prueba sea controlable indica que se tiene acceso y por lo tanto se pueden modificar las variables con las que ésta esté trabajando según vaya siendo necesario.
  5. Capacidad de Descomposición: De la misma forma que un sistema está formado por módulos, la capacidad de descomposición de las pruebas quieren decir que sea capaz de probar módulos independientes de manera independiente, es decir que el resultado de la prueba de un módulo no afecte al de los demás.
  6. Simple: Se refiere a que esté hecha de manera tal que hacer el set de pruebas y aplicarlo para ponerla en funcionamiento no sea complicado y se pueda llevar a cabo con rapidez.
  7. Estable: Quiere decir que aunque se tengan que llevar a cabo ajustes o cambios ya sea en el sistema que se está probando o en la prueba en sí, ésta siga funcionando adecuadamente o que no sea necesario rehacerla completamente desde cero.
  8. Facilidad de Comprensión: De manera sencilla, esta característica quiere decir que la prueba debe de ser fácil de entender en el sentido de entender qué es lo que está probando y de qué forma lo está haciendo.
Si una prueba cumple con todas estas características, será mucho más probable que su efectividad esté garantizada y cumpla correctamente con su función.

Ahora hablaremos un poco de dos pruebas en específico que están enfocadas a un aspecto que se menciona en la tercer característica, las entradas, salidas y procesos. Estas son las llamadas "Pruebas de Caja Blanca" y "Pruebas de Caja Negra":

Prueba de Caja Blanca.

La prueba de caja blanca se basa en el diseño y uso de casos de prueba que estén hechos en base al software o sistema a probar, es debido a esto que la prueba de caja blanca ofrece las siguientes características:
  1. Garantizar que se ejecuten por lo menos una vez todos los caminos independientes de cada módulo.
  2. Llevar a cabo todas las ramificaciones lógicas de verdadero o falso.
  3. Ejecutar todos los bucles en sus límites operacionales.
  4. Ejecutar estructuras internas de datos para garantizar su validez.
Estas características de la prueba de caja blanca nos dan a entender que al diseñar los casos de prueba en base al propio diseño de lo que se va a probar, se puedan recorrer todos los caminos que de los que disponga para asegurar que funcionen correctamente. Existe una técnica para llevar a cabo esta prueba, conocido como "Prueba del camino básico".

Prueba de camino básico.

Esta prueba en una técnica desarrollada por Tom McCabe para llevar a cabo pruebas de caja blanca, la idea del camino básico es primero comprender el diseño del sistema y representarlo a manera de grafo, para que ya con éste se puedan diseñar los casos de prueba que fuercen cada camino. Los pasos a seguir son los siguientes:
  1. A partir del diseño o código fuente, hacer la representación gráfica del flujo en cuestión a manera de grafo.
  2. Calcular la complejidad ciclomática del grafo.
  3. Determinar conjunto básico de caminos independientes.
  4. Preparar los casos de prueba que obliguen a la ejecución de cada camino del conjunto básico.
Ejecutando cada uno de los pasos, se logra hacer una prueba que ejecute cada camino que puede seguir el programa, es decir una prueba de caja blanca.

En el primer paso se necesita crear un grafo del flujo del programa utilizando su diseño o código fuente, este grafo tiene 3 elementos fundamentales para su construcción:
  • Nodo: Básicamente representa una o más secuencias procedimentales, una sentencia de decisión o una secuencia de procesos.
  • Aristas: Son las flechas que se utilizan para unir cada nodo y representan el flujo de control del programa.
  • Regiones: Son las áreas delimitadas por las aristas y nodos, contando también el área del exterior del grafo, cada una de estas regiones se enumeran y el numero de regiones es equivalente a la cantidad de caminos independientes del conjunto básico de un programa.
Otro aspecto que se debe conocer es la denominada "Complejidad Ciclomática", ésta es una métrica del software que proporciona una medición cuantitativa de la complejidad lógica de un programa, en esencia el valor que nos dé indica el límite superior para el número de pruebas que se deben realizar para asegurar que se ejecute cada sentencia por lo menos una vez.

Prueba de Caja Negra.

La prueba de caja negra permite obtener un conjunto de condiciones de entrada que lleven a cabo completamente todos los requisitos funcionales de un programa, en ellas se ignora la estructura de control, sino que se concentra en los requisitos funcionales del sistema y los ejecuta.

Se considera como un complemento a la prueba de caja blanca, y dentro de las características que ofrece se encuentra el permitir encontrar:
  1. Funciones incorrectas o ausentes.
  2. Errores de Interfaz.
  3. Errores en estructuras de datos o en accesos a las bases de datos externas.
  4. Errores de rendimiento.
  5. Errores de inicialización y terminación.
Para preparar los casos de prueba necesarios, se necesitan un número de datos que ayuden a la ejecución de los casos y que le permitan al sistema correr en todas sus variantes, estos datos pueden ser válidos o inválidos dependiendo de si se quiere encontrar un error o probar una funcionalidad.

Para desarrollar una prueba de caja negra existen diversas técnicas, algunas de ellas son:
  • Técnica de la Partición de Equivalencia: Divide el campo de entrada en clases de datos que ejecutan determinadas funciones del software.
  • Técnica del Análisis de Valores Límite: Prueba la habilidad del programa de manejar datos que se encuentren dentro de los límites aceptables.
  • Técnica de Grafos de Causa-Efecto: Permite validar complejos conjuntos de acciones y condiciones.
La técnica más utilizada en las prueba de caja negra es la de partición de equivalencia, dado que permite examinar los valores válidos e inválidos de las entradas existentes en el software y así descubrir más rápidamente errores que podrían tomar más tiempo de encontrar utilizando otro método.

Con esto se puede concluir que las pruebas de caja negra y blanca son complementarias entre si, mientras que la primera se enfoca en las entradas y las salidas, la segunda se enfoca en los caminos que sigue el programa en cada caso, así en conjunto son una prueba muy completa del diseño y funcionalidad de un programa.


http://gemini.udistrital.edu.co/comunidad/grupos/arquisoft/fileadmin/Estudiantes/Pruebas/HTML%20-%20Pruebas%20de%20software/node27.html

http://testingfuncional.wordpress.com/2011/03/12/%C2%BFtesting-funcional-o-pruebas-de-caja-negra/

http://www.ecured.cu/index.php/Pruebas_de_caja_blanca

PRESSMAN, ROGER S. Ingenieria de Software Un Enfoque Práctico

viernes, 9 de octubre de 2015

Prueba de resistencia a una bicicleta

Dentro de las pruebas que se llevan a cabo en un software, se encuentra una llamada "Prueba de Resistencia", esta prueba como su nombre dice, se refiere a probar la capacidad de resistencia del software, principalmente frente a la sobrecarga de información y solicitudes para poder lidiar con ello sin colapsar, sin embargo para ilustrar de manera más sencilla este tipo de prueba, se llevará a cabo con una bicicleta.

Una prueba de resistencia con una bicicleta se podría llevar a cabo de dos formas:
  • Desde el punto de vista del fabricante.
  • Desde el punto de vista del comprador.
Fabricante

La prueba de resistencia que llevaría a cabo el fabricante sería durante la construcción de la bicicleta, y lo que se llevaría a cabo sería someter a la bicicleta a distintas situaciones "extremas", esto se refiere a:
  • Choques con distintos materiales.
  • Resistencia de las cadenas.
  • Aguante de las llantas.
  • Aguante de frenos.
  • etc.
En esencia lo que haría esta prueba sería someter a la bicicleta, o más específicamente a cada una de sus partes a una situación "extrema", en la cual esa parte en específico tiene que lograr cumplir con la función sin romperse, por ejemplo el esqueleto de la bicicleta debería de aguantar choques contra metal, paredes de distintos materiales, autos, etc, intentar frenar a velocidades muy altas, someter a las llantas a distintas superficies, etc. Toda aquella situación a la que se podría enfrentar una bicicleta una vez esté en las manos del comprador, todo esto con el objetivo de ver hasta dónde es capaz de aguantar cada una de sus partes, o la bicicleta entera antes de descomponerse.

Comprador

Del lado del comprador, la prueba de resistencia que éste podría aplicar sobre la bicicleta sería más que otra cosa, someter a la misma al uso más intenso que éste podría aplicarle, porque desde el punto de vista del comprador, la resistencia que va a requerir de la bicicleta es que soporte el uso que éste le va a dar, por lo que la forma en la que probaría la resistencia de la bicicleta sería simplemente utilizándola, tal ves con el agregado de darle el uso más intenso que podría presentarse en circunstancias especiales, pero más allá de eso, el comprador no puede realmente hacer mucho más en cuanto a pruebas de resistencia, más que otra cosa porque no lo necesita.

domingo, 27 de septiembre de 2015

Pruebas de Software

Para poder hablar de las "Pruebas de Software", primero es necesario conocer el proceso mediante el cual son desarrollados los softwares, a este proceso que no solo incluye su periodo de desarrollo, sino también su implementación y manutención, se le llama "Ciclo de Vida del Software" y puede resumirse en la siguiente ilustración:


Pruebas.

Ya una vez conociendo en qué momento de la vida del software se llevan a cabo las pruebas, se puede hablar de que las pruebas pueden entenderse como actividades que se planean con anticipación y se llevan a cabo de forma sistemática, pero al aplicarse al software, necesitan de un plan de pruebas de software, Éstos son procesos en el que se ejecuta un programa con la intención de encontrar un error que aún  o se descubre.


Verificación y Validación.

Cuando se está desarrollando un software y se van aplicando las pruebas, algo que nunca debe perderse de vista es que constantemente debe de llevarse a cabo validaciones y verificaciones, pero ¿Qué significan estos dos conceptos?
  • Validación: En el ámbito del software, la validación es el proceso de revisión al que se somente un programa para comprobar que cumple con sus especificaciones. Esto se realiza con la intención de confirmar que el programa permita llevar a cabo las tareas que sus potenciales usuarios esperan de ella. Éste concepto puede sintetizarse con la pregunta: ¿Se está construyendo el producto correcto?
  • Verificación: Tiene su raíz en el latin "Veriticare" que está compuesto por dos partes: "veritas" (verdadero), y "facere" (hacer). Con esto se entiende que verificación es la acción de verificar, que es comprobar o examinar la verdad de algo, y suele ser un proceso que se realiza para revisar si una determinada cosa está cumpliendo con los requisitos y normas previstos, se puede sintetizar con la siguiente pregunta: ¿Se está construyendo correctamente el producto?

Tipos de Pruebas:
  • Pruebas de Unidad:
    • Son pruebas que lo que hacen es probar una unidad estructural de un código y tienen las siguientes características:
      • Unitarias: Prueban únicamente pequeñas cantidades del código.
      • Independiente: No debe depender ni afectar a otras pruebas unitarias.
      • Prueba métodos públicos: De otra manera la prueba sería frágil a cambios en la implementación y no se podría utilizar en pruebas de regresión.
      • Automatizable: La prueba no debería requerir intervención manual.
      • Repetición y Predecible: No debe incidir el orden y las veces que se repita la prueba, el resultado debe ser siempre el mismo.
      • Profesionales: Deben tener la misma importancia y cuidado que el mismo código.
  • Pruebas de Integración:
    • Su propósito es probar grupos de unidades relacionadas para verificar su operación conjunta, por lo que su énfasis está en la interacción de las partes, no en cada parte individual, gracias a esto son capaces de identificar problemas de interfaces entre unidades y la falta de coherencia entre lo que se espera de una unidad y lo que se ofrece.
  • Pruebas de Validación:
    • Como su nombre lo indica, son pruebas cuyo objetivo es validar lo que se está haciendo, en este caso el software o proyecto, y esta validación debe de llevarse a cabo con la persona que quiere ese software, es decir el cliente para que éste confirme o desmienta que el software en desarrollo cumpla con sus requerimientos y especificaciones.
  • Pruebas de Sistema:
    • Como dice su nombre, el propósito de este tipo de pruebas es poner a prueba el sistema ya en su totalidad, con todas las partes que deben de intervenir en él, tanto la parte de codificación y funcionamiento de cada uno de sus módulos, pasando por la integración de éstos para que funcionen como uno solo, hasta la parte de la interacción de los usuarios con el sistema, podría decirse que lo se hace es probar al sistema en su "ambiente natural".

domingo, 20 de septiembre de 2015

Servicios, Mecanismos y Ataques a la seguridad

Cuando hablamos de seguridad, lo que se da a entender es que nos estamos defendiendo de algo, pero ¿qué es ese algo?, aplicando esta idea a lo que es la seguridad web, tenemos que es necesario que antes de hablar de hablar de mecanismos y servicios de seguridad, se debe de hablar de los ataques a la seguridad y los tipos que existen.

¿Qué es un Ataque?

Para comprender qué es un ataque se debe tener presente el concepto de amenaza, que en términos simples es una vulnerabilidad que se da en el sistema debido a diversas causas y circunstancias, que se podría explotar para generar un ataque.

Con la idea de lo anterior, podemos decir que un ataque es un asalto a la seguridad de un sistema causado por una amenaza previa que fue explotada para así evadir o violar los protocolos de seguridad del sistema y acceder a él con algún propósito.

Tipos de Ataques:
  • Pasivos: Este tipo de ataques se caracterizan porque no alteran la información que se encuentra dentro de un sistema, sino que simplemente se "escucha" u "observa" de manera no autorizada una transmisión de datos, esto normalmente con el objetivo de solamente obtener la información. De este tipo de ataques existen 2 variedades: La obtención de contenido de mensajes y el análisis de tráfico.
    • Obtención de contenido de mensajes: La mayor parte se explica por sí sólo, como su nombre lo dice, se refiere a la obtención de transmisiones que se hacen desde correos electrónicos, llamadas telefónicas, envíos de archivos, etc. En las que se obtiene acceso al contenido enviado en cuestión pero sin alterarlo de alguna forma.
    • Análisis de Tráfico: Es un poco más difícil de explicar pero significa exactamente como suena, se refiere a que cuando se está llevando a cabo una transmisión de datos, se "observa" de dónde está saliendo ese mensaje, el destino de éste, toda la ruta por la cual pasa y la longitud del mismo (sin ver nunca su contenido), esto con diversas finalidades.
  • Activos: Este tipo de ataques implican ya algún tipo de modificación en el flujo de datos, la creación de un flujo falso o incluso la anulación de. Estos ataques se dividen en 4 categorías:
    • Suplantación de Identidad: Como su nombre lo dice, se da cuando una entidad finge ser otra con alguna finalidad.
    • Repetición: Se refiere a la captura de forma pasiva de una unidad de datos para luego retransmitirla y así producir un efecto no autorizado.
    • Modificación de mensajes: Como su nombre lo dice, se refiere a que una parte del mensaje original es alterado de alguna forma para producir un efecto no autorizado.
    • Interrupción del servicio: Impide el uso o la gestión normal de las utilidades de comunicación.
¿Cómo nos defendemos de los ataques?

Una vez conociendo los tipos de ataques que existen, ya se puede hablar de mecanismos y servicios de seguridad para contrarrestar los posibles ataques que se pueden sufrir.

Mecanismos de Seguridad.

Un mecanismo de seguridad como su nombre indica es un mecanismo, pero es uno que está diseñado para detectar un ataque a la seguridad, prevenirlo o restablecerse de él. Existen 7 principales mecanismos:
  1. Firma digital: Son datos añadidos a o una transformación criptográfica de una unidad de datos que permite al receptor verificar la fuente e integridad de datos, y así protegerla de la falsificación.
  2. Control de acceso: Serie de mecanismos que refuerzan los derechos de acceso a los recursos.
  3. Integridad de datos: Verifica la integridad de la unidad de datos o el flujo de unidad de datos.
  4. Intercambio de autenticación: Es un mecanismo diseñado para comprobar  la identidad de una entidad por medio del intercambio de información.
  5. Relleno de tráfico: Se refiere a insertar bits en espacios de un flujo de datos para frustrar los intentos de análisis de datos.
  6. Control de enrutamiento: Permite la selección de rutas físicamente seguras para determinados datos, y permite los cambios de enrutamiento cuando se sospecha de una brecha de seguridad.
  7. Notarización: Es el uso de una tercera parte confiable para asegurar propiedades de un intercambio de datos.
Como puede observarse, los mecanismos de seguridad son medidas que se utilizan para combatir ataques en particular, pero por lo mismo un mecanismo sólo te va a proteger de uno de los varios tipos de ataque que existen, es debido a esto que cuando se implementan medidas de seguridad en un sistema, lo que se utiliza son los servicios de seguridad.

Servicios de Seguridad.

Un servicio de seguridad podría definirse de manera sencilla como un conjunto de uno o más mecanismos (existen mecanismos que al mismo tiempo son servicios) que son utilizados para contrarrestar los ataques y así proporcionar el servicio de seguridad, algunos servicios son los siguientes:
  • Autentificación de Entidades.
  • Autentificación del origen de los datos.
  • Control de acceso.
  • Confidencialidad.
  • Confidencialidad del flujo de tráfico.
  • Integridad de los datos.
  • No repudio.
  • Disponibilidad.
Los siguientes son unos cuadros para representar de manera gráfica los servicios vs ataques, servicios vs mecanismos y mecanismos vs ataques:














































domingo, 13 de septiembre de 2015

Set de Pruebas para un programa que multiplique dos números enteros.

Se llevó a cabo un set de 100 pruebas para, como el nombre sugiere, probar un programa cuya función es multiplicar dos números enteros, el programa en cuestión es el siguiente:















El programa es bastante sencillo, y el código que se va a utilizar para ponerlo a prueba es el siguiente:


















Como se puede notar, la forma en la que se va a probar el programa, es intentando enviarle como parámetros para la ejecución diversos tipos de datos, no únicamente de tipo int como espera recibir el programa, de esta forma se espera que se den errores y para ello se utilizaron los comandos try-catch para imprimir el error en cuestión y que la ejecución no se detenga.

Cada uno de los tipos de datos primitivos de java, que son 8 van a ser probados alrededor de 12 veces utilizando el comando for, el resultado va a ser impreso y así se podrá ver con qué tipos de dato el programa no pudo ejecutarse correctamente. Los resultados de las pruebas son los siguientes:




















Tras ver la ejecución de estas pruebas, puede notarse que únicamente con aquellos datos que eran enteros a pesar de no ser int, el programa funcionó correctamente, mientras que con aquellos datos que eran decimales o aquellos que ni siquiera eran números, el programa falló y se imprimió el error en cuestión, la excepción a esto fueron las pruebas con datos del tipo char, y esto se debe a que en el momento que se creaban los datos, se multiplicaban con un numero entero para que tomara el valor de un carácter del código ASCII, sin embargo al momento de castearlo, el valor que envió fue el numérico del carácter en el código ASCII, no el carácter en sí, es por esto que el programa funcionó a pesar de que teóricamente no debería de haberlo hecho.

Llevar a cabo sets de pruebas es una herramienta muy util, porque con ella podemos de ver que tipo de errores o vulnerabilidades tiene el programa y así durante su construcción corregirlos para que una vez que se lleguen a sus etapas finales de desarrollo, la cantidad de vulnerabilidades que tenga sea mínima y por lo tanto, más seguro.

domingo, 6 de septiembre de 2015

Seguridad Web, Amenazas y Ataques


Introducción: ¿Qué es la seguridad?

Cuando se piensa en la palabra seguridad, vienen a la mente dos principales ideas: prevenir un daño y evitar tener una debilidad. El concepto de seguridad se remota a la misma existencia de nuestra especie, pues desde nuestros antepasados, se veían a los árboles como objetos que nos brindaban seguridad, al impedir que los depredadores nos alcanzaran si es que estábamos en la cima de ellos, las cuevas se veían como lugares que brindaban protección frente a las amenazas del clima, el fuego como defensa para ahuyentar a los depredadores que se acercaran, en suma y de diferentes formas, todos esos objetos brindaban seguridad.

Con base en lo anterior, se puede decir que la seguridad es aquello (ya sea un objeto, reglas, plan, etc.) que evita sufrir un ataque de algo y minimizar las posibilidades de que algo se convierta en una potencial amenaza que pueda derivar en un ataque. Ahora, ¿Cómo podría aplicarse esto a lo que es el internet?

Desarrollo: La seguridad web.

Conforme han pasado los años, la web ha ido creciendo exponencialmente hasta tal punto de convertirse en el banco de información más grande del mundo, albergando información de todo tipo, la cual está disponible para todo aquel que tenga una computadora y conexión a internet.

Sin embargo, todo este sistema que es la web tiene un diseño detrás que define cómo es que está construido y cómo funciona. Por esto mismo es posible hacer lo que se conoce como "ataques" al sistema para violar sus protocolos con algún fin, ya sea extraer información, tirarlo de la web, destruirlo, etc. Es por esto que tanto en el desarrollo de un sistema como en su manutención, es necesario aplicar la seguridad para evitar que este tipo de cosas sucedan, sobre todo porque ya es muy común que empresas manejen grandes sumas de dinero a través de internet, además de información personal, laboral, planes de empresa, etc.

De esta forma, al aplicar el concepto de seguridad a la web, podría decirse que son aquellas medidas utilizadas para evitar un ataque a un sistema web y que por medio de este quede en las manos del atacante, además de evitar desde la construcción del sistema la existencia de vulnerabilidades dentro del mismo que podrían ser explotadas para generar un ataque.

La principal razón por la que se dan problemas en la seguridad web es porque el programador del sistema descuida los siguientes aspectos:

  • Entradas al sistema.
  • Salidas del sistema.
Esto se refiere a que se descuidan los métodos mediante los cuales el usuario y los datos ganan acceso al sistema, son procesados y posteriormente salen del mismo, al estar descuidados, existen lagunas en las que un atacante es capaz de extraer o leer la información que está entrando y saliendo del sistema, y a través de ésta ganar un acceso que no debería de tener.

Con esto como base, se tiene la convención de que los requerimientos de seguridad de un sistema son:
  • Autenticación.
  • Autorización.
  • Confidencialidad.
  • Integridad.
  • No repudiación.
  • Alta disponibilidad.

Para lidiar con este tipo de complicaciones, existen métodos de seguridad básicos para incrementar la protección de un sistema, algunos de estos son:
  • Balancear riesgo y usabilidad: Se refiere a que si se exceden las medidas de seguridad para combatir a los usuarios ilegales dentro del sistema, se corre el riesgo de ser demasiado restrictivo con los usuarios legales, por lo que la mejor medida es balancear las cosas y utilizar métodos de seguridad que sean transparentes para los usuarios.
  • Rastrear el paso de datos: Como su nombre lo dice, trata acerca de saber de dónde vienen los datos que están entrando al sistema y saber hacia dónde van, para saber si de la fuente de la que provienen es válida o no.
  • Filtrar entradas: En esencia se refiere al proceso mediante el cual se validan los datos que están siendo enviados o recibidos para así evitar datos "contaminados" que pongan en riesgo al sistema.
  • Escapar salidas: Se refiere al proceso para codificar o decodificar información que está saliendo del sistema de tal forma que su significado original se preserve.
Todo esto es algo muy importante para poder implementar un buen nivel de seguridad en un sistema, sin embargo también es importante saber con qué tipo de amenazas y ataques se están lidiando, dado que por pura lógica, no te puedes defender de algo si no sabes cuál es la amenaza.

Algunos tipos de amenazas son las siguientes:
  • Spyware: Se le conoce como software espía y como su nombre dice es un software que se enfoca en estar "espiando" el sistema en cuestión y así recopilar información mientras pasa desapercibido, por sí mismo no es algo peligroso (como con todas las amenazas) dado que sólo recopila información, el problema viene cuando el que recibe la información decide utilizarla con algún fin.
  • Adware: Tipo de spyware que recolecta información sobre el usuario algunas veces para mostrar anuncios publicitarios de acuerdo al perfil del mismo.
  • Malware: Es una categoría de código malicioso que incluye virus, gusanos y caballos de Troya, su propósito es de carácter destructivo, es decir acceder a la información del usuario y mediante algún método robarla o eliminarla.
  • Virus: Programa o archivo que al ejecutarse corre un código que infecta el equipo, es decir, altera el funcionamiento normal de la computadora. Como los virus humanos los de computadora varían por el nivel de infección desde los simples que son fáciles de limpiar hasta los que su daño puede ser mayor que inclusive deje inservible el sistema operativo debido a que atacan archivos importantes como los BIOS. La mayoría de los virus se propagan de computadora en computadora, los gusanos y caballos de troja son un tipo de ellos.
  • Correo Spam: Correo electrónico basura no solicitado también llamado "junk mail", generalmente enviado en forma masiva y conteniendo publicidad o ataques de robo de identidad (phishing).
  • Phishing: Proceso fraudulento que se da cuando un estafador envía mensajes de correo electrónico de tipo spam o mensajes del tipo pop-up para atraer con engaño a los usuarios y obtener información  sensible como cuentas de usuario, contraseñas, números de tarjetas de crédito, datos de cuentas, así como cualquier información personal.
Los ataques más comunes en sistemas web son los siguientes:
  • Ataques URL de tipo semántico:
    • Este tipo de ataques involucran a un usuario modificando la URL a modo de descubrir acciones a realizar originalmente no planeadas para él.
  • Ataques al subir archivos:
    • Existen ataques que aprovechan la posibilidad de la aplicación de subir archivos al servidor. la forma en la que funciona que funcionan es que generalmente PHP almacena los archivos subidos en un carpeta temporal, pero es común en las aplicaciones cambiar la localización del archivo subido a una carpeta permanente y leerlo en la memoria. Al hacer este tipo de procedimientos se debe revisar el parámetro al que va a hacer referencia al nombre del archivo, ya que puede ser truqueado de tal forma que apunte a archivos de configuración del sistema.
  • Ataques de Cross-Site Scripting:
    • XSS es un tipo de vulnerabilidad de seguridad informática normalmente encontrada en aplicaciones web que permiten la inyección de código por usuarios maliciosos en páginas web vistas por otros usuarios, los atacantes típicamente se valen de código HTML y de scripts ejecutados en el cliente, pueden ser vistas como técnicas de evasión de las políticas de protección. Encontrando formas ingeniosas de inyectar códigos maliciosos en las páginas servidas por otros dominios, de esta forma se puede ganar privilegios a datos sensibles, cookies de sesión y otros objetos.
      • Vulnerabilidad XSS tipo 0: Conocido como basado en el DOM o Local, con este tipo de vulnerabilidad, el problema existe en el script del lado del cliente.Si un código de JavaScript accede a una URL como un parámetro de una petición al servidor y utiliza esta información para escribir HTML en la misma página sin ser codificada empleando entidades HTML, existe un agujero XSS, dado que estos datos escritos serán interpretados por los navegadores como código HTML que puede incluir en si código adicional del lado del cliente.
      • Vulnerabilidad XSS tipo 1: A este tipo de agujero XSS se le conoce también como no persistente o reflejado. Estos agujeros aparecen cuando los datos provistos por un cliente web son usados inmediatamente en el lado del servidor para generar una página de resultados para el usuario. Si los datos no validados por el usuario son incluidos en la página resultante sin codificación HTML, se le permite al cliente inyectar código en la página dinámica.
  • Cross-Site Request Forgeries:
    • Este tipo de ataque permite al atacante enviar peticiones HTTP a voluntad desde la máquina de la víctima. Por su naturaleza, es complicado determinar cuando una petición HTML se ha originado por un ataque de este tipo.Cuando se conoce el formato que debe tener una URL para lograr la ejecución de una acción en el sistema, se logra encontrar la posibilidad de explotar este tipo de ataques. Ahora lo único que se necesita es simplemente hacer que una víctima visite la URL.
  • Envío de formas falsificadas:
    • En el fondo, el envío de una forma emplea el mismo mecanismo que una URL, la petición HTTP enviada por el navegador al servidor. El formato con el que va a contar la petición se encuentra predeterminado por la forma y algunos de los datos enviados en la petición son dados por el usuario.Un atacante podría copiar el código fuente de una página, salvarla en su equipo, y modificar el atributo de la acción que realizará la forma incluyendo ahora la ruta absoluta de la página originalmente deseada. Así se pueden quitar restricciones originales que se hubieran ejecutado en el cliente, como el tamaño máximo de un archivo adjunto, desactivar la validación de datos en el lado del cliente, alterar los elementos ocultos o los tipos de datos de los elementos de la forma. Trabajando de esta forma se pueden enviar datos arbitrarios al servidor, de una manera sencilla y sin el uso de herramientas sofisticadas.
  • Peticiones HTTP falsificadas:
    • Un ataque más sofisticado que el anterior es enviar peticiones falsas empleando herramientas especiales para este propósito. La existencia de este tipo de ataques es una prueba determinante de que los datos enviados por los usuarios no son dignos de ninguna confianza, el proceso para llevar a cabo esto es simple, empleando una herramienta de línea de comandos presente en la mayoría de las plataformas se posibilita la comunicación directa con un servidor remoto, conectándonos en el puerto en el cual el servidor escucha.
Conclusión:

La seguridad es un tema de mucha relevancia sobre todo en esta época donde el internet y los sistemas web son de un uso tan común que manejan información de empresas multimillonarias, bancos, transacciones, etc. Además de la información personal de muchas personas. Gracias a esto, ahora existen una gran cantidad de métodos para la seguridad web, al igual que información respecto a los tipos de amenaza con las que uno puede enfrentarse y cómo lidiar con ellas, porque si tenemos que adaptarnos a un mundo informático, es necesario informarnos de los peligros que conllevan para así poder evitarlos.

Romero A. (2009). Aspectos Básicos de la Seguridad en Aplicaciones Web. septiembre 06, 2015, de UNAM Sitio web: http://www.seguridad.unam.mx/documento/?id=17#ataques

Ruiz G. (2011). Tipos de Amenazas. septiembre 06, 2015, de Universidad Iberoamericana Sitio web: http://www.iberotijuana.edu.mx/sisinfo/index.php/documentacin-mainmenu-58/22-seguridad/101-definiciones

González B. (2004). Seguridad en Servicios Web. septiembre 06, 2015, de desarrolloweb.com Sitio web: http://www.desarrolloweb.com/articulos/1640.php

martes, 30 de junio de 2015

Cuaderno de Trabajo del Desarrollo de un Formulario con JSP

El siguiente es el cuaderno de trabajo que fue realizado en base al desarrollo de un programa en la forma de un formulario utilizando conexión a base de datos, JSPs y sesiones, el cual fue desarrollado a lo largo de aproximadamente un mes.


jueves, 18 de junio de 2015

Tiempo estimado para la escritura de un libro

Utilizando como base el promedio del numero de pulsaciones por minuto que obtuve en la prueba de velocidad de curso meca y a lo largo de las lecciones, puedo establecer que mi promedio de pulsaciones por minutos es de aproximadamente 340.

Suponiendo que me de a la tarea de escribir un libro, en el sentido de sólo escribirlo no de crearlo, y si éste es de 100 cuartillas, se puede utilizar un calculo para llegar a un tiempo aproximado que tardaría en escribirlo.

Primero, una palabra en promedio tiene de 8 a 10 letras.

Segundo, un reglón suele estar compuesto de aproximadamente 10 palabras, dependiendo lógicamente del tamaño del reglón y de la letra.

Tercero, una cuartilla en promedio está compuesta de 22 a 25 reglones.

Utilizando para el cálculo los valores más altos, tendríamos palabras de 10 letras, reglones de 10 palabras y cuartillas de 25 reglones.

Si mi promedio de pulsaciones por minuto es de 340, entonces soy capaz de escribir 34 palabras por minuto, eso sería 3.4 reglones al minuto. Por lo tanto puedo escribir una cuartilla en aproximadamente 7.3 minutos.

Si soy capaz de escribir una cuartilla  en 7.3 minutos, entonces 100 cuartillas me tomaría aproximadamente 730 minutos, tiempo que traducido a horas serían aproximadamente 12.1 horas.

Con esto se puede concluir que en la escritura de un libro de 100 cuartillas, el tiempo aproximado que tardaría en hacerlo sería de 12 horas.

domingo, 7 de junio de 2015

Desarrollo de un Programa de Altas en JSP

Código de HTML.

Código de JSP.

Base de datos creada en MYSQL.
 Vista de la página web.

Ejecución del JSP.

Programa desarrollado en 20 minutos.

jueves, 28 de mayo de 2015

martes, 28 de abril de 2015

Calidad

























MODELOS DE DESARROLLO DE SOFTWARE:

Modelo "CMMI"

CMMI significa "Capability Maturity Model Integration" o en español "Modelo de Integración de la Madurez y Capacidad" y es un modelo de desarrollo de software enfocado al proceso de los mismos, este modelo maneja 6 conceptos principales, los cuales son:
  • Procesos: Se define como un método para producir algo, el cual toma en cuenta las Técnicas, los Materiales, las Herramientas y las Personas que intervienen en su ejecución.
  • Área de Proceso: Son un conjunto de actividades agrupadas para facilitar el camino de la mejora y establecen la capacidad de proceso de la empresa.
  • Capacidad: Es una cualidad que permite el buen desarrollo de una actividad y suele aplicarse a los procesos, con la relación de que a mayor capacidad de un proceso, más predecible será su resultado.
  • Madurez: Puede definirse como el alcance de la plenitud y es algo que se adquiere con la experiencia al evolucionar los procesos para bien.
  • Organización: Como bien su nombre lo dice, es la estructura de la empresa desarrolladora, que toma en cuenta a la empresa en sí, la Unidad de Negocio, el Centro de Trabajo y el Proyecto.
  • Modelo: Es un esquema teórico de una situación real que se desarrolla para facilitar la comprensión y estudio de ésta
El CMMI es un modelo que enseña el camino para alcanzar un nivel de Madurez de la organización o un nivel de capacidad en un área de proceso, por lo tanto este modelo dice Qué es lo que se tiene que hacer, mas no el Cómo hacerlo.

La estructura del modelo CMMI se divide en 2 tipos, el escalonado y el continuo, cada uno de ellos dividiendose en 6 niveles:

Estructura Escalonada (Evaluación de Madurez):

Nivel 0: Proceso incompleto y no aplicable.

Nivel 1 (Inicial): Proceso impredecible, poco controlado y reactivo.

Nivel 2 (Gestionado): Proceso aplicable en proyectos y frecuentemente reactivo.

Nivel 3 (Definido): Proceso aplicable a toda la organización y que reacciona anticipadamente.

Nivel 4 (Gestionado cuantitativamente): El proceso es predecible y controlado cuantitativamente.

Nivel 5 (Optimización): Enfoque en la mejora del proceso.

Estructura Continua (Evaluación de Capacidad):

Nivel 0: Incompleto

Nivel 1: Realizado, proceso informal e impredecible.

Nivel 2: Gestionado, sistema de gestión de proyectos presente, comportamiento predecible.

Nivel 3: Definido, procesos de ingeniería y de gestión definidos e integrados

Nivel 4: Gestionado cuantitativamente, productos y procesos controlados cuantitativamente.

Nivel 5: En optimización, la mejora de procesos está institucionalizada.

Clasificación de Áreas de Proceso:

  • Ingeniería.
  • Gestión de Proyecto.
  • Gestión de Proceso.
  • Soporte.
Cada una de estas áreas tiene diferentes funciones dependiendo del nivel en el que se encuentren, además de que también se conforman de:
  • Meta u Objetivo General
  • Meta u Objetivo Específico
El objetivo general es el propósito principal del proyecto y los objetivos específicos son aquellos que al cumplirse llevan a la realización del objetivo general. Estos objetivos facilitan la institucionalización del proceso, es decir, cuando se sigue de una forma rutinaria como parte de la organización y para esto es necesario seguir los pasos de Compromiso, Habilidades, Implantación y Verificación.

Gestión de Proyecto: Cubren las actividades relacionadas con la planificación, seguimiento y control del proyecto. Está conformado por los siguientes apartados:
  • Planificación de Proyectos.
  • Seguimiento y Control de Proyectos.
  • Gestión Integrada de Proyectos.
  • Desarrollo de Equipos Integrado.
  • Gestión de Riesgos.
  • Gestión de Proyectos Cuantitativa.
  • Gestión de Acuerdos con Proveedores.
Ingeniería: Da soporte a las actividades del ciclo de vida de desarrollo del producto. Está conformado por:
  • Desarrollo de Requisitos.
  • Gestión de Requisitos.
  • Solución Técnica.
  • Integración del Producto.
  • Verificación.
  • Validación.
Soporte: Proporciona los procesos esenciales para soportar el desarrollo y mantenimiento del producto, formado por:
  • Medición y Análisis.
  • Gestión de Configuración.
  • Aseguramiento de Calidad de Proceso y Producto.
  • Análisis y Resolución de Decisiones.
  • Análisis y Resolución Causal.
  • Entorno Organizativo para la Integración.
Gestión de Procesos: Contiene las prácticas relacionadas con la implementación de un programa de mejora de procesos, conformado por:
  • Enfoque en el Proceso Organizativo.
  • Definición del Proceso Organizativo.
  • Formación Organizativa.
  • Rendimiento del Proceso Organizativo.
  • Innovación y Despliegue Organizativo.
Con la aplicación de todos estos aspectos del modelo CMMI, se espera un buen nivel de calidad en el desarrollo del software en aspectos como la organización, la productividad, el cumplimiento de requisitos, etc.

Modelo PSP/TSP:

El modelo conocido como PSP/TSP es uno que se encuentra dividido en dos partes, inicialmente se aplica el PSP (Personal Software Process) y posteriormente el TSP (Team Software Process).

El PSP es un proceso que como su nombre lo dice está diseñado a nivel personal, y que se aplica a tareas estructuradas

El objetivo de este proceso es:
  • Planear y monitorear el trabajo.
  • Administrar la calidad de los productos que se producen.
  • Medir y mejorar el desempeño.
Todas estas acciones se realizan a un nivel personal, donde el individuo se toma a sí mismo como sujeto de estudio y lleva a cabo estas acciones, buscando su mejora y el desarrollo de disciplina.

Una vez que cada individuo lleva a cabo el PSP, se prosigue ahora con el TSP, el cual como su nombre indica, es un proceso de desarrollo para equipos basados en CMMI. El propósito de este modelo es obtener:
  • Predecibilidad de costo y tiempo.
  • Mejora de productividad y ciclos de desarrollo.
  • Mejora de calidad de productos.
En suma lo que busca lograr este conjunto de procesos es la resolución de problemas de negocio, esto primero haciendo que cada individuo mejore su forma de trabajar y de analizar su desempeño para después juntarse con otros y trabajar en un equipo con el objetivo de cumplir con un desarrollo de manera eficaz y eficiente.

Proceso de Mejora Continua.

El llamado proceso de mejora continua proviene de la época de la segunda guerra mundial, más específicamente de japón, donde este término es conocido como "Kaizen", "Kai" que significa "Cambio" y "Zen" que significa "Bueno". Esto fue debido a que al término de la 2da guerra mundial la situación de Japón era muy difícil y crearon el llamado JUSE (Unión Japonesa de Científicos e Ingenieros) con el cual crearon metodologías para mejorar el proceso empresarial.

El proceso de mejora continua hace uso del llamado "Círculo de Deming", el cual está constituido por 4 pasos que forman un ciclo, haciendo que una vez es terminado el último, se vuelve a empezar el ciclo con el primer paso. Estos pasos son:


  • Planear: Se establece una meta, se analiza un problema y se define el plan de acción.
  • Hacer: Se ejecuta el plan de acción y se registra.
  • Verificar: Se analiza el resultado obtenido.
  • Actuar: Una vez se tienen los resultados, se decide si es necesaria alguna modificación para mejorar.
Cuando el círculo de Deming se aplica al proceso de mejora continua, lo que se obtiene es un ciclo en el que una empresa una vez que lleva a cabo un proyecto, es capaz de analizar los resultados que obtuvo de éste y ver si fueron favorables o no, una vez que se determina esto, se procede a discutir si se puede realizar alguna modificación a la forma en que se ejecutó el proyecto para mejorarlo y una vez hecho esto, se reinicia el ciclo con el mismo proyecto o uno nuevo, pero ya aplicando las modificaciones que se discutieron con anterioridad. De esta forma el ciclo provoca que continuamente se estén revisando y analizando los procesos que lleva a cabo el equipo o la empresa y así modificarlos constantemente en busca de un mejor desempeño, dando lugar así a la mejora continua.

Fuentes:

http://www.alconet.com.ar/ISO/menu.html

http://www.aec.es/c/document_library/get_file?p_l_id=32315&folderId=210056&name=DLFE-6053.pdf

http://www.kernel.com.mx/documentos/psp_tsp.pdf

http://www.manufacturainteligente.com/kaizen/