SEGURIDAD DE SISTEMAS,APLICACIONES Y BASE DE DATOS

SEGURIDADES EN SISTEMAS, APLICATIVOS Y BASES DE DATOS

SEGURIDAD EN SISTEMAS APLICATIVOS WEB

El crecimiento de la Internet a traído como efecto secundario la privacidad de información tanto personal como profesional. Ya que 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 y mientras más se conecta el mundo, la necesidad de seguridad en los procedimientos usados para compartir la información se vuelve más importante

Es común escuchar sobre fallas en los sistemas de protección de los servidores más frecuentemente utilizados y es un hecho, que la mayoría de los problemas detectados en servicios web no son provocados por fallas intrínsecas de ninguna de estas partes, ya que una gran cantidad de los problemas se generan por malos usos por parte de los programadores, y teniendo en cuenta que la mayoría de los problemas de seguridad en los sitios web se encuentran a nivel aplicación y que son el resultado de escritura defectuosa de código, se debe entender que programar aplicaciones web seguras no es una fácil, ya que requiere por parte del programador, no únicamente mostrar atención en cumplir con el objetivo funcional básico de la aplicación, sino una concepción general de los riesgos que puede correr la información contenida, solicitada y recibida por el sistema.

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 es el uso del parámetro register_globals que es considerado 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.

Otro aspecto importante además de los procesos de verificación que se deben de tener para con las entradas y salidas del sistema lo representa la fuga de información útil para un posible ataque sobre nuestro sistema. En este punto, los mensajes de error enviados por el servidor, que suelen ser de gran utilidad durante el proceso de desarrollo de la aplicación, se vuelven contra nosotros cuando siguen apareciendo en una aplicación que se encuentra en la etapa de producción, por lo que es necesario deshabitar todos estos mensajes y editar algunos otros (como los que se envían cuando el servidor no encuentra algún archivo en particular) que también pueden ser utilizados por los atacantes para obtener información sobre nuestro sistema.

Practicas básicas de Seguridad Web

1. Balancear Riesgo y Usabilidad

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. 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 dónde vinieron los datos y hacia dónde van. En muchas ocasiones lograr esto puede ser complicado, especialmente sin un conocimiento profundo de cómo funcionan los sistemas Web.

Particularmente para PHP existen arreglos super globales como GET, POST y COOKIE entre otros que sirven para identificar de forma clara las entradas enviadas por el usuario. Si esto lo combinamos con una convención estricta para el nombrado de las variables podemos así tener un control sobre el origen de los datos usados en el código.

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 redundancia para evitar problemas en el caso de que la base de datos fuera vulnerada.

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 no escapados.

Clasificación de Ataques

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.

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. 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

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. Por ello se introdujo la política same-origin. Esencialmente esta política permite la interacción entre objetos y páginas, mientras estos objetos provengan del mismo dominio y en el mismo protocolo. Evitando así que un sitio malicioso tenga acceso a datos sensibles en otra ventana del navegador vía JavaScript.

Tipos de vulnerabilidad XSS

Existen tres diferentes tipos de vulnerabilidades XSS:

Tipo 0

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.

Tipo 1

Un ejemplo clásico de este tipo es en los motores de búsqueda, si alguno busca una cadena que incluya caracteres especiales HTML, comúnmente la cadena de búsqueda será formateada para representar lo que se buscó, o al menos incluirá los términos de la búsqueda en la caja de texto para ser editados. Si las ocurrencias de los términos no son codificados como entidades HTML existe un agujero XSS.

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 la naturaleza de este tipo de ataques, es difícil determinar cuando una petición HTML se ha originado por un ataque de este tipo.

Cuando un atacante conoce el formato que debe tener una URL para lograr la ejecución de una acción en el sistema, ha logrado encontrar la posibilidad de explotar este tipo de ataques. Ahora lo que necesita el atacante es simplemente hacer que una víctima visite la URL.

Un recurso que se utiliza comúnmente para realizar este tipo de ataques en tener embebida

...