Que son las aplicaciones web?

Descripcin general En los inicios de Internet, los sitios web consistan de pginas estticas. Obviamente, el contenido esttico impeda a la aplicacin interactuar con el usuario. Como esto es un limitante, los fabricantes de servidores web permitieron correr programas externos mediante la implementacin del mecanismo CGI. Esto permita que la informacin ingresada por el usuario fuera enviada a un programa externo o script, procesado y luego el resultado era devuelto al usuario. CGI es el abuelo de todos los marcos de aplicaciones web, lenguajes de script y servicios web que son comunes hoy en da. CGI es raramente utilizado ahora, pero la idea de un proceso ejecutando informacin dinmica suministrada por el usuario o un almacn de datos, y generando una salida es ahora el pilar de las aplicaciones web. Tecnologas CGI CGI es aun utilizado por muchos sitios. Una ventaja de CGI es la facilidad para escribir la lgica de la aplicacin en un lenguaje nativo rpido, tal como C o C++, o de habilitar una aplicacin que previamente no era web a que sea accesible va navegadores web. Existen varias desventajas al escribir aplicaciones usando CGI: La mayora de los lenguajes de bajo nivel no soportan salidas de HTML de manera directa, y por lo tanto se necesita escribir o utilizar una librera, o una salida HTML deber ser creada en el momento por el programador.

El ciclo escritura compilacin implementacin ejecucin es mas lento que en la mayora de las tecnologas mas recientes (pero no demasiado). CGI son procesos separados, y la penalizacin en el rendimiento de IPC y en la creacin de procesos puede ser significativa en algunas arquitecturas. Error! No se le ha dado un nombre al marcador. 18 CGI no soporta controles de sesin, por lo tanto una librera tiene que ser escrita o importada para soportar sesiones. No todos se encuentran confortables escribiendo en un lenguaje de bajo nivel (tal como C o C++), por lo tanto la barrera de ingreso es de alguna manera alta, particularmente comparado con lenguajes de script. La mayora de los lenguajes de 3ra generacin comnmente utilizados en programas CGI (C o C++) sufren de desbordamientos de pila y prdida de recursos. Para evitar esto, es necesaria una gran cantidad de habilidades. Filtros Los filtros son usados para propsitos especficos, tales como controlar el acceso a un sitio web, implementar otro marco de aplicaciones web (por ejemplo Perl, PHP o ASP), o proveer un control de seguridad. Un filtro debe ser escrito en C o C++ y puede ser de alto rendimiento ya que reside dentro del contexto de ejecucin del mismo servidor web. Ejemplos tpicos de una interfase de filtro son los mdulos de servidor web Apache, SunONE NSAPIs, y Microsoft ISAPIs. Ya que los filtros son interfases especiales raramente utilizadas que pueden

directamente afectar la disponibilidad del servidor web, ya no son ms considerados. Scripting La falta de controles de CGI sobre el manejo de sesiones y los controles de autorizacin ha obstaculizado el desarrollo de aplicaciones web de utilidad comercial. Junto con tiempos de desarrollo relativamente ms lentos, los desarrolladores web se han inclinado hacia lenguajes de script como una solucin. Los intrpretes corren cdigo script dentro del proceso del servidor web, y debido a que los scripts no son compilados, el ciclo escritura implementacin ejecucin era un poco ms rpido. Los lenguajes de script raramente sufren de desbordamientos de pila o prdidas de recursos, por lo tanto es ms fcil para los programadores evitar uno de los problemas de seguridad ms comunes. Tiene algunas desventajas: OWASP Guide 2.0 19 La mayora de los lenguajes de script no se encuentran solidamente tipificados y no promueven buenas prcticas de programacin. Los lenguajes de script son generalmente mas lentos que sus contrapartes compilados (algunas veces hasta 100 veces mas lento). Los scripts muchas veces llevan a generar cdigo fuente difcil de mantener a medida que su tamao aumenta. Es difcil (pero no imposible) escribir grandes aplicaciones de varias capas en lenguajes de script, muy frecuentemente la capa de presentacin, aplicacin y datos residen en la misma

maquina, limitando la escalabilidad y seguridad. La mayora de los lenguajes de script no soportan nativamente mtodos remotos o llamadas de servicios web, haciendo difcil la comunicacin con servidores de aplicacin y servicios web externos. A pesar de sus desventajas, muchas aplicaciones aun son escritas en lenguaje de script, tales como eGroupWare (PHP), y muchos sitios antiguos de banca electrnica se encuentran frecuentemente escritos en ASP. Los marcos de lenguaje de script incluyen ASP, Perl, Cold Fusion, y PHP. Sin embargo, muchos de estos son considerados hbridos ahora, particularmente las ltimas versiones de PHP y Cold Fusion, que permiten la optimizacin de scripts. Marcos de aplicaciones web A medida que los lenguajes de script alcanzaban sus lmites de rendimiento y escalabilidad, muchos grandes proveedores se movieron a la plataforma Sun de desarrollo web: J2EE. Utiliza el lenguaje Java para producir aplicaciones veloces (casi tan veloces como C++) que no fcilmente sufren de desbordamiento de pila y prdidas de memoria. Permite a aplicaciones grandes distribuidas ejecutarse aceptablemente desde la primera vez. Posee buenos controles de autorizacin y sesin. Habilita aplicaciones de varias capas relativamente transparentes a travs de varios mecanismos de invocacin remota, y Error! No se le ha dado un nombre al marcador. 20

Es fuertemente codificado para prevenir muchos problemas tpicos de seguridad y programacin antes que el programa sea ejecutado. Hay muchas implementaciones de J2EE disponible, incluyendo la versin de referencia de Tomcat de la fundacin Apache. La desventaja es que J2EE tiene una curva de aprendizaje o mas pronunciada que C++, lo que hace que le resulte difcil escribir aplicaciones a diseadores web y programadores recin iniciados. Recientemente las herramientas de diseo grafico han facilitado esto de alguna manera, pero a comparacin que PHP, J2EE se encuentra aun a cierta distancia. Microsoft actualizo su tecnologa ASP a ASP.Net, que utiliza el marco .Net y compiladores nativos MSIL justo a tiempo. El marco .Net mimetiza de muchas formas el marco J2EE, pero MS mejoro el proceso de desarrollo de varias maneras tales como: Resulta ms fcil a los programadores recin iniciados y a los diseadores web crear aplicaciones ms pequeas. Permite grandes aplicaciones distribuidas. Posee buenos controles de sesin y autorizacin. Los programadores pueden usar su lenguaje favorito, que es compilado a cdigo nativo permitiendo un excelente rendimiento (cercano a las velocidades de C++), adems de la recoleccin de desbordamiento de pila y residuos de recursos. Comunicacin transparente con componentes remotos y externos. Se encuentre fuertemente codificada para prevenir problemas comunes de seguridad y programacin antes que el programa sea ejecutado. La eleccin entre J2EE y ASP.Net depende mayormente de la plataforma elegida. Las

aplicaciones que se orientan a J2EE tericamente pueden ser ejecutadas con pocos (o ningn) cambio entre los proveedores mas importantes. Y en muchas plataformas de Linux, AIX, MacOS X, o Windows. En practica, algunos ajustes son requeridos, pero no reescribir completamente la aplicacin. ASP.Net se encuentra disponible principalmente Microsoft Windows. El proyecto Mono (http://www.go-mono.com/) puede correr aplicaciones ASP.Net en diversas plataformas incluyendo Solaris, Netware, Linux. Existen pocas razones para elegir una a la otra desde la perspectiva de la seguridad. OWASP Guide 2.0 21 Aplicaciones de pequea a mediana escala La mayora de las aplicaciones se encuentran dentro de esta categora. La arquitectura mas comn es un script lineal procedural y simple. Esta es la forma mas usual de codificacin para ASP, Coldfusion y scripts PHP. Pero menos utilizada (sino imposible) para ASP.Net y aplicaciones J2EE. La razn para esta arquitectura es que resulta fcil de escribir, y se requiere poco conocimiento tcnico para mantener el cdigo. Para aplicaciones mas pequeas, cualquier beneficio en el rendimiento obtenido por moverse a una arquitectura mas escalable nunca ser recuperado en el tiempo de ejecucin. Por ejemplo, si se requieren tres semanas adicionales de tiempo de desarrollo para re-escribir los scripts a un enfoque MVC, las tres semanas nunca sern

recuperadas (o notadas por los usuarios finales) de las mejoras en escalabilidad. Es tpico encontrar diversos problemas de seguridad en estas aplicaciones, incluyendo consultas dinmicas de bases de datos construidas con entradas de datos insuficientemente validadas, un manejo pobre de errores y controles dbiles de autorizacin. Esta gua provee recomendaciones de los diversos captulos para mejorar la seguridad de estas aplicaciones. Aplicaciones de gran escala Las aplicaciones de gran escala necesitan una arquitectura diferente de aquella de un simple formulario de encuesta. A medida que las aplicaciones crecen en tamao, resulta cada vez ms difcil el implementar y mantener funcionalidades y mantener una alta escalabilidad. La utilizacin de arquitecturas de aplicacin escalables se convierte en una necesidad mas que en un lujo cuando la aplicacin necesita mas de tres tablas de base de datos o presenta mas de aproximadamente 20-50 funciones a un usuario. Una arquitectura de aplicacin escalable normalmente se encuentra dividida en niveles, y si se utilizan patrones de diseo, muchas veces se dividen en porciones reutilizables usando diferentes lineamientos especficos para reforzar la modularidad, requerimientos de interfase y la reutilizacin de objetos. El dividir la aplicacin en niveles permite que la aplicacin se pueda distribuir entre varios servidores, mejorando por lo tanto la escalabilidad de la aplicacin a expensas de mayor complejidad.

Una de las arquitecturas de aplicaciones web ms comunes es Modelo Vista Controlador (MVC), que implementa la arquitectura de aplicacin Smalltalk 80. MVC es tpico de la mayora Error! No se le ha dado un nombre al marcador. 22 de las aplicaciones J2EE de Apache Foundation Jakarta Struts, y el cdigo detrs de ASP.Net puede ser considerado una implementacin parcial de este enfoque. Para PHP, el proyecto WACT (http://www.wact.sourceforge.net) aspira a implementar el paradigma MVC de una manera ms amigable para PHP. Vista La renderizacin de cdigo front-end, frecuentemente llamada nivel de presentacin, debera aspirar a producir la salida HTML para el usuario con poco o nada de lgica de aplicacin. Como muchas aplicaciones sern internacionalizadas (por ejemplo no conteniendo cadenas localizadas o informacin cultural en la capa de presentacin), deben usar llamadas al modelo (lgica de aplicacin) para obtener la informacin requerida para suministrar informacin til al usuario en su lenguaje y cultura preferido, direccin del script, y unidades. Todas las entradas de los usuarios se encuentran redireccionadas hacia los controladores en la lgica de la aplicacin. Controlador El controlador (o lgica de la aplicacin) toma entradas de los usuarios y las dirige a travs de varios flujos de trabajo que llaman a los objetos del modelo de la aplicacin para extraer, procesar, o almacenar informacin.

Los controladores bien codificados, validan informacin centralmente en el servidor contra problemas de seguridad comunes antes de pasar la informacin al modelo de procesamiento y se aseguran que la salida de datos sea segura o en un formato preparado para una salida segura por parte del cdigo de visualizacin. Debido a que es probable que la aplicacin sea internacionalizada y accesible, la informacin debera encontrarse en el lenguaje y cultura local. Por ejemplo, las fechas no solo pueden presentarse en distinto orden, pero tambin se podra utilizar un calendario completamente distinto. Las aplicaciones deben ser flexibles respecto de la presentacin y almacenamiento de informacin. El desplegar simplemente 9/11/2001 es completamente ambiguo para cualquiera excepto por un par de pases. Modelos Los modelos encapsulan funcionalidades tales como cuenta o usuario. Un buen modelo debe ser transparente al programa que lo llama y proveer un mtodo para lidiar con procesos de OWASP Guide 2.0 23 negocio de alto nivel en vez de actuar como un relleno para el almacenamiento de datos. Por ejemplo, un buen modelo permitira que exista en el controlador pseudo cdigo como el siguiente: oAccount->TransferFunds(fromAcct, ToAcct, Amount) Ms que escribirlo de la siguiente manera: if oAccount->isMyAcct(fromAcct) &

amount < oAccount->getMaxTransferLimit() & oAccount->getBalance(fromAcct) > amount & oAccount->ToAccountExists(ToAcct) & then if oAccount->withdraw(fromAcct, Amount) = OK then oAccount->deposit(ToAcct, Amount) end if end if La idea es encapsular el trabajo sucio en el modelo de cdigo, en lugar de exponer primitivas. Si el controlador y el modelo se encuentran en diferentes mquinas, la diferencia de rendimiento ser asombrosa, por lo que es importante para el modelo ser til a un nivel alto. El modelo es responsable de la comprobacin de datos en contra de las reglas de negocio, y cualquier riesgo residual para el nico almacn de datos en uso. Por ejemplo, si un modelo almacena los datos en un archivo plano, el cdigo necesita comprobar la inyeccin de comandos de sistema operativo si los archivos planos han sido nombrados por el usuario. Si el modelo almacena los datos en un lenguaje interpretado, como SQL, entonces el modelo se encarga de la prevencin de inyeccin de SQL. Si se utiliza una interfaz de cola de mensajes a un mainframe, el formato de datos de la cola de mensajes (normalmente XML) debe estar bien formado y cumple con una DTD. El contrato entre el controlador y el modelo debe ser examinado cuidadosamente para garantizar que los datos estn fuertemente tipificados, con una estructura razonable (sintaxis),

una longitud apropiada, al tiempo que permita flexibilidad para permitir la internacionalizacin y las necesidades futuras. Llamadas por el modelo al almacn de datos debe ser a travs del mtodo ms seguro posible. A menudo, la posibilidad ms dbil son las consultas dinmicas, cuando una cadena se construye a partir de la entrada de un usuario sin verificar. Esto lleva directamente a la inyeccin de SQL y est mal visto. Para ms informacin, vea el captulo Inyecciones de Intrprete. Error! No se le ha dado un nombre al marcador. 24 El mejor desempeo y mayor seguridad a menudo se obtiene a travs de procedimientos almacenados parametrizados, seguido de consultas parametrizadas (tambin conocidas como declaraciones preparadas) con una fuerte tipificacin de los parmetros y esquemas. La principal razn para el uso de procedimientos almacenados es reducir al mnimo el trfico de la red en transacciones de mltiples niveles o para evitar que informacin sensible sea transmitida por la red. Los procedimientos almacenados no son siempre una buena idea lo atan a un proveedor de base de datos y muchas implementaciones no son rpidas para el clculo numrico. Si utiliza la regla 80/20 para la optimizacin y mueve las transacciones lentas y de alto riesgo a procedimientos almacenados, los triunfos valdrn la pena desde un punto de vista de seguridad y rendimiento. Conclusin

Las aplicaciones web se pueden escribir de muchas maneras diferentes, y en muchos idiomas diferentes. Aunque la Gua se concentra en las tres opciones comunes para sus ejemplos (PHP, ASP.NET y J2EE), la Gua puede utilizarse con cualquier aplicacin web de tecnologa.