Acceso A Bases De Datos.docx

ENTORNO DE PROGRAMACION [Subtítulo del documento]

24 DE ABRIL DE 2018 CESAR Y LOS CESAR’S

INSITUTO TECNOLOGICO SUPERIOR DE CINTALAPA

INGENIERIA INFORMATICA 6TO F

DISEÑO DE APLICACIONES WEB

UNIDAD II. ENTORNO DE PROGRAMACION.

INVESTIGACION

PROFESOR LIC. ARTURO MONTESINOS CERVANTES

EQUIPO#4

JULIO CESAR VAZQUES SANTIAGO LEONARDO DANIEL REYES HERNANDEZ ALMA ANGELICA CRUZ DE LA CRUZ JOSE MARCELINO ROSALES ARRIAGA

CINTALAPA DE FIGUEROA, CHIAPAS 24 DE ABRIL DEL 2018

INTRODUCCION En la actualidad el crecimiento de internet ha impactado directamente en la seguridad de la información manejada cotidianamente. Sitios de comercio electrónico, servicios, bancos e incluso redes sociales contienen información sensible que en la mayoría de los casos resulta ser muy importante. Se puede decir que uno de los puntos más críticos de la seguridad en Internet son las herramientas que interactúan de forma directa con los usuarios, en este caso los servidores web. Sin embargo, la mayoría de los problemas detectados en servicios web no son provocados por fallas de ninguna de estas partes, si no que los problemas se generan por malas prácticas de parte de los programadores. Debemos entender que programar aplicaciones web seguras no es una tarea fácil, ya que requiere por parte del programador, no sólo 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 procesada por el sistema.

Acceso a Bases de Datos Sistemas Administradores de Bases de Datos (DBMS) como Oracle y Sybase pueden ser accesados a través de servicios Internet, utilizando sus propios protocolos de comunicación a través de TCP/IP. Esto requiere que el usuario utilice un programa cliente especial para el servidor DBMS en el cual realiza transacciones y, probablemente, deba usar un programa aplicación que le permita acceder sólo a una parte de los datos en el servidor, o bien, utilice un programa genérico que le permita accesar varios tipos de bases de datos con una interfaz común, pero limitada sólo a aspectos generales de las bases de datos. Una nueva forma de accesar bases de datos es a través de los servicios de información tradicionales como Gopher o WWW, en que el usuario utiliza el mismo programa de uso habitual para acceder ese servicio. El acceso mismo a la base de datos no la realiza el usuario en sí, sino que es el servicio de información el que efectúa las transaciones comunicándose con el DBMS, y luego entrega al usuario los resultados en forma ordenada. El diagrama de la Figura 3.1 muestra el enfoque aquí descrito.

Modelo de servicio con acceso a una base de datos Para que el servicio de información pueda accesar a la base de datos, se requiere que exista un medio de comunicación entre éstos, es decir, que sea posible establecer una conexión al DBMS desde el servicio de información. Esto puede lograrse de diversas formas, dependiendo del tipo de cada uno de los servidores, de la ubicación física de ellos, y de las herramientas disponibles para tales efectos. Por ejemplo, si el servicio de información es WWW, el DBMS es Oracle, y ambos están instalados en la misma máquina o existe una vía de comunicación entre ellos como SQL*Net, es posible escribir un programa interfaz CGI en el servidor WWW que, en base a datos proporcionados por el usuario en un formulario, realice una consulta usando el producto SQL*Plus, utilizando un script SQL adecuado, y analize la respuesta obtenida para formatear el resultado en un documento hipertexto, el cual es enviado al usuario como respuesta a los datos recién proporcionados. Otra alternativa sería utilizar el producto Oracle WebServer, quien canaliza las consultas directamente a procedimientos PL/SQL almacenados en el DBMS.

Posibles aplicaciones del acceso a las bases de datos a través de un servicio de información son las siguientes: 

Se puede generar documentos al vuelo basado en los datos almacenados en una base de datos que es actualizada en línea, tales como el estado de cuenta de una persona en un banco, o la lista de vuelos en un aeropuerto programados para las próximas 24 horas. 

Documentos que entregan información respecto a varios elementos en un mismo tema pueden ser construídos a partir de plantillas que son llenadas tomando los datos desde un servidor de bases de datos. Por ejemplo, se puede tener una base de datos relacional con información geográfica de diversos países, la cual puede ser accesada por el servicio de información para generar documentos con información básica de cada país a partir de una hoja tipo, además de poder resumir estadísticas por región o poder acceder a un mayor nivel de detalle. En un servicio basado en hipertexto, este ejemplo permitiría a un usuario viajar por todo el mundo, pasando de país en país en el caso de existir la relación “paises vecinos”, o bien desde un listado de los países que conforman un continente. Al mantener al día la base de datos, los documentos y sus relaciones serán actualizadas “automáticamente”.

SEGURIDAD EN UNA APLICACIÓN WEB Gran parte de los problemas de seguridad en las aplicaciones web son causados por la falta de seguimiento en dos rubros muy importantes de los que depende cualquier aplicación, las entradas y salidas del sistema. Además de verificar estos 2 rubros, es importante considerar la exposición accidental de datos que pueden ser empleados en un posible ataque sobre el sistema. Los mensajes de error enviados por el servidor, que suelen ser de gran utilidad durante el proceso de desarrollo de la aplicación, pueden ser empleados maliciosamente cuando siguen apareciendo en un entorno de producción, por lo que es necesario deshabilitar todos estos mensajes y editar algunos otros (como los que se envían cuando el servidor no encuentra algún archivo en particular) los cuales también pueden ser utilizados por los atacantes para obtener información sobre nuestro sistema. Balancear riesgo y usabilidad Si bien la usabilidad y la seguridad en una aplicación web no son excluyentes una de la otra, alguna medida tomada para incrementar la seguridad con frecuencia afecta la usabilidad. Normalmente siempre se debe pensar en las maneras en que usuarios ilegítimos nos pueden atacar y la facilidad de uso para los usuarios legítimos. Es conveniente emplear medidas de seguridad que sean transparentes a los usuarios y que no resulten engorrosas en su empleo. Por ejemplo, el uso de un login que solicita el nombre de usuario y contraseña (Ilustración 2.), permite controlar el acceso de los usuarios hacia secciones restringidas de la aplicación. Este paso adicional, es una característica que impacta en la rapidez de acceso a la información por parte del usuario, pero que proporciona un elemento adicional de protección. A mayor complejidad de nuestro sitio, aumenta el riesgo de que se sufra un ataque debido a sus características más elaboradas, es por eso que deben considerarse opciones de seguridad necesarias y sencillas pero eficientes, que ayuden a mitigar cualquier característica que la haga vulnerable.

Rastrear el paso de los datos Es muy importante mantener conocimiento de los pasos que ha recorrido la información en todo momento. Conocer de dónde vienen los datos y hacia dónde van. En muchas ocasiones lograr esto puede ser complicado, especialmente sin un conocimiento profundo de cómo funcionan las aplicaciones 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. Además de entender los orígenes de la información se debe dar la misma importancia a entender cuáles son las salidas que tiene la aplicación y hacia a donde se devuelven los resultados.

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 sean usados para provocar funcionamientos no deseados en la aplicación. Existen muchos puntos de vista diferentes sobre cómo realizar el filtrado o proceso de limpieza. Lo que usualmente se recomienda es ver al filtrado como un proceso de inspección, no debemos tratar de corregir los datos, es mejor forzar a los usuarios a jugar con las reglas válidas. Al usar listas blancas asumimos que los datos son inválidos a menos que prueben ser validos al encontrarse patrones coincidentes. Una limitante de usar este punto de vista es considerar inválidos datos que debieron considerarse válidos pero que no fueron tomados en cuenta patrones similares al construir la lista blanca. Si llegamos a utilizar algún framework se debe tener especial cuidado, ya que estos brindan tantas comodidades que muchos desarrolladores inexpertos los utilizan sin preocuparse en entender el código que están observando y por lo tanto implementan medidas de validación en entradas, variables, entre otros, sin entender exactamente el funcionamiento de la solución empleada. Es importante notar que en los lenguajes de programación existen una buena cantidad de filtros pero evidentemente estos no llegan a cubrir todas las necesidades que puede tener un desarrollador. En este caso, se llegan a utilizar

funciones creadas y adaptadas a nuestras necesidades a modo de filtro especial, en la mayoría de estos casos es donde se puede encontrar el uso de expresiones regulares. En la Ilustración 3 tenemos un ejemplo en PHP de variables GET sanitizadas mediante una función la cual valida que únicamente sean números enteros (FILTER_SANITAZE_NUMBER_INT) y no contengan etiquetas HTML (strip_tags).

Una vez concluido el paso del filtrado solo resta usar convenciones apropiadas en el nombramiento de las variables para poder distinguir las que ya han sido filtradas. Escapado de salidas Otro punto importante de la seguridad es el proceso de escapado y su contraparte para codificar o decodificar caracteres especiales de tal forma que su significado original sea preservado. Si llegamos a utilizar una codificación en particular es necesario conocer los caracteres reservados los cuales serán necesarios escapar. 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.

El proceso de escapado debe adecuarse al tipo de salida de que se trate (si es al cliente, a la base de datos, etcétera). Para la mayoría de los destinatarios, existen funciones nativas en los lenguajes de programación para esta finalidad. En alguno de los casos como podría ser el de base de datos es importante incluso observar la codificación en la que son enviados. Para distinguir entre los datos que han sido escapados de los que no, es recomendable también usar una convención de nombres. Es necesario una función de escapado para cada caso, como ejemplo en PHP se tomarían las siguientes consideraciones para: 

Correo electrónico, se puede usar la función filter_var() con los argumentos de FILTER_VALIDATE_EMAIL.



 

Bases de datos SQL, es más recomendable utilizar consultas parametrizadas pero podríamos utilizar mysql_real_escape_string. Líneas de comandos, se puede hacer uso de la función escapeshellarg(). Código en Javascript, PHP no tiene un método incorporado para escaparlo, pero se puede utilizar json_encode() junto con htmlspecialchars() si se quiere mostrar en HTML.

Ataques URL de tipo semántico Este tipo de ataques involucran a un usuario modificando la URL a modo de descubrir acciones a realizar que originalmente no están planeadas para ser manejadas correctamente por el servidor. La implementación de cualquier formulario debe contemplar validaciones necesarias para evitar el esas acciones y se deben realizar adecuaciones de acuerdo a nuestras entradas, en la ilustración 5 se muestra un formulario de login con campos de usuario y contraseña. En el ejemplo anterior los parámetros, que son enviados con el método GET, se agregan directamente en la URL, lo que produce que atacantes inexpertos puedan utilizarlos, ya que son solo un poco más fáciles de capturar y modificar que los enviados de forma oculta desde el navegador (POST). Un ejemplo del envío por GET es el de la ilustración 5.

Ataques de Cross-Site Scripting 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. Los atacantes típicamente se valen de código HTML y de scripts ejecutados en el cliente. (OWASP, 2014)

Ataques de Cross-Site Request Forgery Este tipo de ataque permite al atacante enviar peticiones HTTP a voluntad desde la máquina de la víctima. Es difícil determinar cuándo 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 suele tener embebida la petición en una imagen. En este caso el atacante sólo necesita crear alguna etiqueta HTML del siguiente tipo: Existen acciones que podemos tomar para contrarrestar este tipo de ataques, una de estas es preferir el método POST para el procesamiento de formas en lugar del GET, otra posibilidad es solicitar confirmación por parte del solicitante antes de realizar los procesos (a costa de reducir la usabilidad en la aplicación). Peticiones HTTP falsificadas Un ataque más sofisticado que el anterior es enviar peticiones falsas empleando herramientas especiales para este propósito. Para ello, se emplean herramientas de línea de comandos o plugins agregados a los navegadores, con estos se pone a la escucha de los servicios web que típicamente se conectan a través del puerto 80. En la ilustración 7 podemos observar los campos que pueden modificarse con Tamper Data.

En realidad un atacante puede confeccionar a gusto sus peticiones HTTP, la fortaleza de nuestro sistema será medible por su capacidad de detectar que peticiones recibidas deben ser escuchadas y procesadas de acuerdo a los parámetros y valores que se vayan a recibir. 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 fuentes de información y el usuario, esto es, las aplicaciones web son usadas para interactuar con 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. De esta manera, si algún dato malicioso

fue inyectado a la base de datos, nuestra lógica de filtrado puede percatarse de ello. Exposición de Credenciales de Acceso Uno de los asuntos principales a ser cuidados cuando se utiliza una base de datos es el almacenamiento de las credenciales de acceso a ella. Los datos de usuario y password son considerados sensibles, por lo que deben tener garantizada una atención especial. En archivos de configuración es común encontrar estos datos los cuales se encuentran como texto en claro. Ver ilustración 8.

La intercepción o acceso no autorizado de esta información podría comprometer los servidores de bases de datos o gestores de contenidos en donde estén alojados. Si por alguna razón no fuera posible localizar al archivo que contiene esta información fuera del directorio raíz, es necesario configurar el servidor web para rechazar las peticiones de recursos que no deben ser accesibles. SQL Injection La inyección de código SQL es la vulnerabilidad número uno en el top de OWASP (OWASP, 2015). Para que exista una vulnerabilidad de SQL Injection se requieren dos fallas por parte del programador: 1. Fallas en el filtrado de los datos. 2. Fallas en el escapado de los datos al enviarlos a la base de datos (escapado de salida). Ninguno de estos pasos cruciales debe ser omitido, y los dos pasos requieren especial atención para poder minimizar los errores. Afortunadamente los ataques de SQL Injection son fácilmente evitables, mientras filtremos y escapemos las salidas.

Conclusiones La seguridad en aplicaciones Web involucra principalmente al desarrollador, aunque con gran frecuencia se encuentran defectos que pueden ser aprovechados por atacantes en las tecnologías en que se basan los sistemas web (Sistemas Operativos, Servidores Web, Servidor de Base de Datos, etc.) la atención principal debe dirigirse a los defectos propios al desarrollo nuestras aplicaciones. Todo programador debe estar consciente que el manejo de las peticiones, para aceptarlas o rechazarlas, deben estar los datos o variables recibidas no cumplan con las características esperadas o predefinidas. Todas las entradas del sistema deben pasar por el filtrado de los datos contenidos para confirmar su usabilidad. Además para el programador debe ser claro y fácil de identificar cuando una variable ya ha sido sometida al proceso de limpieza, de esta forma evitaremos tener que confiar en la memorización o tener que hacer un mapa de los procesos ejecutados por cada línea de código ejecutada de manera previa. Otro aspecto importante a considerar son los procesos de salida de la información del sistema. Es importante siempre considerar el significado que pueda tener la información enviada en su nuevo contexto, y en el caso de poder crear problemas de interpretación de las salidas, escaparlas para preservarlas. Al igual que en el proceso de filtrado, es importante mantener un control sobre la codificación que tienen los datos antes de enviarlos a su nuevo contexto.