Aspectos Basicos de la Seguridad en Aplicaciones Web

Introducción a la Seguridad en Sistemas Web

Un efecto secundario del crecimiento exponencial que ha tenido el Internet es la privacidad de información tanto personal como profesional. En Internet encontramos funcionando a tiendas en línea, negocios que mueven grandes cantidades de dinero, redes de los servicios que habilitan el comercio a nivel internacional así como sitios de redes sociales que contienen información muy delicada de la vida privada de sus miembros. Desde muchos puntos de vista, podemos creer sin dudar que el punto más crítico de la seguridad del Internet, lo tienen las piezas que intervienen de forma directa con las masas de usuarios, los servidores web.

Problemas Principales en la Programación de Sistemas Web

Una gran parte de los problemas de seguridad en las aplicaciones web son causados por la falta de seguimiento por parte del programador en los siguientes aspectos:

• Entradas al sistema
• Salidas del sistema

Quizás uno de los consejos de seguridad en PHP más conocido en cualquier foro de Internet es el uso del parámetro register_globals que es considerado a priori por muchos administradores como un defecto en la configuración y muy probablemente sin entender con cabalidad que es lo que implica esta configuración. El tener habilitado este parámetro oculta el origen de los datos. Si se encuentra habilitado, no podemos saber como es que una variable entró al sistema (si lo hizo por medio de una petición GET o POST por ejemplo) y contribuye a la pérdida del control por parte del programador sobre los procesos a los que se ha sometido cada variable para librarla de riesgos potenciales para la aplicación.

Practicas básicas de Seguridad Web

2.1 Balancear Riesgo y Usabilidad

Si bien la usabilidad y la seguridad en una aplicación web no son necesariamente mutuamente excluyentes, algunas medidas tomadas para incrementar la seguridad con frecuencia afectan la usabilidad. Al igual que debemos pensar en las maneras en que usuarios ilegítimos nos pueden atacar, también debemos considerar la facilidad de uso para los usuarios legítimos.

La recomendación inicial sería tratar de usar medidas de seguridad que sean transparentes a los usuarios. Por ejemplo, la solicitud de un nombre de usuario y una contraseña para registrarse en un sistema son procedimientos esperados y lógicos por parte del usuario.

2.2 Rastrear el Paso de los Datos

La medida más importante como desarrollador preocupado por la seguridad que podemos tomar es mantener conocimiento de los pasos que ha recorrido la información en todo momento. Conocer de donde vinieron los datos y hacia donde van. En muchas ocasiones lograr esto puede ser complicado, especialmente sin un conocimiento profundo de como funcionan los sistemas Web.

En las aplicaciones web, existen maneras de distinguir los orígenes de los datos y poder así reconocer cuando los datos pueden ser dignos de confianza y cuando no. Ante todo, debemos recordar que la desesperación y la paranoia con mucha frecuencia nos dirigen a complicaciones y errores.

2.3 Filtrar Entradas

El filtrado es una de las piedras angulares de la seguridad en aplicaciones web. Es el proceso por el cual se prueba la validez de los datos. Si nos aseguramos que los datos son filtrados apropiadamente al entrar, podemos eliminar el riesgo de que datos contaminados y que reciben confianza indebida sean usados para provocar funcionamientos no deseados en la aplicación.

El proceso de filtrado debe estar conformado por los siguientes pasos:

• Identificar la entrada.
• Filtrado de la entrada.
• Distinguir entre datos que ya han pasado por el filtro y los que no.

Por lo general, se considera más seguro tratar a los datos provenientes de bases de datos como entradas, aunque supuestamente sean bases seguras y en las que debiéramos tener confianza, esto se debe a que es mejor tener.

2.4 Escapar Salidas

Otra piedra angular de la seguridad en aplicaciones web es el proceso de escapado y su contraparte para codificar o decodificar caracteres especiales de tal forma que su significado original sea preservado.

El proceso de escapado debe estar compuesto a su vez por los siguientes pasos:

Identificar las salidas. Escapar las salidas. Distinguir entre datos escapados y noescapados.

Para escapar las salidas, primero debemos identificarlas. En PHP una forma de identificar salidas hacia el cliente es buscar por líneas como:

echo
print
printf
<?=

Además debemos considerar otro tipo de salidas como los datos que son enviados a otros sistemas como bases de datos, etc. El proceso de escapado debe adecuarse al tipo de salida de que se trate (si es al cliente, a la base de datos, etc.). Para la mayoría de los destinatarios, existen funciones nativas en PHP para esta finalidad.

3.1 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. Los parámetros que son enviados directamente desde la URL son enviados con el método GET y aunque los parámetros que son enviados con este método sólo son un poco más fáciles de modificar que los enviados en forma oculta al usuario en el navegador, esta exposición adicional de los parámetros tiene consecuencias, como cuando queda registrada la URL con todo y estos parámetros quizás privados en buscadores como Google.

3.2 Ataques al Subir Archivos

Existen algunos ataques que aprovechan la posibilidad de la aplicación de subir archivos al servidor. Estos ataques funcionan de la siguiente manera:

Generalmente PHP almacena los archivos subidos en un carpeta temporal, sin embargo 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 debemos revisar el parámetro que hará referencia al nombre del archivo, ya que puede ser truqueado a modo de apuntar a archivos de configuración del sistema (como /etc/passwd en sistemas Unix).

3.3 Ataques de Cross-Site Scripting

XSS es un tipo de vulnerabilidad de seguridad informática típicamente 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.

Una vulnerabilidad de este tipo puede ser usada por los atacantes para burlar los controles de acceso comunes, como la muy conocida Same Origin Policy. Recientemente este tipo de ataques han sido explotados para crear poderosos ataques de phishing y de abusos en el navegador.

Desde la liberación del lenguaje JavaScript, se previeron los riesgos de permitir a un servidor Web enviar código ejecutable al navegador. Un problema se presenta cuando los usuarios tienen abiertos varias ventanas de navegador, en algunos casos un script de una página podría acceder datos en otra página u objeto, observando el peligro de que un sitio malicioso intentara acceder datos sensibles de esta forma.

Seguridad de las Aplicaciones y su Relación con las Bases de Datos

La mayoría de las aplicaciones web son usadas como un conducto entre muchas fuentes de datos y el usuario, esto es, las aplicaciones web son usadas frecuentemente para interactuar con una base de datos. Aunque el tema de la seguridad en las bases de datos merece un tratamiento diferente al de las aplicaciones web, se encuentran íntimamente relacionados. Como hemos mencionado en secciones anteriores, toda entrada al sistema debe ser filtrada, y toda salida escapada. Lo mismo aplica cuando las entradas o salidas son de o hacia una base de datos. Muchos programadores no dan importancia al filtrado de datos provenientes de una consulta a la base de datos, debido a que consideran a esta fuente como confiable. Aunque el riesgo a primera vista parecería menor, es una práctica recomendable no confiar en la seguridad de la base de datos e implementar la seguridad a fondo y con redundancia. Si algún dato malicioso pudiera haber sido inyectado a la base de datos, nuestra lógica de filtrado puede percatarse de ello, pero sólo si se ha implementado este mecanismo.

Fuente... http://www.seguridad.unam.mx/documento/?id=17