Evaluación del performace de aplicaciones Web

El segundo tema consistió en mostrar los resultados del trabajo que se está haciendo para Softlogik respecto a la evaluación de desempeño de las aplicaciones. Para el caso el equipo de la teñarcera generación se dividió en dos grupos: 1) Evaluación del número de usuarios que para el proyecto en específico fueron 3000 usuarios, 2) La segunda parte del equipo evalúo el tiempo de carga de la página en función de su tamaño.

Respecto al primer punto, el equipo utilizó dos herramientas WAPT y JMeter. Los resultados que pueden obtenerse con este tipo de herramientas se describen a continuación...

• En la primera medición de desempeño  con WApT (Web Aplication Testing), se llegó a tiempos de desempeño de 40 segundos. Se realizó una corrección del Timeout mayor a 15 segundos configurando el Apache, en la segunda medición hubo una mejora respecto a que 900 usuarios no tard aban más de 6 segundos en visualizar los resultados. 
• Respecto a errores de red. Cuando 400 errores se tratan de acceder simultáneamente es xisten niveles de pruebas. Arriba de los 250 usuarios existen errores de red y los timeouts.

El contexto es que un usuario por casilla se conecta para capturar lo datos.

• Se realizó otra prueba con JMeter. Para atender 3000 conexiones.

Observación: Se deben buscar referencias que permitan comparar cual es un estándar de performance para este tipo de aplicaciones. Buscar referencia de comparativos respecto a como estamos respecto a los demás.

• De 0 a 6 segundos...  Excelentes.
• De 6 a 15 segundos... Donde todavía el usuario podría esperar..
• De 6 a 30 segundos... Podría

Observación Softlogik: Alejandro hace una referencia de Jacob Nielsen sobre de 0 a 1 segundo apenas se percibe por el ser humano. De 0 a 10 segundos el ser humano puede esperar pues existen múltiples factores que afectan el desempeño. Pero esto para aplicaciones comerciales. Para sitios Web altos en transacciones estos tiempos son mayores.

Métricas sugeridas::

• La metra sería que 3000 usuarios puedan consultar en menos de 15 segundos.
• Hay una suposición de que la red funciona perfectamente.

Observaciones desde el punto de vista de infraestructura:

• En estos puntos ya se tienen que combinar con un buen diseño de la infraestructura que soporta el servicio. Se tiene que diseñar una capacidad para atender estos tipos de usuario.

Observaciones generales:

• En cuanto al performance no se tenía una meta.
• ¿Cuál podría ser la solución para que no existan errores de red?
• Es necesario que los experimientos se planteen desde un punto de vista científico.

Respecto al segundo del ejercicio, la otra parte del equipo evalúo con dos herramientas el tamaño de la página a través de dos herramientas: YSlow y PageSpeed... A continuación algunas notas u observaciones del ejercicio:

Proceso: se instala la herramienta, se indica la página y se generan los resultados. Es un plug-in de Firefox. Los requerimientos son Mozilla Firefox. En la parte superior está la barra de navegacióno y así se presenta Yslow con la extensión de Mozilla y se hace una referencia. El desarrollador de YSlow (Steve Souder), encargado del grupo de alto rendimiento de Yahoo. Lo que hace es una recomendación de las mejors prácticas que se hacen a lo largo del tiempo.

En la primera revisión del sitio con Yslow surgieron varias recomendaciones como cargar css en el header, cargar javascript en la página. Al inicio la página medía 980 kb. Al final después de que el equipo de desarrollo realizó la última corrección ya con hojas de estilo incluidas el tamaño final de la aplicación quedaría en 278 kb. 

• Con el uso de herramienta de PageSpeed la calificación de 1 a 100 obtuvo una calificación del 50 y tantos puntos. PageSpeed se enfoca mucho a las imágenes. Con imágenes comprimidas se puede hacer una calidad de la imagen. 
• Después de aplicar las sugerencias la página se carga en un cuarto de segundo.

EVALUACIÓN DE LA SEGURIDAD BASADOS EN EL MODELO OWASP

1. Inyección. Con consultas SQL se puede acceder directamente a los datos. Desde cualquier entrada es una posible vulnerabilidad de inyección.
2. Secuencia de comandos en sitios cruzados (XSS). Es similar a la inyección SQL pero con lenguajes de scirpt.
3. Pérdida de autenticación  y gestión de sesiones. Cuando sucede que no se elimina correctamente una sesión.
4. Referencia directa insegura a objetos. Cuando un atacate modifica directamente directorios. La recomendación es sperar archivos en diferentes carpetas. De otra forma hay que dar permisos a cada uno de los archivos.
5. Falsificación de peticiones en sitios cruzados. La característica del cinco es que utiliza páginas a donde estás logueado. Así se pueden realizar accionoes en tu nombre.
6. Defectuosa configuración de seguridad. Cuando se nos olvida al pasar de producción eliminar contraseñas como admin admin.
7. Almacenamiento criptográfico de la seguridad. Utilizar algoritmos ya existentes.
8. Fallas de restricción de acceso a URL. Aquí se agrega por ejemplo una página con /admin.
9. Protección insuficiente en la capa de transporte. Alguien puede capturar el tráfico de la red y puede ver lo que estamos enviando. Solución utilizar un certificado de seguridad.
10. Re direcciones o reenvíos no validos. Con links enviar a páginas externas.

Fases de la investigación:

1. Ataque manual. El SQL injection y Cross Site Scripting comenzarón a utilizarlo a mano. Pero en el transcurso de la investigación encontrarón herramientas automáticos. En la página de ha.ckers.org/xss.html vienen más de cien combinaciones diferentes para probar si existía esa vulnerablidad. 

2. Herramientas de escaneo de vulnerabilidades (Accunetix, netsparker, N-Stalker, Grendel-Scan). De todas las herramientas que encontraron Accunetix revisa todas las vulnerabilidades. Pero se revisaron otras herramientas. Varios autores sugieren el utilizar para lograr una mayor confianza en los resultados. Accunetix, es la herramienta que provee mayores resultados, con más detalle y sugerencias realizadas.

1. Los resultados proveídos por Accunetix, se basan en cuatro niveles: Alto, Medio, Bajo, Informacional. Se ralizaron tres pruebas a la aplicación X... La herramienta puede arrojar falsos positivos. Para la última revisión se eliminaron o hicieron las modificaciones pertinentes. El único problema detectado fue que se tenía acceso director para crear usuarios del sistema. 
2. Con Netsparker se identificó un error de que el password puede ser robado por la red porque no se tiene un certificado de seguridad.
3. N-Stalker dice que no tenemos la versión actual de Apache, por lo que debería realizarse.

ACCIONES TOMADAS EN BASE A LA AUDITORIA. El equipo de desarrollo implementó una serie de acciones para hacer la aplicación evaluada más segura. 

• Para la inserción XSS. Se agregó YX ssFilter al framework y en cada controlador se manda llamar para habilitar el filtro.
• El equipo de desarrollo valido además la página y restringió el acceso par ala captura de usuarios.
• Se bloquaron los directorios de información del framework.
• Actualización de la versión de Apache.

CONCLUSIONES: "Primero debemos de medir para luego mejorar nuestro desempeño".

Observaciones: ¿Cómo se pueden institucionalizar en Softlogik? 

Alex: En el Kanban hay una columna de integración en esa columna de integración se va a agregar a una lista de actividades. Deben de hacerse parte del proceso de desarrollo. En Softlogik es incluir está fase en Kanban.

Paty: Esto se realiza agregando mejores prácticas durante todo el proceso.

Observaciones de Pepe: Se puede implementar un enfoque preventivo?

Alex: No totalmente, "la optimización temprana es la raíz de todos los males". Se van incorporando mejores prácticas que se aplican... Pero tal vez lo ideal es que se apliquen a la mitad o al final del proceso.

Observación Dr. Lemus: Donde se aplican este tipo de herramientas. Se puede prevenir desde desarrollo?

Kike: Todo lo de inserción que es lo más peligroso se hace a través de la sanitización del código. Desde el desarrollo se pueden utilizar HTML purifying, encoders, etc. Hay listas blancas para verificar. El "eslabón más

Obervación con Dr. Lemus: Sería necesaria otra auditoría de seguridad. Si se desarrolla más.

Jesús: Solo se ralizaron pruebas de caja negra.