21 Ene Prevención Ataques DDOS
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.
Ilustración 4. Formulario con envio de datos por metodo GET
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.
Ilustración 5. URL con parámetros enviados visibles.
3.2 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)
Ilustración 6. Definición general de los tipos de XSS. (Domínguez, 2015)
3.3 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:
<img src=”http://ejemplo.org/compra.php?param=valor¶m2=valor” />
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).
3.4 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.
Ilustración 7. Headers interceptados.
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.
4. 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.
www.incapsula.es
Website DDoS Protection
Incapsula Website Protection offers always-on cloud-based DDoS protection, which automatically detects and mitigates DDoS attacks launched at websites and web applications.
Supported by a robust Content Delivery Network (CDN) and enterprise-grade Web Application Firewall, this service also protects against attacks seeking to exploit application vulnerabilities, while improving connectivity and accelerating content delivery.
TopTen #1 Reviews DDoS Protection
Incapsula Website DDoS Protection
Always-on protection ensures automatic detection and mitigation of DDoS attacks
Application and network layer DDoS attack protection
Identification and differentiation between humans, good bots, bad bots, AJAX and APIs
Includes a CDN and WAF for website performance and security enhancement
4.1 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.
Ilustración 8. Código PHP con contraseñas de acceso a base de datos.
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.
4.2 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:
Fallas en el filtrado de los datos.
Fallas en el escapado de los datos al enviarlos a la base de datos (escapado de salida).
?
Ilustración 9. Descripción básica de SQL Injection.
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.
4.3 Exposición de datos
Una de las preocupaciones más comunes relacionadas con las bases de datos es la exposición de datos sensibles. Al almacenar números de tarjetas de crédito, por ejemplo, es preferible asegurarse que los datos almacenados en la base de datos se encuentran seguros e inaccesibles incluso para los administradores de la base.
Para asegurar que no se almacenan datos como texto en claro en la base de datos, se pueden realizar procedimientos de hash a las cadenas almacenadas para que no sea entendible la información a simple vista. Se debe considerar el costo de esta implementación ya que habría que obtener el hash al insertarlo y al extraerlo realizar la operación inversa, lo que conllevaría a que la aplicación tarde un poco más en responder.
5. Páginas privadas y los sistemas de autenticación
La autenticación consiste en verificar la identidad de un usuario. Comúnmente el procedimiento involucra un nombre de usuario y una contraseña a revisar. Muchas aplicaciones tienen recursos que son accesibles sólo para los usuarios autenticados, así como recursos totalmente públicos.
5.1 Ataques de fuerza bruta
Este tipo de ataque es un método de ensayo y error utilizado para obtener información de una contraseña, clave o número de identificación personal, entre otros. Funciona mediante la generación de un gran número de intentos consecutivos para el valor de los datos deseados. Un ataque de este tipo agota todas las posibilidades sin preocuparse por cuales opciones tienen mayor probabilidad de funcionar.
En los términos del control de acceso, generalmente encontramos al atacante intentando ingresar mediante un gran número de pruebas. En algunos casos el atacante puede conocer nombres de usuario válidos y la contraseña es la única parte que se trata de adivinar.
5.2 Espionaje de contraseñas (Password Sniffing)
Cuando un atacante tiene los medios para analizar el tráfico entre los usuarios y el servidor de la aplicación, debemos preocuparnos por la exposición que pueden tener los datos en el trayecto, sobre todo cuando se trata de credenciales de acceso.
Ilustración 10. Captura de tráfico HTTP con contraseña enviada en claro.
En la actualidad debido a la información que se transmite en la web se recomienda establecer el uso del protocolo HTTPS para poder cifrar el canal de comunicación por el que enviaremos nuestra información. (OWASP, 2016)
5.3 Cookies o variables de sesión persistentes
Cuando un usuario permanece en el estado de registrado después de un tiempo no razonable (por ejemplo, cuando no expira la sesión), tenemos un problema de registros persistentes.
Este tipo de problemas disminuyen la seguridad de nuestro mecanismo de autenticación. Generalmente son causados por una cookie persistente, un ticket enviado al usuario o alguna variable de sesión establecida que no se considera como expirado jamás o que no cambia en cada nuevo registro establecido por el usuario.
Las cookies permanentes y variables de sesión ayudan a los sitios web a recordar tu información y ajustes cuando los visitas más adelante. Esto conlleva un acceso más rápido y sencillo ya que, por ejemplo, no tienes que iniciar sesión de nuevo.
6. 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.
Procedimientos de seguridad básicos para aplicaciones Web
Visual Studio 2010 Otras versiones
Actualización: noviembre 2007
El tema de la creación de una aplicación Web segura es muy amplio ya que requiere realizar un estudio para comprender los puntos vulnerables de la seguridad. También es necesario familiarizarse con las posibilidades de seguridad que ofrecen Windows, .NET Framework y ASP.NET. Finalmente, resulta vital entender cómo utilizar estas funciones de seguridad para contrarrestar las amenazas.
Aunque no se tenga mucha experiencia en seguridad, existen unas medidas básicas que se deberían adoptar para proteger cualquier aplicación Web. La lista siguiente proporciona pautas de seguridad mínima que se aplican a todas las aplicaciones Web y que se deberían seguir:
Recomendaciones generales de seguridad para aplicaciones Web
Ejecutar aplicaciones con privilegios mínimos
Conocer a los usuarios
Protegerse contra entradas malintencionadas
Tener acceso seguro a bases de datos
Crear mensajes de error seguros
Mantener segura la información confidencial
Usar cookies de forma segura
Protegerse contra amenazas de denegación de servicio
Ejecutar aplicaciones con privilegios mínimos
Cuando la aplicación se ejecuta, lo hace en un contexto que tiene privilegios específicos en el equipo local y posiblemente en equipos remotos. Para obtener información sobre cómo configurar identidad de aplicaciones, vea Configurar la identidad de procesos en ASP.NET. Para ejecutar con privilegios mínimos, siga estas instrucciones:
No ejecute la aplicación con la identidad de un usuario de sistema (administrador).
Ejecute la aplicación en el contexto de un usuario con los mínimos privilegios factibles.
Establezca permisos (Listas de control de acceso, o ACL) en todos los recursos requeridos por la aplicación y utilice la configuración menos permisiva posible. Por ejemplo, si resulta viable en la aplicación, establezca que los archivos sean de sólo lectura. Para obtener una lista de los permisos ACL mínimos requeridos para la identidad de su aplicación ASP.NET, vea Listas de control de acceso (ACL) necesarias para ASP.NET.
Mantenga los archivos de la aplicación Web en una carpeta ubicada debajo de la raíz de la aplicación. No dé a los usuarios la opción de especificar una ruta que permita tener acceso a ningún archivo de la aplicación. Esto ayudará a evitar que los usuarios obtengan acceso a la raíz del servidor.
No Comments